Tema: Color and gamut in Perfectraw

Color and gamut in Perfectraw

It seems important that Perfectraw handles colors and gamut with the same quality as the interpolation and processing noise.

The work is being done at the level of interpolation (Emil and Amaze, Luis and his fasts interpolations, Manuel and AFD, etc..), and the noise level (Emil, Manuel, Luis ...) is a very high level. It must be the same in color and mastery of the gamut.

This problem is far from straightforward, because the first approach under consideration is skewed by our screens, which are mostly in sRGB, not about showing that 35% of the visible spectrum. The first screens AdobeRGB (50%) and even WideGamut (75%) arrive on the market. The high-end printers inkjet arrive to restore colors including green and blue near WideGamut. It is therefore important that the processing of raw file does not deteriorate the colors and return the best color gamut.

This problem is not new to Perfectraw and dcraw as early development 2 problems have been addressed: the high-lights (with 2 options in dcraw "blend highlights" and "recover_highlights", then the Gamma 16-bit the problem of rendering quality of low light and lack of artifacts.

Nevertheless, the color processing is not limited to these two aspects.

Recall that image out of the camera (raw) is without value rgb color space. It allocates space (sRGB ... ProPhoto) during processing raw. It is difficult to know the extent of the native area, but the tests I have done and the opinion of several experts lead to believe that the data of the camera are beyond WideGamut towards ProPhoto . The ideal treatment of the file would lose nothing.

All treatments can cause a loss of color gamut or color changes: interpolation, chroma noise, luminance noise, sharpening, highlights, low lights, gamma, allocating space, contrast, exposure, saturation, ICC profiles, etc..
It is therefore important to ensure: a) the processing retains color and gamut, or maintained at acceptable levels, b) if it is impossible that filters or palliative maintain an acceptable level.

For Perfectraw, it will be necessary to ask several questions:

• What levels of loss of color and gamut does accept it for processing? With consequences: what metrics? and what process?

• What workspace default? ProPhoto (as Lightroom) or sRGB ...

• What color rendering gives tone? The closest to reality (deltaE94 optimization) which is not the most pleasant to see or “houses” profiles - as do NX2 or C1 or DxO. With, what consequences for color processing? By calculation, in RGB mode, in Lab mode, with ICC profiles, etc..

For example, having already shown a comparison of the texture of the reds, the importance of treatment, http://jacques.desmis.perso.neuf.fr/compar_rouges1.jpg and http://jacques.desmis.perso.neuf.fr/compar_rouges2.jpg

I enclose a second example, still on the treatment of noise.

First image D700 200ISO
http://jacques.desmis.perso.neuf.fr/comp-bleu1.jpg


Second image D700 6400ISO treatment with standard Gaussian noise

http://jacques.desmis.perso.neuf.fr/comp-bleusf.jpg

D700 6400ISO third image same teatment with the blue filter.
http://jacques.desmis.perso.neuf.fr/comp-bleuaf.jpg


The blue in these images are beyond WideGamut, but inside of ProPhoto. Of course it can be argued that these colors are rarely found in nature .




Best regards

Doesn't dcraw share some similarity with ACR in that it uses a color transform matrix generated by Adobe? Is the profiling capability that Adobe Labs has provided a relatively open system, in that the color profiles can be used by other programs? That would provide at least a good integration with Adobe and a ready-made capability to profile one's camera.

The problem with Adobe's .dcp structure is that in many cameras the final result of the profile is exposure dependant; it's a four-stage profile consisting of dual-temperature WB matrices, dual-temperature forward transform matrices, dual-temperature pre-exposure LUT transforms in HSL before it releases the image data into the LR/ACR engine for exposure/hue/sat/curve treatment. It is then returned to the camera profile for one last LUT transform that originally was meant to do some "perceptual" correction of the image data (hue preception varies with image brightness/saturation, and this cannot be corrected before all exposure/curve adjustments have been applied).

Now it seems most profiles do include quite a bit of the actual correction into the last LUT, not just perceptual "touch-ups".

The "camera gamut" problem is widely discussed and few grasp the implications of having a poorly defined, noise affected, primary RGB structure. The large area colour definition can in fact stretch out towards pure monochromatic hues if you average areas large enough - in hues not affected by CFA filter response non-linearities or metamerics. The smaller the areas and the lower the signal level gets, the more the gamut shrinks. For a normal CC24 test you use a minimum of 256 pixel values to get "average colour", and this may/may not correspond to real use.

I don't see "screen-limited" gamuts as a problem as long as your system is setup to have a good CMS flow, and a good monitor profile. No colour is EVER true to reality, which also needs to be pointed out sometimes. Even though CIECAM02 gets quite close, the WB transforms are never totally true to what we would actually perceive under the transposed light temperature. Overall balance and the relationship between saturated/less saturated colour is more important than absolute gamut fitting. We adapt to the screen gamut just as well as we adapt to real-world light WB changes.

The Adobe .dcp standard is open, and quite well documented in the DNG-standard documents. Icc-conformity would be easier though, and I think this is what Coffin uses - the .dcp matrices packaged in .icc-compliant format. You loose quite a lot of the .dcp flexibility (the profile gets less "WB-flexible") but functionality would be good. The CaptureOne package also uses .icc camera profiles, but I don't know if their profiles are "free for use".

Iniciado por theSuede

The problem with Adobe's .dcp structure is that in many cameras the final result of the profile is exposure dependant; it's a four-stage profile consisting of dual-temperature WB matrices, dual-temperature forward transform matrices, dual-temperature pre-exposure LUT transforms in HSL before it releases the image data into the LR/ACR engine for exposure/hue/sat/curve treatment. It is then returned to the camera profile for one last LUT transform that originally was meant to do some "perceptual" correction of the image data (hue preception varies with image brightness/saturation, and this cannot be corrected before all exposure/curve adjustments have been applied).

Now it seems most profiles do include quite a bit of the actual correction into the last LUT, not just perceptual "touch-ups".

First of all, welcome! Glad to have your input here.

The "camera gamut" problem is widely discussed and few grasp the implications of having a poorly defined, noise affected, primary RGB structure. The large area colour definition can in fact stretch out towards pure monochromatic hues if you average areas large enough - in hues not affected by CFA filter response non-linearities or metamerics. The smaller the areas and the lower the signal level gets, the more the gamut shrinks. For a normal CC24 test you use a minimum of 256 pixel values to get "average colour", and this may/may not correspond to real use.

Not sure what you mean by averaging areas -- areas of what? And what nonlinearities of the CFA do you have in mind? I had a perhaps naive view that the CFA response is linear, it is not a nonlinear optics device but a simple linear response dielectric as far as I am aware. Response of the underlying photosites is not linear, but that is a different thing.

The Adobe .dcp standard is open, and quite well documented in the DNG-standard documents. Icc-conformity would be easier though, and I think this is what Coffin uses - the .dcp matrices packaged in .icc-compliant format. You loose quite a lot of the .dcp flexibility (the profile gets less "WB-flexible") but functionality would be good. The CaptureOne package also uses .icc camera profiles, but I don't know if their profiles are "free for use".

OK, color management in the converter is not something I've yet delved into in any detail. At the moment, what I think I would want is a decent base color profile such as offered by dcraw, and then a means by which people can generate and share color profiles of a more sophisticated nature for any given camera model. What I liked about the Adobe Labs profiler is that it is easy to generate a profile for one's own camera with a color chart, and the ability to tweak it to taste in a user-friendly fashion.

Sorry for not being entirely clear... By "nonlinearity" I mean that the CFA filter response is not a theoretically perfect bandpass function (modulated by "wavelength") of any sort, but a complex mix of different absorptions. Even though you can characterize the filter response by a point on the xyY-plane you cannot count on the actual response being anywhere close to what a "minimum loss" spectral model of this point would look like. That's why a pure matrix multiplication won't get you more than "reasonably close" to a real correction of the camera profile - you need LUTs with quite high resolution to do that. The "folds" on chromaticity space can be very sharp in some cameras.

But for large stretches of the "horseshoe" created by the pure spectrals on the xyY chromaticity diagram you can get very close to monowavelength accuracy/resolution if you feed the camera with a monochromator - IF you get large areas enough to be able to totally disregard the effects of noise. I had a short discussion with Ilah/Marianne over at dpr regarding this that I never got around to muster the energy to finish. The D3x was pushed further down the "to do" list, so it didn't coincide with my paid work.

This is why you cannot define a "camera gamut", to do this you also have to define an exposure level and a minimum area - to be able to accurately account for the noise covariance error ellipse around the point you intend to set as an outer bound on the "gamut" surface. A camera is a passive secondary reflective tristimuli measurement, not a at all to be likened to a RGB "source".

A camera gamut as defined by it's RGGB response and a certain minimum signal to noise ratio will be very uneven and ragged in its outline - not even close to the nice and neat geometrical triangles you get from a emissive source like a crt or lcd panel display. For some wavelength ranges where the camera has input referred metamerisms (caused by the filter imperfections) it actually asymptotes to zero, meaning that colour accuracy is zero in this range if you set the measurement accuracy threshold to tightly. It can at the same time have 1nm placement accuracy in a band very close to this.

Is the Dcraw only using the matrix part of the .icc you can feed it as "camera profile"? I don't think so - but I haven't looked closer at how it handles colour, I've always used it as a "pure" source to get linear gamma camera RGB's from. I would think it uses the entire v2.2 spec icc to include a LUT also. This takes you quite far, I don't see any reason to make things more complicated than this. You can still use the Adobe "profiler tool" to make a dcp-profile and then just extract the usable parts from this into an icc-profile usable in the Dcraw frame.
_______________________________________________
_______________________________________________
Another thing I meant to comment was about the NR algorithms you discussed over in the other thread. You're testing them on the ImagingResource testimages, and that may not be very representative...

They are all lit by very good D50 light facsimiles - high ISO photography is more often than not lit by "A" 2800 to 3500K light, which changes our "lightness" perception quite radically. The red is just as big an input into the "lightness" perception as the green in those lower light temperatures. As far as I've seen the largest NR requirement and lies in the blue channel - the red channel does more often than not have a lower S/N ratio than the green channel in high ISO situations - in incandescent light it may even have a higher S/N ratio than the green channel even though the green samples twice as much area...
What needs to be tightly controlled is the chromaticity control of the blue channel on the final result - you want the "white" to be reasonably detailed and balanced without letting the very high noise ratios in the blue channel pass though as chroma noise speckles. The blue colours are psychovisually dampened in intensity in low-light situations, so some loss of "brightness" in blue colours of the picture is to be preferred over speckle-noise in my opinion.

Well, I should get back to my own work... :-)

I agree with "theSuede", CFA filter response is not linear, but complex. Using a trio matrix is a last resort, which may nevertheless be appropriate in most cases. The record obtained will be similar to that of ACR or Lightroom. I do not know if it is possible to easily extract the "profile" from the Adobe tools?

If you want to go further, eg for reproducing paintings (Picasso, Bruegel, Velasquez ,...) passage through ICC profiles obtained rigorously is almost indispensable.

This implies:
1) to work with a digital-target with a wide color gamut, rich in low light, guiding profile
2) have a program to develop the profile. One of the best of my knowledge is "ProfilMaker" from GretagMacbeth.
3) to amend dcraw to take into account the profiles after gamma (I never managed to get correct results with the profile management "internal" of dcraw).
4) etc..

I have 1) and I realized 3). A friend has ProfileMaker, which allows me to get very good results with dcraw and CaptureNX

I tried the profiles provided with CaptureOne and CaptureNX ... and the results are disappointing.

Regarding the images of "images resources, they allow : a) a comparison of process b) a review of treatment" means ". Nevertheless it would be interesting to find more complex images with: a) differences of illumination on the same images (D50, D80, tungsten, etc..), B) significant variations of exposure. I do not have that type of image.

Regarding the initial question about colour handling in the "new" program, I would recommend that at least a matrix WB/precorrection is used BEFORE postprocessing. This makes the post-processing in the program (NR) a lot more precise (less difference between different pictures and different output profiles). If there is a possibility to apply the correction LUT also before post-processing - even better. I have no DCraw programming experience, so I don't know.

Colour handling in and after the interpolation is a balance between correction (and thereby enabling maximum possible input gamut) and avioidance of clipping in the output stage. Often when you export to ProPhoto it's quite hard to clip RGB values, even with quite sharp colour correction. But if you're normally exporting the post-processed picture to sRGB and you have processed the picture in full camera gamut you will get clipping, especially in noisy and noise-reduced images. In this case it is often better to lower the saturation of the picture in the matrix/LUT already before postprocessing - it gives a more "even" result as the post-processing then works in the linear range of the output gamut. Maybe you should consider this, even with AdobeRGB.

Gamut limiting (or shrinking) before post-processing can be a good thing. After this, perceptual conversion to the output colour format is the best we can do. The .icc official v4 sRGB is kind of buggy/spiky though, but I have stable perceptual 3D profiles for both PPRGB>ARGB and PPRGB>sRGB in my computer.

Sorry I cannot be of more help with the programming, but that is a bit outside of my range right now....

Following the remarks of "theSuede" and more opportunities already present, I made several changes to the code to test and optimize.

I have not changed the treatment algorithms of noise (or minimal changes in settings) before interpolation, impulsion after interpolation, Gaussian, and chroma.

I brought several possible settings:

• Algorithm and place in the code occurs for the exposure compensation:
1. Before interpolation
2. After interpolation, but before processing noise
3. After processing and noise before conversion RGB
4. After converting RGB

• When there is no noise processing, the result is substantially identical. Treatment 2) and 3) seems the best because it allows control over exposure in contrast to 1)

• In case of treatment of noise the best result is obtained with 3). Treatments 1) and 2 accompanied by a lower score for the chroma noise and 4) is poor.

• Algorithm and place of gamma relative to the treatment of noise:

• I tried to make the entire process noise after converting RGB and gamma, results are significantly worse

• I applied a gamma LUT before treatment of noise and without RGB conversion. The results for the treatment of noise are less good and colorimetry is wrong, it would be necessary to recalculate the matrix Adobe (how?)

• I applied a gamma (pow() without LUT) before treatment of noise, then a gamma reverse after treatment of noise to get the system under the same conditions. This allows processing of Gaussian noise without damaging the texture preserving the low lights:

• I made 2 types of tests: a) it concerns the whole gamma processing noise after interpolation b) only the Gaussian noise

• The best results are obtained by limiting treatment to Gaussian noise with a gamma around 1.2 or 1.4 and an inverse gamma of 0.83 and 0.71

Reminder: as regards the ICC profiles calibration cases, the only algorithm that works properly (or that I managed to run) is running after converting RGB and gamma (as do Capture NX2 and DxO)

Conclusion:
• Apply a gamma pow() (1.2 to 1.4) and its inverse before and after the treatment of Gaussian noise significantly improves the quality of treatment
• Apply a gamma LUT before processing noise, or a gamma for the treatment of chrominance noise degrades the performance
• The best exposure control for noisy images is to do just before the RGB conversion.

It is possible that with other algorithms (noise, gamma ...) the results could be better ??

Care to post some comparative images jdc? Also where does one acquire your latest binary?

The update version of my binary (*. exe) is on my site to one of these 2 addresses. Do not forget VCOMP90.dll.
1) Nouvelle page 1
2) Nouvelle page 1




I arbitrarily chose 7 crops (actually 21 = 7x3) to show the impact of adjustments.

The first trio is an image 200iso without exposure correction and a gamma BT709, and without auto-levels. (In my version of dcraw 16-bit if “-W” is not activated, the levels are automatically adjusted for the highlights and low lights, of course you can play separately on the contrast level low side lights and high side lights). We can see from this image that Colorchecker24 is clearly underexposed: 4th gray box is L = 36 instead of 51, the first is L = 75 instead of 95 and the last is L = 9 instead of 21.


Command line (with AMML interpolation):
Dcraw_99 -w -v -o 4 -4 -g 2.22 4.5 -T -W -q 2




The second trio is an image 200iso with the same gamma correction but an exposure correction that takes place just before the RGB conversion. The exposure is correct. It is this image that will serve as a reference in particular to examine the details, texture and color levels in the bottle and the cup.
Command line :
Dcraw_99 -w -v -o 4 -4 -T -g 2.22 4.5 -q 2 -F 1.95 3 0.2 -W




For the third line, I applied a gamma BT709 just after interpolation. I then realized increased exposure to the 4th box is gray to L = 51. Then I did the conversion without RGB gamma. It is easy to see that the colorimetry is wrong

Command line:
Dcraw_99 -w -v -o 4 -4 -T -g 1.0 0 -q 2 -F 1.47 3 0.2 -W -9 GAMMAINT 1




Next soon...
_______________________________________________
_______________________________________________
The 4th trio corresponding to the image 25600ISO (D700), without exposure compensation, with-W, and treatment of noise:
* High frequencies and impulsion before and after interpolation (50 in command line)
* 3 pass Gaussian - Force 2
- Edge type Lab - hard -3 - Level 200
- Chroma noise "wavelet" - samplings with 5 - strength 400.


Command line :
Dcraw_99 -w -v -o 4 -4 -T -g 2.22 4.5 -q 2 -W -9 NRM 50 3 2 -3 5 200 -12 400


Of course the image is underexposed, but we see the loss of texture and detail in the black bottle and cup










The 5th trio uses the same settings, and a correction exposure after noise processing, but before RGB conversion. The image is properly exposed, but the black in the bottle and cup have a loss of texture and detail.
Dcraw_99 -w -v -o 4 -4 -T -g 2.22 4.5 -q 2 -W -9 NRM 50 3 2 -3 5 200 -12 400 -F 1.8 3 0.2






The 6th trio repeats the same noise settings, but a gamma (pow ()) is made, then its inverse for all the processing noise. The exposure correction is done just after the interpolation. The image is properly exposed, but the noise level remains high.
Command line:
Dcraw_99 -w -v -o 4 -4 -T -g 2.22 4.5 -q 2 -W -9 NRM 50 3 2 -3 5 200 -12 400 -F 1.8 4 0.2 -9 PGAM 1.25 1






The 7th trio is identical to the 6th, the gamma pow() only for gaussian, and the exposure is done just before the RGB conversion. The result is better, however, it is an image 25600ISO with algorithms in my possession.
Command line:
Dcraw_99 -w -v -o 4 -4 -T -g 2.22 4.5 -q 2 -W -9 NRM 50 3 2 -3 5 200 -12 400 -F 1.8 3 0.2 -9 PGAM 1.25 0

The last crop definitely shows the best noise/detail comprmise. Well done!