Prev: Performance Issue: Canon Lenses or Camera Body Causing Softer Focus
Next: What place/s in the world would you most want to take a selfportrait in ?
From: Bruce on 14 Jul 2010 07:37 On Wed, 14 Jul 2010 07:21:03 -0400, Alan Lichtenstein <arl(a)erols.com> wrote: >Bruce wrote: >> On Tue, 13 Jul 2010 17:21:39 -0400, Alan Lichtenstein <arl(a)erols.com> >> wrote: >> >> >>>Indeed. All the literature I saw regarding those camera types, >>>beginning with the Olympus PEN cameras did not characterize them as SLR >>>cameras. There are a variety of characterizations, however, the one I >>>see used most frequently, as you assert, is interchangeable lens EVF. >>>Although that does leave something to be desired. If the above was a >>>press release, it would appear someone goofed. >> >> >> >> It wasn't a press release. It was a Bloomberg article, as would have >> been obvious to anyone who read my posting and/or followed the link to >> the original article. Obviously you did neither of those things. >> >Reporters get their facts from the events they cover. The 'article' in >question cites comments by Nikon's president, in an interview. That >said, now unless you are going to assert that the reporter 'embellished' >the facts by adding something that was NOT stated( i.e., inserting the >term SLR when Nikon's president did NOT use it ), we have to believe >that the term was used in the context of the interview. > >Since any interview by a company official, in this case, Nikon's >president constitutes a dissemination of company policy, it can properly >be termed a 'press release.' > >As far as your other comments are concerned, I think that the above >explains my use of terminology. As far as your comment that 'obviously >you did neither' is concerned, I would only caution you not to jump to >conclusions before you go drawing conclusions which may not have the >validity you seem to think they do. IOW, ask first before you make >assumptions. You have worked *very hard* to earn a place in my kill file. So, congratulations!
From: Alan Lichtenstein on 14 Jul 2010 14:29 Bruce wrote: > On Wed, 14 Jul 2010 07:21:03 -0400, Alan Lichtenstein <arl(a)erols.com> > wrote: > >>Bruce wrote: >> >>>On Tue, 13 Jul 2010 17:21:39 -0400, Alan Lichtenstein <arl(a)erols.com> >>>wrote: >>> >>> >>> >>>>Indeed. All the literature I saw regarding those camera types, >>>>beginning with the Olympus PEN cameras did not characterize them as SLR >>>>cameras. There are a variety of characterizations, however, the one I >>>>see used most frequently, as you assert, is interchangeable lens EVF. >>>>Although that does leave something to be desired. If the above was a >>>>press release, it would appear someone goofed. >>> >>> >>> >>>It wasn't a press release. It was a Bloomberg article, as would have >>>been obvious to anyone who read my posting and/or followed the link to >>>the original article. Obviously you did neither of those things. >>> >> >>Reporters get their facts from the events they cover. The 'article' in >>question cites comments by Nikon's president, in an interview. That >>said, now unless you are going to assert that the reporter 'embellished' >>the facts by adding something that was NOT stated( i.e., inserting the >>term SLR when Nikon's president did NOT use it ), we have to believe >>that the term was used in the context of the interview. >> >>Since any interview by a company official, in this case, Nikon's >>president constitutes a dissemination of company policy, it can properly >>be termed a 'press release.' >> >>As far as your other comments are concerned, I think that the above >>explains my use of terminology. As far as your comment that 'obviously >>you did neither' is concerned, I would only caution you not to jump to >>conclusions before you go drawing conclusions which may not have the >>validity you seem to think they do. IOW, ask first before you make >>assumptions. > > > > You have worked *very hard* to earn a place in my kill file. > > So, congratulations! > Had you simply left your post of after stating that it wasn't a press release, but a Bloomberg article, that would have been sufficient to point out what may have been an error of omission or an assumption on my part. But that wasn't sufficient for you. You simply HAD to make it personal by adding the remainder of the phrases. And now you take umbrage at my clarifying what I wrote and why I write it, with the appropriate caution to you not to jump to additional conclusions. Picking up your ball and running home is hardly a mature way of dealing with a disagreement. I remind you it was YOU who began the nit-picking for whatever reason only you can know. Because your comments had no purpose, in the manner you asserted them EXCEPT to begin an exchange that you got. So, take your ball and run home. I could not care less if you don't reply to what I may post or ask. There are others who do not jump to personal attack, no matter how mild you may think it is. A more secure and mature person would simply not reply to an individual he/she wants no truck with. One wonders why you found it necessary to announce to the world that you had a need to kill file someone as opposed to the simple expedient of ignoring them.
From: Peter on 14 Jul 2010 15:33 "Alan Lichtenstein" <arl(a)erols.com> wrote in message news:4c3e0239$0$31264$607ed4bc(a)cv.net... > Bruce wrote: >> On Wed, 14 Jul 2010 07:21:03 -0400, Alan Lichtenstein <arl(a)erols.com> >> wrote: >> >>>Bruce wrote: >>> >>>>On Tue, 13 Jul 2010 17:21:39 -0400, Alan Lichtenstein <arl(a)erols.com> >>>>wrote: >>>> >>>> >>>> >>>>>Indeed. All the literature I saw regarding those camera types, >>>>>beginning with the Olympus PEN cameras did not characterize them as SLR >>>>>cameras. There are a variety of characterizations, however, the one I >>>>>see used most frequently, as you assert, is interchangeable lens EVF. >>>>>Although that does leave something to be desired. If the above was a >>>>>press release, it would appear someone goofed. >>>> >>>> >>>> >>>>It wasn't a press release. It was a Bloomberg article, as would have >>>>been obvious to anyone who read my posting and/or followed the link to >>>>the original article. Obviously you did neither of those things. >>>> >>> >>>Reporters get their facts from the events they cover. The 'article' in >>>question cites comments by Nikon's president, in an interview. That >>>said, now unless you are going to assert that the reporter 'embellished' >>>the facts by adding something that was NOT stated( i.e., inserting the >>>term SLR when Nikon's president did NOT use it ), we have to believe that >>>the term was used in the context of the interview. >>> >>>Since any interview by a company official, in this case, Nikon's >>>president constitutes a dissemination of company policy, it can properly >>>be termed a 'press release.' >>> >>>As far as your other comments are concerned, I think that the above >>>explains my use of terminology. As far as your comment that 'obviously >>>you did neither' is concerned, I would only caution you not to jump to >>>conclusions before you go drawing conclusions which may not have the >>>validity you seem to think they do. IOW, ask first before you make >>>assumptions. >> >> >> >> You have worked *very hard* to earn a place in my kill file. So, >> congratulations! >> > Had you simply left your post of after stating that it wasn't a press > release, but a Bloomberg article, that would have been sufficient to point > out what may have been an error of omission or an assumption on my part. > But that wasn't sufficient for you. You simply HAD to make it personal by > adding the remainder of the phrases. And now you take umbrage at my > clarifying what I wrote and why I write it, with the appropriate caution > to you not to jump to additional conclusions. > > Picking up your ball and running home is hardly a mature way of dealing > with a disagreement. I remind you it was YOU who began the nit-picking > for whatever reason only you can know. Because your comments had no > purpose, in the manner you asserted them EXCEPT to begin an exchange that > you got. > > So, take your ball and run home. I could not care less if you don't reply > to what I may post or ask. There are others who do not jump to personal > attack, no matter how mild you may think it is. A more secure and mature > person would simply not reply to an individual he/she wants no truck with. > One wonders why you found it necessary to announce to the world that you > had a need to kill file someone as opposed to the simple expedient of > ignoring them. Welcome Alan. He put me in, defacto, when I started asking questions he would rather not answer about some mutual acquaintances he claimed we had. -- Peter
From: Better Info on 14 Jul 2010 19:51 On Wed, 14 Jul 2010 07:30:24 -0400, Alan Lichtenstein <arl(a)erols.com> wrote: >Better Info wrote: > >> On Wed, 14 Jul 2010 09:50:15 +0100, Bruce <docnews2011(a)gmail.com> wrote: >> >> >>>On Tue, 13 Jul 2010 17:09:06 -0700 (PDT), Rich <rander3127(a)gmail.com> >>>wrote: >>> >>>>On Jul 13, 5:34 pm, Alan Lichtenstein <a...(a)erols.com> wrote: >>>> >>>>>Please explain the pixel-mapping function. Is it to be used for >>>>>'preventative maintenance' or just if a problem is identified? The >>>>>manual is less than satisfactory. As an Olympus owner, I never used >>>>>this feature, because I had and have no problems. >>>> >>>>If a hot (or dead) pixel appears (a pixel whose response rate differs >>>>significantly from its neighbours) you can "map" the image of the >>>>adjacent pixel over the bad one, thereby eliminating it from the >>>>image. Kind of like how long exposure dark framing is used to >>>>eliminate hot pixels. I never had to use it on an Olympus either, but >>>>it would have come in handy with a few Nikon's I've seen. >>> >>> >>>It was useful on the Olympus E-20 DSLR which seemed particularly prone >>>to hot pixels - more so than any Nikon DSLR, I suspect. >> >> >> EVERY sensor is prone to hot and dead pixels. Just because you don't have >> access to mapping them out or know about them doesn't mean that they don't >> exists. >> >> On average, there's at least 2,000 to 15,000 dead or hot pixels on every >> sensor of every size by every manufacturer. This has been found by the >> "badpixel.lua" script for CHDK cameras. (Through 3 years of sensors from >> various providers.). That LUA script required to run before using CHDK's >> DNG output format. CHDK has to find all the bad-pixels that the cameras >> already knows about before it can convert the RAW sensor data to a DNG >> format. >> >> If your sensor is reporting ZERO bad photosites someone is most certainly >> lying to you. EVERY sensor has them, to varying degrees, no matter how much >> money that you threw at your camera. >> >Perhaps you can add something to my question. I have never used the >pixel mapping function. The manufacturer suggests that it be used once >a year. I cannot detect any 'bad pixels' optically, albeit that is a >very crude and likely very imprecise function, but I see no evidence of >any in photographs. Consequently, I have never used the function. Are >you suggesting that I operate it as per the manufacturer's advice anyway? There's no reason to use it unless you are detecting stuck pixels in all of your photos. Stuck (hot or dead) pixels are a dynamic thing. They can change over time. Depending on static charges and stray cosmic rays, some can become hot or dead for weeks then suddenly clear up on their own. (People who fiddle with webcams and take them apart to add optics or remove the IR filter find this out all too well, the image can be a noisy mess for a week, then it just clears up one day.) Some will show up only when the sensor has warmed up. Others only showing when the sensor is first turned on, while it's still cold. I wouldn't map any out unless you absolutely have to. The nice thing about CHDK's two-fold method (noise removal on/off option) or the DNG saving format (requiring a different file of pixel mappings, filename "badpixel.bin") is that you can even edit the noise-removal's bad pixels file ("badpixel") by hand by entering their X,Y coordinates. One of my Sony superzoom cameras also has a remapping feature (button hidden in the battery compartment), but in the 8 year life of that camera so far I've never had reason to use it. Can you find documentation that it will remap the whole sensor and wipe out the old internal list of bad pixels? Or just look for new ones and add them to a list in memory? If the latter, then you could be losing valuable pixels over time if it won't free up ones that have switched from bad to good. I also wouldn't use it after the camera has been used for a long time, the number detected would rise with sensor temperature. When doing my own CHDK camera tests for shutter speeds from 1 second to 64 seconds (for a special build of CHDK that had a long-exposure hot-pixel removal routine, requiring 17 different badpixel files, one for each shutter speed), it was surprising how many more show up as the sensor gets warmer (not shutter speed dependent). And many times, they were not even the same ones from session to session. This is probably why this special-build routine was not made into a base function of all CHDK builds. If you'd like to find out just how many bad pixels your camera has, look for a little utility called "DeadPixelTest.exe". Or hunt through the CHDK documentation for their own version called "show_bad.exe". The CHDK one outputs the pixels in a X,Y coordinate list from a dark-frame RAW file. You can also define the threshold of just how warm of a pixel you are willing to tolerate as bad. Most choose a threshold value of 32, 64, or 128 (on the RAW data, of 10 (1024), 12 (2048), or 14 (4096) bits) as being indicative of a too warm of a pixel, but this is just a personal preference. One of my CHDK cameras has an exceptionally quiet sensor on it (luck of the manufacturing draw) so I use a warm-pixel threshold value of only 12 on it. Conversely, all of those with a value of a solid zero, 0, in a RAW file have to be mapped out too, as being fully dead (cold, instead of warm or hot).
From: Better Info on 14 Jul 2010 23:41
On Wed, 14 Jul 2010 07:30:24 -0400, Alan Lichtenstein <arl(a)erols.com> wrote: >Better Info wrote: > >> On Wed, 14 Jul 2010 09:50:15 +0100, Bruce <docnews2011(a)gmail.com> wrote: >> >> >>>On Tue, 13 Jul 2010 17:09:06 -0700 (PDT), Rich <rander3127(a)gmail.com> >>>wrote: >>> >>>>On Jul 13, 5:34 pm, Alan Lichtenstein <a...(a)erols.com> wrote: >>>> >>>>>Please explain the pixel-mapping function. Is it to be used for >>>>>'preventative maintenance' or just if a problem is identified? The >>>>>manual is less than satisfactory. As an Olympus owner, I never used >>>>>this feature, because I had and have no problems. >>>> >>>>If a hot (or dead) pixel appears (a pixel whose response rate differs >>>>significantly from its neighbours) you can "map" the image of the >>>>adjacent pixel over the bad one, thereby eliminating it from the >>>>image. Kind of like how long exposure dark framing is used to >>>>eliminate hot pixels. I never had to use it on an Olympus either, but >>>>it would have come in handy with a few Nikon's I've seen. >>> >>> >>>It was useful on the Olympus E-20 DSLR which seemed particularly prone >>>to hot pixels - more so than any Nikon DSLR, I suspect. >> >> >> EVERY sensor is prone to hot and dead pixels. Just because you don't have >> access to mapping them out or know about them doesn't mean that they don't >> exists. >> >> On average, there's at least 2,000 to 15,000 dead or hot pixels on every >> sensor of every size by every manufacturer. This has been found by the >> "badpixel.lua" script for CHDK cameras. (Through 3 years of sensors from >> various providers.). That LUA script required to run before using CHDK's >> DNG output format. CHDK has to find all the bad-pixels that the cameras >> already knows about before it can convert the RAW sensor data to a DNG >> format. >> >> If your sensor is reporting ZERO bad photosites someone is most certainly >> lying to you. EVERY sensor has them, to varying degrees, no matter how much >> money that you threw at your camera. >> >Perhaps you can add something to my question. I have never used the >pixel mapping function. The manufacturer suggests that it be used once >a year. I cannot detect any 'bad pixels' optically, albeit that is a >very crude and likely very imprecise function, but I see no evidence of >any in photographs. Consequently, I have never used the function. Are >you suggesting that I operate it as per the manufacturer's advice anyway? There's no reason to use it unless you are detecting stuck pixels in all of your photos. Stuck (hot or dead) pixels are a dynamic thing. They can change over time. Depending on static charges and stray cosmic rays, some can become hot or dead for weeks then suddenly clear up on their own. (People who fiddle with webcams and take them apart to add optics or remove the IR filter find this out all too well, the image can be a noisy mess for a week, then it just clears up one day.) Some will show up only when the sensor has warmed up. Others only showing when the sensor is first turned on, while it's still cold. I wouldn't map any out unless you absolutely have to. The nice thing about CHDK's two-fold method (noise removal on/off option) or the DNG saving format (requiring a different file of pixel mappings, filename "badpixel.bin") is that you can even edit the noise-removal's bad pixels file ("badpixel") by hand by entering their X,Y coordinates. One of my Sony superzoom cameras also has a remapping feature (button hidden in the battery compartment), but in the 8 year life of that camera so far I've never had reason to use it. Can you find documentation that it will remap the whole sensor and wipe out the old internal list of bad pixels? Or just look for new ones and add them to a list in memory? If the latter, then you could be losing valuable pixels over time if it won't free up ones that have switched from bad to good. I also wouldn't use it after the camera has been used for a long time, the number detected would rise with sensor temperature. When doing my own CHDK camera tests for shutter speeds from 1 second to 64 seconds (for a special build of CHDK that had a long-exposure hot-pixel removal routine, requiring 17 different badpixel files, one for each shutter speed), it was surprising how many more show up as the sensor gets warmer (not shutter speed dependent). And many times, they were not even the same ones from session to session. This is probably why this special-build routine was not made into a base function of all CHDK builds. If you'd like to find out just how many bad pixels your camera has, look for a little utility called "DeadPixelTest.exe". Or hunt through the CHDK documentation for their own version called "show_bad.exe". The CHDK one outputs the pixels in a X,Y coordinate list from a dark-frame RAW file. You can also define the threshold of just how warm of a pixel you are willing to tolerate as bad. Most choose a threshold value of 32, 64, or 128 (on the RAW data, of 10 (1024), 12 (2048), or 14 (4096) bits) as being indicative of a too warm of a pixel, but this is just a personal preference. One of my CHDK cameras has an exceptionally quiet sensor on it (luck of the manufacturing draw) so I use a warm-pixel threshold value of only 12 on it. Conversely, all of those with a value of a solid zero, 0, in a RAW file have to be mapped out too, as being fully dead (cold, instead of warm or hot). |