From: Bruce on
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
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
"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
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
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).