RSS/Atom feed Twitter
Site is read-only, email is disabled

A possibly easier way to AnyRGB

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

A possibly easier way to AnyRGB Elle Stone 02 Jun 17:07
  A possibly easier way to AnyRGB Elle Stone 03 Jun 20:32
Elle Stone
2019-06-02 17:07:37 UTC (almost 5 years ago)

A possibly easier way to AnyRGB

Hi All,

Currently GIMP uses hard-coded sRGB primaries for many operations, thereby producing wrong results when editing images in RGB color spaces other than sRGB. Also currently GIMP color pickers only pick colors, only allow dialing in colors, only show out of gamut indicators colors using sRGB. Well, it's ridiculous to be editing an image in ClayRGB (aka AdobeRGB) and be told a green color is out of gamut, when it's only out of gamut wrt sRGB.

Based on testing the space invasion for GIMP-2.99, it seems fairly massive changes are required to implement "AnyRGB" one function at a time. But maybe there is an easier way to implement AnyRGB.

*My current workaround for GIMP-2.10:*

Currently I compile GIMP-2.10 in multiple prefixes, one prefix per RGB color space that I actually want to edit in. These prefixes are easy to set up:

For GIMP, only two files need to be modified:

* libgimpcolor/gimpcolorprofile.c * libgimpcolor/gimprgb.h

For babl, only one file needs to be modified:

* babl/babl-space.c

If anyone wants to set up a ClayRGB prefix, patches can be downloaded here - required modifications for other ICC profiles should be obvious:

https://ninedegreesbelow.com/files/GIMP-ClayRGB-prefix/GIMP-ClayRGB-prefix.zip

This sort of patch merely exchanges one hard-coded color space for another.

*A proposed alternative solution:*

What about writing code that gets the primaries from the user's chosen RGB working space, and then conveys those primaries to the relevant three functions in libgimpcolor/gimpcolorprofile.c, libgimpcolor/gimprgb.h, and babl/babl-space.c , thereby replacing hard-coded sRGB primaries with "AnyRGB" primaries?

"AnyTRC" would need to be considered separately. However, from the point of view of photographic editing, the only really useful TRCs are linear and perceptually uniform. The sRGB TRC is only approximately perceptually uniform. A better hard-coded choice would be the LAB "L" TRC. Though maybe babl already has a way to handle "AnyTRC"?

Best, Elle Stone

https://ninedegreesbelow.com
Color management and free/libre photography
Elle Stone
2019-06-03 20:32:34 UTC (almost 5 years ago)

A possibly easier way to AnyRGB

On 06/02/2019 01:07 PM, Elle Stone wrote:

*A proposed alternative solution:*

What about writing code that gets the primaries from the user's chosen RGB working space, and then conveys those primaries to the relevant three functions in libgimpcolor/gimpcolorprofile.c, libgimpcolor/gimprgb.h, and babl/babl-space.c , thereby replacing hard-coded sRGB primaries with "AnyRGB" primaries?

Actually four functions, one each for linear and perceptual "sRGB" in libgimpcolor/gimpcolorprofile.c, which would be rewritten to use "User-chosen RGB primaries". Plus the LUMINANCE defines in gimprgb.h would need to be replaced with something like "get_Y_values_from_user_chosen_RGB_primaries". And the current "sRGB" in babl/babl-space.c likewise would need to be replaced with "User-chosen RGB".

The user's chosen RGB profile's RGBXYZ matrix would need to be conveyed to these functions every time the user-chosen color space was changed.

There would of course need to be a couple of new functions for making "sRGB-built-in fallback color space" for assigning to images without any embedded ICC profile, and for use when users open images that aren't actually in RGB matrix working spaces. Though it would be nice to allow users to specifiy which actual color spaces to use in these two case, with built-in sRGB as the default fall-back color space.

Anyone? Comments? Possible? If not possible, why not?

Certainly babl knows what color space an image is in, and so does GIMP. So why can't this information be used directly, instead of by writing "space" functions that live alongside "sRGB only" functions?

Best, Elle