search

Kalpanika / x3f

Tools for manipulating X3F files from Sigma cameras
89 stars 28 forks source link

green shift/bias correction #6

Open mmroden opened 9 years ago

mmroden commented 9 years ago

The images have distinct color differences from those produced by SPP.

rolkar commented 9 years ago

You can find some examples here

http://www.dpreview.com/forums/post/56175736 http://www.dpreview.com/forums/post/56178615 http://www.dpreview.com/forums/post/56179091 http://www.dpreview.com/forums/post/56182506

It seems to be a color hue added to an otherwise just fine image. The hue can both be as a vignetting or all over the image.

erikrk commented 9 years ago

http://www.dpreview.com/forums/post/56175736

This looks like an extreme example of the green bias problem, with severe clipping of the blacks in the red and blue channels. The blacks in the green channel are somewhat clipped as well, but that could be due to a setting in ACR. We should really have the X3F for this one.

rolkar commented 9 years ago

I have tested to do both DNG and TIFF conversion of the same image. They have the same color shift and vignetting. So, it is not a matter of mistake writing the DNG data.

But - the TIFF image is quite darker. Which feels strange.

The test was on a white wall with a Merrill camera.

erikrk commented 9 years ago

ACR is applying +50 brightness and +25 contrast by default. If you set those two to zero you might get something more similar to the TIFF output.

On sáb, 2015-07-25 at 14:09 -0700, Roland Karlsson wrote:

I have tested to do both DNG and TIFF conversion of the same image. They have the same color shift and vignetting. So, it is not a matter of mistake writing the DNG data.

But - the TIFF image is quite darker. Which feels strange.

The test was on a white wall with a Merrill camera.

— Reply to this email directly or view it on GitHub.

erikrk commented 9 years ago

I have examined "Henrik Silkeborg motomanDK - - SDIM8116.X3F". If you process with "x3f_extract -tiff -unprocessed -no-crop" it becomes evident that the masked areas above and below the active image are seriously messed up. Apparently something wrong with the camera. SPP manages somehow though. Maybe it has some kind of heuristics? Should we care? Maybe we could add a manual override for black level?

rolkar commented 9 years ago

Maybe do a global search after the darkest areas.

erikrk commented 9 years ago

How would this be done in practice? It's of course very easy to just find the darkest pixel, but that's not what we want. We want to calculate the average of a substantial number of masked pixels.

The question is, how much should we bother about such things? This is obviously a "defective" camera. SPP manages to handle it somehow though. Kind of disturbing. So, is this a defective camera or not? It's a matter of definition.

On vie, 2015-07-31 at 01:55 -0700, Roland Karlsson wrote:

Maybe do a global search after the darkest areas.

— Reply to this email directly or view it on GitHub.

erikrk commented 9 years ago

68 should solve this case.

http://www.dpreview.com/forums/post/56178615

erikrk commented 9 years ago

Merrill files have something called WhiteBalanceColorShadingFactor. Could this be important for color correction? I don't know how to interpret it though. It's a set of 2x2 matrices, one for each white balance setting.

Quattro files instead have SunlightColorShadingFactor, FluorescentColorShadingFactor and IncandescentColorShadingFactor. They seem to be grids the cover the image instead of just four coefficients.

erikrk commented 9 years ago

I have an alternative theory when it comes to the issue with green bias and clipped blacks in the blue channel for Merrill and Quattro. I don't think it has anything to do with black level correction. It probably has to do with gain correction instead. Since gain correction is done before color space conversion and the conversion involves big negative coefficients, bad gain correction could very well result in negative values after conversion.