Input/output color profile support has a clunky UI

[Entropy512]

This is connected to/impacts #5575 among others

The UI/UX for input/output color profile handling is really clunky. Rather than specify gamut and transfer function for output, the user must go to the ICC profile creator, generate a file, save it, then manually move it to a location where it will be used for output (as the default directory for output profiles on Linux is not normally user-writable).

Also, transfer function should probably be overridable in the batch process dialog where output file format is selected, as transfer function is often tied to output file format (e.g. JPEG is often gamma-encoded as is 8-bit TIFF, but 16+ bit TIFF is usually linear)

Similarly, for input, the default location saved to by the ICC profile generator is difficult to reach in the file dialog on Linux as it is in a hidden directory under $HOME ($HOME/.config )

Long-term (6.0?), a user should be able to select common gamuts and transfer functions from the UI without generating a custom ICC profile and then pointing another component of RT to the resulting file.

Short-term, usrICCDir in https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/iccstore.cc#L450 should perhaps be renamed sysICCDir (as it is where system-installed profiles are located), and iccstore should additionally look in options.rtdir/profiles/output like the existing code that looks at profiles/output for output profiles. I'm going to take a crack at this later in the week.

(Is there a reason that input profiles are pulled from the system store but output profiles are pulled from an RT-specific user location?
Also is there a reason that the ICC profile generator defaults to saving files in a location not used for input OR output profiles in iccstore?)

[Entropy512]

Some aspects of this may be a dupe of some of @Beep6581 's comments related to UI in #5518

[Thanatomanic]

I agree that it would be very convenient to skip the ICC profile step and have the option to generate them on the fly.

We should probably also reconsider the TRC we embed in our profiles by default. Currently, these are always the same, but Rec2020 or ProPhoto or sRGB standards expect different TRCs. Users probably don't know we don't respect that.

[Entropy512]

Yeah, Rec2020's default TRC is the same as Rec709, which I don't think we support at all.

The majority of content isn't even that - it's Rec. 2020 primaries combined with HLG or PQ TRC.

Which has me wondering if HLG's behaviors (gamma at the low end, log at the high end) fit into one of the defined parametric TRCs in LCMS2 in order to allow RT to output HLG...

[Entropy512]

There's probably an issue somewhere for supporting AVIF output, and that has an alternative method for specifying common primaries and TRC:

https://github.com/AOMediaCodec/libavif/wiki/CICP

Sanely supporting CICP would be highly beneficial and the UI/UX for supporting CICP output in appropriate formats could automagically generate a corresponding ICC profile for non-CICP-capable formats.

That's definitely a 6.0 item though!

[Entropy512]

Pure gamma is absolute garbage for 8-bit (JPEG) outputs, and probably still substandard even at 10 bits. The reason it is (and why nearly all standards have a linear segment) is that pure gamma rounds down to 0 for multiple code values.

https://github.com/Entropy512/I2C_RGB/blob/master/firmware/gammacurve_8to12.h - that's an old example where I did a pure gamma. Look at how many input values round to an output of 0, and how many input values round to an output of 1. This is wasteful of input code values and is why Rec709 and sRGB both do NOT use pure gamma.

[Entropy512]

Decoding gamma of BT.709 is 2.4 pure gamma

So what? Please stop dragging this discussion way offtopic.

Who cares what the decoding gamma is, if it is different (I have not seen any citations from reputable sources stating this) - OUR OUTPUT PROFILES ARE FOR ENCODING.

For the most part the only real use case for Rec.709 transfer on output is because ffmpeg doesn't get compiled with zscale by default AND it is not color managed, so there's benefit to doing the transfer function internally within RT - in which case the output color profile is ignored by the target application and the only reason to set it is to ensure that an application which assumes a particular transfer function has the data already encoded with the appropriate function.

While it is in theory possible to use an arbitrary ICC profile on input (I have done it to create HALD CLUTs for S-Log2 inputs), this use case is rare -the vast majority of inputs are linear Bayer-mosaiced raw data.

[Entropy512]

Reading it in more detail, that only applies to the design of reference monitors. It has no applicability to color management for systems that have digital input and output. At the best case, it MIGHT have applicability for DisplayCal since that is one of the few cases where open source software might have ANY insight into the low-level behaviors of a particular display. It is most definitely not relevant to a discussion of user interface deficiencies with respect to connecting the ICC profile generator to anything that uses those profiles, which is what this issue is intended to discuss.

RawTherapee is an image processing solution, it is not a solution for internal electronics of LCD or OLED displays. It is not a monitor calibration solution, please go use DisplayCal and if you're not happy with how it is functioning, go bother them and stop bothering us.

Please stop dragging this offtopic. I'm willing to deal with the occasonal minor tangent (after all I've done that myself), but this is the second time in as many weeks you've dragged an issue way offtopic in ways completely irrelevant to the issue you're spamming.