Color space of worms

Software G'MIC
1

There has been a reoccurring complaint that G’MIC doesn’t do color management and that it is hard coded to work within the sRGB space. It isn’t a cosmic can of worms for me since I typically use other apps to do the heavy lifting. However, it can be tedious to switch between apps to see the results of the processing. (I use CLI gmic BTW).

Shortly after the passionate discussion in “More on LCH and JCH”, I decided to investigate the latter part of the complaint for myself. It was easy to determine whether a stdlib command was coded with a gamma-encoded sRGB by looking for the srgb2rgb and rgb2srgb commands. However, I was also curious about what sort of RGB rgb2* and *2rgb were.

A conversion that I would regularly employ is rgb2lch. When I do this to an image that is 0,0,255 (blue), I get a set of LCH values that reflect those that come from linear sRGB 0,0,255. When I try to convert from linear Adobe RGB 0,0,255, which does ≠ linear sRGB 0,0,255, I should get different LCH values, but I obviously don’t since G’MIC isn’t aware that it is a different RGB space and rgb2lch is capable of only a certain type of conversion; viz., linear sRGB → LCH (either D65 or D50).

I haven’t tried this conversion (using an online converter) broadly across different colors but, for Adobe RGB 0,0,255 to sRGB, only L and C change but not H . But it is quite possible that H could change as well due to Welcome to Bruce Lindbloom's Web Site. I hope I typed this out correctly. It can be confusing when talking about this stuff.

Anyway, this brings me to a place where I not only have to let another app do the color management but I also would have to do color conversions like rgb2lch outside of G’MIC, which is confusing in itself because the ranges and / or units in C and H can be different. I am not here to criticize G’MIC’s development but I would like to know how I ought to tackle this problem moving forward. Thanks.

1 Like
2

What I would suggest about this:
If the hardcoded srgb2rgb conversion does not fit your needs, then probably it’s good to redefine it. It is a custom command, so defining your own srgb2rgb is possible and will override the previous definition in the stdlib (same for rgb2srgb).

We can even imagine creating a command srgb2rgb that could manage different types of conversions, depending on the value of a global variable $_srgb_type for instance:

rgb2srgb: 
  e[^-1] "Convert color representation of image$? from sRGB to linear RGB."
  v - 
  if {['$_srgb_type']==['custom']} # custom
    f "sval = i/255; val = sval<=0.12345?sval/12.34:((sval + 0.123)/(1.234))^2.3; cut(255*val,0,255)" v +
  else # default
    f "sval = i/255; val = sval<=0.04045?sval/12.92:((sval + 0.055)/(1.055))^2.4; cut(255*val,0,255)" v +
  fi

This way, you will be able to manage all the conversion formula you want. All color conversion functions are custom commands, so we can imagine doing the same with other types of color conversions.