Hot Pixel and Dead Pixel removal

Mike Bailey

• 2. August 2006 11:16

This topic has been touched upon a few times in the past, but I can not recall seeing whether or not the issue will be addressed in the future by Capture One. Ulf responded some time ago that dead pixels were not that common in one thread, which in my experience isn't really true. Of two D60s I had in the past one developed two hot pixels. Of two 20Ds, one has a hot pixel. My 5D has begun to show a hot pixel in the past two months. Etc. These are all with less than 1 second exposure, so they are not mapped out by the firmware which does map them out on longer than 1 second exposures.

With the increasing sensor sizes, it's definitely going to be even more common for hot and dead pixels to show up. Raw converters that remove these pixels when developing raw files make this a very useful feature. Other software handles it, and it's possible to add an action in CS2 to take care of this, but having it handled in the raw converter seems to make more sense, like in ACR.

Is there a chance this might be under consideration for version 4? I'm currently using version 3.7.4 of C1 Pro.

Thanks.

Mike

0

• 

  Ulf Liljegren

  • 3. August 2006 14:15

  Hello
  
  I believe much of what I said was that we have not seen much of a problem with it especially not with Phase One camera back where it is handled in the firmware.
  Improving image quality as something that we always work on and we do map out hot pixels.
  With Phase One camera backs this is never a problem but with DSLRs it’s a bit trickier.
  A standard hot pixel map out works like this:
  .
144
|
144----0----144
|
144
.
  
  If you have a single pixels that have value 0 and surrounding pixels value 144 the center pixel will get value 144 or the averaging value.
  How ever this does not kick in unless you have some what of a longer integration time when this becomes more critical during longer integration time[/code]

  0
• 

  Mike Bailey

  • 3. August 2006 22:08

  Ulf,
  
  Thank you for your response. I'm not sure what you mean in your last sentence about longer integration time and the algorithm not kicking.
  
  Out of curiousity I checked to see what C1 was doing (I'm using Magne's profiles, so the values are relative) with the hot pixel on my 5D for various scenes. The values produced were 140,120,120; 245,214,214; 234,202,202 for three different scenes. I assume the values are derived from surrounding pixels. What's interesting is that the R value varies while the G and B seemed to equal each other, so suspect that C1 is aware of some sort of deviant pixel situation at the time of the conversion but doesn't average accurately with surrounding pixels, hence the "red" spot.
  
  ACR seems to get rid of the deviant pixel altogether. I can see no evidence of it even at 600%. RSP tries to average, but ends up mostly just muting the pixel so that it's less visible, but still there.
  
  At any rate I hope your response didn't mean that there won't be any further work on trying to remove hot and/or dead pixels. I suppose a truly dead pixel is much easier since all RGB values would be locked on at 255,255,255 or 0,0,0?
  
  Mike

  0
• 

  Ulf Liljegren

  • 4. August 2006 19:15

  In the digital photographic industry we quite often refer to integration time instead of shutter time which is what a user would worry about.
  Integration time is the time the chip is active before readout which is a bit longer then the shutter time.
  
  In this case would really like you to create a support case at http://support.phaseone.com and for you to attach two of your RAW files from the camera that has the problem.
  One file with 1/125 or around that in shutter time and one with atleast 2sec exposure time.
  
  Thanks in advance.

  0
• 

  Mike Bailey

  • 7. August 2006 14:05

  Ulf,
  
  Sure... I'll do as you ask.
  
  Thanks.
  
  Mike

  0

Post ist für Kommentare geschlossen.