Does this mean SilkyPix WILL support the SD1?

ArvoJ wrote:

oz75 wrote:

@ArvoJ: Thanks for the explanation. Could you tell me, where you've got these information ("...decode and write non-color-converted data for newer cameras")?

From other people comments of course Well, I took a look at current dcraw code too - apparently it just skips entire color conversion routine for newer Foveon cameras.

This means also that supplying calibrated target images doesn't help DC to improve Foveon support.

That is true. It is hard to calibrate something as noncolorimetric as a Foveon sensor with the small number of patches in a target. If you have full spectral responses, you can run a library of thousands of spectra through those response curves and get a much better calibration surface. So, the best way to tackle a Foveon is with a monochromator on an optic bench, to get a. 10nm spectral response. Been there, done that.

Foveon color conversion is not simple matrix multiplication and/or color curves application (like for usual RGB sensors), it consists of many more steps - and there're no publicly known algorithms for some of these operations available.

Actually, there are. There's even free code for most of what you need.

There are a couple of good algorithm packages for all the color math. The last time I wrote a Foveon color processor, I borrowed the 3 space to 3 space interpolator from Marti Maria's LCMS. LCMS Is still under active development, so that takes care of the first piece of the puzzle.

Color actually isn't the worst of the three highly specialized algorithms needed to deal with on Foveon raw processing. I'd say the worst piece of the puzzle is blown highlights. Bayer sensors blow "gracefully", if you don't do anything special at all, you get a "hue shift" when you blow one channel, and the shift worsens as the second and third channels approach blow out.

Higher end raw processors use inpainting algorithms just on the blown channel, so there's no hue shift until you've blown all three channels, at which point you just blow straight to white, and it looks natural.On a Foveon, when you blow one photodiode channel, you lose all three readout channels in that pixel. This can happen at a surprisingly low signal level. Foveon tried several approaches. Blowing to white did not work, at all. Imagine having an area that was deep red, relatively dull, only 20% luminance, and the red channel saturates, so you blow right from 20% luminance red to 100% luminance white. That's why Foveon's first SDK blew to 60% grey. It was never the "right thing" to do, it was just less "wrong" than going to white or black.

Currently, SPP uses full fledged inpainting for blowouts. Sometimes that works, other times, you get weird textures in the blowouts. That "signature" is what let me figure out WTF Foveon was doing. Inpainting was not in the last SDK I had. I don't think dcraw has a suitable blowout compensator or red channel sharpener (we'll come back to that). But here's where you get them.

Paul Harrison's Ph.D. thesis on texture reconstruction turned into an inpainting plugin called "resyhthesizer" or "retexturizer" or something, and it's exactly what you need for blown highlights on the Foveon. (I know Paul more for his work in flute design software, from years back when I ran the "flute tech" forum. He's friendly, helpful, and your absolute best chance at getting through this).

Red channel sharpening is the last piece. If you just do the 3 space interpolator and then say "hey, we've got red now, let's sharpen it", you get what SPP gets, orange, yellow, and green ghosts that put the lie to the claims of "full resolution color". That's the one I used from the Foveon SDK. Sigma was going to open that thing up. Did they ever follow through? Anyway, I was not impressed. I figured out how to do it right, but never implemented it.

For this last piece, take Roy Berns's spectral estimation from RGB images algorithm from his RIT papers around 2000, break the Foveon image into seven 50nm color channels, call them ROYGBIV, and then sharpen the red, orange, yellow, and green channels by different radai using a deconvolution sharpener. I used that 7 channel technique for fringe-free chromatic aberration correction in a different application, so I'm positive it will work for this.

Sorry, no free code on the spectral estimation that I know of.

(some may notice that I used the terms "interpolation" and "estimation" an awful lot. For anyone that finds this disturbing, my sincere apologies. Truth can be like that, sometimes).

wizfaq Foveon