Artifacts from minimal raw processing

afre · September 2, 2019, 4:21am

Note Sorry about not presenting the problem adequately. Was undergoing one of the hardest moments of my life this summer. It will become clearer near the end of the thread. I will continue posting as I find out more.

Let me explain how I found this issue. It might help you understand my process and perhaps sort out things other than outlier clipping. From my Play Raw processing, I notice something peculiar. That I was getting more noise issues than other members’ edits. I wanted to know the reason. One thing that influenced the noise and artifacts was the raw developer setting here:

clip negative values on or off yield different results; among other factors, artifacts and noise. Couple this with export colour space and encoding, you would have different combinations and results.

Early on, I would simply go the Rec2020 linear no-clip route but then I started alternating among

– Rec2020 linear no-clip + pass through (Working profile)
– Rec2020 linear no-clip + sRGB linear
– Rec2020 linear no-clip + sRGB standard
– Rec2020 linear neg-clip + pass through (Working profile)
– Rec2020 linear neg-clip + sRGB linear
– Rec2020 linear neg-clip + sRGB standard

First thing I noticed while making the comparison was that colour space conversion in export could create negative values, which a user would not expect but makes complete sense if one understood what was going on. Raw developer gives the user the power to choose to clip or not. Export doesn’t.

The other thing was that certain combinations yield uglier results than others. In my preliminary G’MIC experiments, I found the bolded combination yield the best minimal raw starting point.

vs

Source: my colour Play Raw post.

where the girl’s iris and the woman’s hair doesn’t have much detail left due to noise and artifacts. I tried (not very hard) to correct some of that in the image but it still looks bad compared to the top one that only has minimal processing to bring up the brightness and contrast.

PS I didn’t do Rec2020 with another encoding. For now, I am satisfied with Rec2020 linear and don’t have the time or energy to experiment combinations with another encoding combination.

PPS It isn’t only detail in the shadows but also in the highlights. The highlighted region of the woman’s nose is small in the bolded combination.

Carmelo_DrRaw · September 2, 2019, 8:49am

Hi! Could you provide me the pfi files for the two images above? I’d like to have a look myself before answering in detail…

One thing that might be worth trying is the “gamut mapping” option in the colorspace conversion tool. That is, do the conversion from Rec2020 to sRGB with the colorspace conversion tool, and activate the gamut mapping function. This should bring any negative/clipped value back into the [0…1] range, in a way that tries to preserve details and colors as much as possible.

afre · September 2, 2019, 2:47pm

No PFI required. The settings are as described above and then exported to TIF. Then I simply do post-processing with G’MIC. (Sometimes, I do a bit more in raw developer but that is all I use PF for.) My computer is really slow. Took me a day(!) to do the testing.

Now, if I do exactly the same processing in G’MIC on all of the TIF, the results vary a lot. That is what I am concerned about. The Rec2020 linear no-clip + sRGB linear combination gives the cleanest result; i.e., if I didn’t make any mistakes while testing, which I believe I have in retrospect. In any case, I now know that certain combinations degrade the image.

Edit #2 Here is another comparison using [PlayRaw] Say! Synchronised-swimming Cygnets! What I did was cut negatives, brighten average to ~0.5, add contrast to get std to ~0.2, crop, brighten-contrast again.

OOC JPG, Rec2020, Rec2020+sRGBlin, Rec2020+sRGBstd, Rec2020+sRGBstd→lin (1), Rec2020+sRGBstd→lin (2)

pf-exp2v2

age · September 6, 2019, 4:45pm

uhm…I see some posterization in the shadows with rec2020 and encoding standard.

rec.2020 perceptual

rec2020 standard

Carmelo_DrRaw · September 6, 2019, 5:23pm

I need to check, but I seem to remember that the rec2020 “standard” encoding in PhF is the BT.709, which is different from sRGB. Maybe there is some bug in the BT.709 formula I am using… I suggest to stick tovlinear or perceptual for the moment.

afre · September 6, 2019, 7:06pm

Sorry, in retrospect, my comparisons from above aren’t scientific or consistent at all. In sum, the main issue is a quality one. I notice there are unexpected levels of noise and artifacts in the deeper shadows; and loss of detail, colour integrity and dynamic range in the higher highlights.

Some of it might be due to my processing acumen (and that my mind is melting under real life circumstances) and perhaps the low level processing that I am doing with PF and G’MIC. What I do know is that even a small change in the settings yield very different results. I want to figure out a combination that works reliably most of the time.

Carmelo_DrRaw · September 6, 2019, 8:36pm

What still puzzles me the most is the fact that the two sample images in your initial post have a different brightness level, which cannot come simply from the linear vs. perceptual output encoding, or from the clipping (at least if the color management is handled consistently).

Nevertheless, it is clear that the second image is lacking shadow details, for a reason that I would like to understand. It might be the same reason as the shadows posterization reported by @age, so I would like to better understand what is going on…

Thanks!

afre · September 6, 2019, 8:52pm

Sorry again, the comparison isn’t fair: the second image is a Play Raw. However, it does show to a certain extent all of the items that I listed in the “in sum” post. What the struggle is actually about (besides wb) was me trying (not very hard) to reconcile with PF’s issues and failed big time.

I know because I exported a RT unclipped float the next day and many of the issues weren’t there or were easy to resolve. Again, not a great comparison since it doesn’t retain the negative and overflow values or process the raw the same way that PF does.

Carmelo_DrRaw · September 6, 2019, 8:57pm

I will try myself to generate TIFFs from PF and RT using processing parameters the are as similar as possible, and see if I can spot the differences… however, I will not be able to give feedback before next Monday.

Anyway, that’s a very good observation.

Carmelo_DrRaw · September 7, 2019, 7:13pm

Could you provide me the raw file?

@afre I still cannot reproduce the bad result (second image) in your initial post.
Also, in the PlayRaw post you say you have used RT for the initial processing:

Is that really the case? So, is the bad shadow detail a result of a processing with PF or RT?

afre · September 8, 2019, 1:46am

Again, sorry about that. It has been a difficult and confusing 2 weeks for me. Will give it another look.

Will update this post as I go. First, I will be using 20180922_FUJ8679.raf from How to process mixed conditions lightning & getting nice colors in Darktable again. Here are the stats from the TIFs.

     raw dev       export
a00  2020          working
a01  2020          sRGB-linear
a02  2020          sRGB-standard
a10  2020-negclip  working
a11  2020-negclip  sRGB-linear
a12  2020-negclip  sRGB-standard

     min        max      avg        std
a00  -0.172453  1.19215  0.0632094  0.085194
a01  -0.301892  1.21147  0.0650508  0.089532
a02  -2.72704   1.0766   0.236226   0.175046
a10   0         1.19215  0.0632294  0.0851788
a11  -0.108966  1.21147  0.06507    0.0895166
a12  -0.984307  1.0766   0.236404   0.174759

Part of the confusion was that I was doing way too many operations at once in my testing, and advanced ones at that. I was also looking at too many aspects of the images at once and as a result might have conducted tests simultaneously rather than separately, mad scientist style. Lastly, my posts were kind of gibberish, mixing up PF and RT, etc., etc.

This time I severely limited what I was doing. I have done 2 sets below. I did not do any pixel filtering (hot pixels, in-painting), only clipped negative values to 0, applied 2.2 gamma to linear exports (working, sRGB-linear) and then stretched each set for display. It is done in the same order as the filenames listed above with a 0 prepended for the dark set and a 1 for the bright set. It is no surprise that 0a00 and 0a10, and 1a00 and 1a10, are the same images, respectively.

gmic input_glob *.tif z 0%,30%,25%,70% c 0,100% ^^[^^2,5] {1/2.2} psnr_ 0 repeat $! nm[$^>] 0{$^>,b} done / 0.3862 * 255 round out_ jpg

gmic input_glob *.tif z 25%,30%,50%,70% c 0,100% ^^[^^2,5] {1/2.2} psnr_ 0 repeat $! nm[$^>] 1{$^>,b} done / 1.05898 * 255 round out_ jpg

I decided to upload the results in a zip file instead of displaying them so that I don’t mess up the order and discourse doesn’t do anything to them. Let me know if you want anything done differently. (I know JPGs are lossy and G’MIC can alter the final ranges when saving to JPG. I chose JPGs because my upload speed is slow and I don’t want it to cut off halfway.)

0a00+.zip (28.2 MB)

afre · October 16, 2019, 10:43pm

@Carmelo_DrRaw I will try to present the problem more clearly this time. I don’t have time to present samples and numbers at the moment because I have run out of time.

Reexamining the problem again, it has to do with not clipping the negative values. I use the following combinations. I only use raw developer and export, and hope to keep a linear and energy intact workflow.

1 rec2020 linear no clipping
2 clip or blend mode
3 working profile, sRGB linear or sRGB standard
4 black point correction or not

Yesterday, on Play Raw Sigh. I blew it!, I found that the combination rec2020 linear no clipping + clip mode + working profile + no bpc yields no negative values, while the others seem to produce negative values for the same pixels. Need to verify this later.

The artifacts arise from these negative values in the dark regions when I attempt to clean them up. For Sigh. I blew it!, it affects many pixels, even when I try to do exposure compensation in raw developer.

Carmelo_DrRaw · October 17, 2019, 4:01pm

Indeed, negative values can result from the RAW processing, in the presence of noise that brings some pixels below the nominal black level. That’s why I clip negative values by default in the raw developer module:
32%20PM

I would recommend to stick with that, unless you really know why you need those negative values…

Concerning BPC, as long as you use the standard matrix colorspaces (sRGB, Rec2020, ACEScg, etc…) it should make no difference, because they all have the same black point.

BPC makes some difference when converting to profiles for output devices like display or printers, because they have a non-zero black level. In this case, the recommendation is to leave BPC activated, otherwise you might loose shadow details (see here for an explanation and practical example).

afre · October 17, 2019, 7:02pm

The rationale behind not clipping negative values is that if not all of the channels are clipped you would have the same problem as you do with clipped highlights: a shift in colour. How noticeable that shift is is another story.

Are you saying that only noisier pixels tend to get negative values? Still, clipping would only make them even more distorted, though I wonder at what point the pixel becomes non-data nonsense…

My strategy in dealing with pixels with negative values has been to interpolate or inpaint them. It has been more of an experiment really, trying to do something that people don’t normally address.

Lately, I found that my current method can often make matters worse upon closer inspection, introducing unnatural splotches, which has contributed to the artifacts that I was talking about. Another artifact inducing factor has been G’MIC preview window, which exaggerates differences. Now that I know, I will be making sure that I separate them from issues that may arise from PF.

In the case of BPC, toggling it on does indeed introduce a difference in the exports, however small, even for standard matrix colour spaces. Does sRGB linear count? Or does it only affect sRGB standard? Edit: the difference is notable between sRGB standard with and without BPC, but not for sRGB linear. Not sure if it is a bug or rounding errors.

I am thinking of leaving it off because of that and also because I can deal with that later.

PS For Play Raw t/14424, 13% of the pixels are affected by negative values. Same pixels for export sRGB linear or standard, with or without BPC. I consider that to be a lot.

PPS I also fact checked this statement:

It appears that changing blend mode to blend adds more negative values and exposure compensation doesn’t reduce them much. They are persistent.