[Gray]

Does anyone know what this blue spot is? Here's an enlargement of a low-light image.



There are two of these blue spots that appear in low-light images taken with my K-5.
They are clearly visible in this full image taken with the lens cap on.

[calsan]

That's easily fixable.
Just select pixel mapping from the set up menu and go OK.

[Gray]

That's easily fixable.
Just select pixel mapping from the set up menu and go OK.

Thanks - quick and easy.
I've never used px mapping before and the spots were very annoying. Now to satisfy my inquisitiveness and find out what px mapping is and what causes it to be needed...

[jerm1386]

dead pixels or, in your case, hot pixels, are a byproduct of manufacturing a sensor with 16 million photosites in such a small area (each 'pixel' is actually 1R, 1B, and 2G pixels in a square). You can't get them all perfect all the time. some may be perpetually dark, but others are stuck bright. There's usually an upper limit on the number that can be defective before they throwout the sensor, but many sensors, from any given production run, will have these tiny imperfections. what pixel mapping does is takes a picture with no light (it can just keep the shutter closed) and looks for these aberrations, and stores their location so it knows to subtract them from any further photos.

Incidentally if you let your sensor get hot by doing a lot of live view/long exposures, more hot pixels can show up (but will usually go away again when the sensor cools down)

---

Last edited by jerm1386; 10-26-2011 at 05:39 PM. Reason: I was wrong on the number of photosites

[Gray]

dead pixels or, in your case, hot pixels, are a byproduct of manufactuing a sensor with 64.8 million photosites in such a small area... go away again when the sensor cools down)

Thanks for such an understandable and concise explanation. I've learned something new today! Cool.

[RioRico]

A historical note: Hard-disc surfaces aren't perfect either, no more than are multi-migapickle sensors. Hard discs always have bad sectors. Those get mapped-over by the controller circuitry. That mapping is automagic now (and maybe cameras should go for such auto-repair too). But back in the day, with simpler interfaces, hard discs were shipped with printed bad-sector lists. Installation required manually entering those addresses for the controller to bypass.

But that's nothing. I recall a BYTE magazine article from ~late 1980s, reporting on developments in Soviet microcomputing. USSR fab quality wasn't so great. CPU chips would be shipped with BAD INSTRUCTION lists. Any specific CPU chip might or might not be able to add-to-register or move-to-port. So any particular CPU chip RAN ONLY ITS OWN SOFTWARE! No portability at the machine-language level. Sort of like a camera model where any particular copy might or might not be able to set WB, or adjust contrast, or whatever. Yow. Are we having fun yet?

[drougge]

a sensor with 64.8 million photosites in such a small area (each 'pixel' is actually 1R, 1B, and 2G pixels in a square).

It's the same number of photosites as pixels.

The bayer mask is RGBG or similar, but it's still one photosite => one pixel. If they didn't do it that way, they would have smaller numbers, and that would sound bad to marketing. (Also, it's actually better to use them as separate pixels, just not as good as having a single location that senses all colours (as Foveon does).)

[jerm1386]

Wow, you learn something new every day. I always figured that each pixel on the sensor was comprised of one R, one B, and two G photsites. Turns out, though our images are processed and displayed as 16MP x3 colors, each pixel starts out as only representing one color and the data for the other two colors it can't represent are interpolated from the pixels around it. No wonder foveon advertises their sensors as 3x the MP of the images it spits out! This also aligns with RAW image sizes; i guess if each pixel were 4 photosites' worth of data, our RAW files would be 90MB apiece

I have updated my post accordingly.