RFC: Gamma corrected pipe input scaling for rgb images

[jenshannoschwalm]

Non-raw images can have gamma corrected data as input possibly leading to bad results while we do the initial scaling. This scaling happens when generating the mipmap via _init_f and when inserting data into the pixelpipes.

What we do now:

• we test for the image having exif data as sRGB or AdobeRGB.
• the colorin module does a much better check than exif data and possibly sets the profile type to any RGB mode. We keep track on this when setting the input profile and possibly change the image->colorspace (making sure to leave the exif checked data as they are).
• dt_iop_clip_and_zoom() got an extra gboolean parameter gamma, if that is true the interpolation is encapsulated in rgb->linear and linear->rgb conversions.

This results in improved data visualizing for all pipes and data taken from the preview pipe.

Reminder:

1. As this is only effective for non-raw images we should likely stay in linear space and let colorin module handle this.
2. Should we avoid the conversions for upscaling?

---

This has been itching me for quite a while - since #13682 #13335 and #13682. One part of those issues has been solved by 6b18bae having final-scaling still in linear space.

The second problem discussed and demonstrated in the old issues is the initial feeding of non-linear data into the pipes.
Here are some images to be tested:

or the large nasa image https://commons.wikimedia.org/wiki/File:Earth%27s_City_Lights_by_DMSP,_1994-1995_(full).jpg (scroll down a bit and choose full image).

For me this is the first part of color-related stuff for 5.6. @kofa73 is likely working on improving white balance and i will take further care on colorin ...

@mediatechnologic started the discussion (i hope you are still reading and would be able to compile & test) @TurboGit as pening #13682

[ralfbrown]

As this is only effective for non-raw images we should likely stay in linear space and let colorin module handle this.

+1

I've also proposed in the past having colorin output in RGB space instead of Lab, since with scene-referred processing the next module in the pipe will nearly always expect RGB and thus trigger a Lab->RGB conversion step. Eliminating the conversion would remove some floating-point roundings as well as shaving a couple milliseconds off the processing time.

dt's architecture allows modules to vary their input and output color spaces according to current conditions, with the pixelpipe handling any necessary conversions if there is a mismatch with the previous/next modules.

[jenshannoschwalm]

Absolutely right. Working on that, pr following later but soon.

Although the situation in colorin input data is more complicated.

[TurboGit]

I agree that the back and forth superfluous conversion between Lab & RGB should be avoided. That's would be a nice improvement in speed and image quality.

[TurboGit]

Works for me, thanks!

[jenshannoschwalm]

Force-pushed an updated version.

1. Feeding crop&scaled data into a pipe is now done via OpenCL code if memory requirements are met. This means a performance gain for non-raw images even with gamma correction.

I agree that the back and forth superfluous conversion between Lab & RGB should be avoided. That's would be a nice improvement in speed and image quality.

Absolutely. But this can't be done here, that's all in colorin module.

I checked again if we could do the conversion in these parts of the code at least for non-raws, unfortunately not without a lot of messing in the code in all modules that might be in the pipe before colorin.
At least the new OpenCL code makes non-raws somewhat faster for larger images.