Color space conversion

Software G'MIC
1

Checking to see if I got this right:

  1. The default output color space of dcraw is sRGB.
  2. To get to LCH, I would need to do -srgb2rgb then -rgb2lch.

Also,

  • When would one use -rgb2lch8?
  • Do I need to worry about normalization/cutting before/after conversion?
2

dcraw and sRGB
The usage notes don’t say that sRGB is the default output color space (-o [0-6] Output colorspace (raw,sRGB,Adobe,Wide,ProPhoto,XYZ,ACES)); but Coffin’s [website] (https://www.cybercom.net/~dcoffin/dcraw/dcraw.1.html) does.

G’MIC and LCh
I reread the documentation. Looks like this is what I should do
gmic -sp lena -rgb2lch8 -split c -doSomething -append c -lch82rgb

If this is correct, input ≠ output when it should be; i.e.,

gmic -sp lena -o lena.png
gmic -sp lena -rgb2lch8 -lch82rgb -o lena_rt.png
magick compare -metric phash lena.png lena_rt.png null: 2>&1
0.0485551

  • When I use a RAW processed by dcraw, the round trip cost is much higher; e.g., [PlayRAW] First snow in Canadian Rockies yields 1.35252 (non-linear 8-bit sRGB ppm) and 1.47667.(linear 16-bit sRGB ppm).

In comparison

magick logo: -colorspace LCH -colorspace sRGB logo_rt.png
magick compare -metric phash logo: logo_rt.png null: 2>&1
0

  • It is also 0 if I use lena instead of logo:, or the ppms.

What is going on? Thoughts? @David_Tschumperle and others.

3

Command -rgb2lch8 normalizes the output image to have range [0,255]. It is only useful when you plan to do some intermediate process on it using a software that does not support floating-point images for instance (e.g. GIMP with version 2.8). If you plan to stay with G’MIC until the end of the processing, then -rgb2lch is probably just fine.

Depending on the type of output you want to generate, yes. If you just want to apply some kind of processing in Lch, then goes back to sRGB afterwards in the same G’MIC pipeline, probably not.

4

In a perfect world, yes, it should be the same. But, due to limited numerical precision (32bits floats used in G’MIC), the result may differ a little bit from the original image. That’s true for almost all non-trivial color space conversions (I suppose RGB<->CMY is simple enough not to lose any precision, but that’s probably the only one).
If you use -rgb2lch instead of -rgb2lch8, you’ll probably get a slightly better precision though.

I’m not sure why ImageMagick returns 0, I guess this is maybe because it detects nothing is done between the two color conversions. Or maybe it is using double-valued (64bits) images instead of floats.
In any case, having a perfectly reversible image transformation is almost impossible when the transformation is complex enough (this is true for all theoretically inversible image processing operators, e.g. Fourier transforms, …).