[SOLVED] Suggestion: IM7 colourspace CLI/API

[NicolasRobidoux]

I would like to suggest that IM7 use an ICC/colourspace interface (CLI/API) somewhat similar to NIP2/VIPS (see, e.g., http://libvips.blogspot.ca/2012/01/how- ... olour.html).

Specifically: Pick a "standard" anchor space. (Actually, more than one is probably needed, to deal with alpha and things that don't fit like color separation, multi-band images etc. In addition, when working in 8-bit, it may be a good thing to specifically have an sRGB and a "linear" RGB anchor space, which are the same except for that when converting to/from other colourspaces shortcuts are taken. Allow me to ignore these complications.) My first choice would be linear RGB(A), but sRGB(A) v2 would be acceptable. (NIP2/VIPS uses XYZ through Lab variants but I don't think this is a good choice for IM. GEGL/babl uses linear light RGB(A).) I understand this does not cover all possibilities. Unless otherwise "informed", or the image just does not fit into RGB(A), IM7 will pretend that what you have is just that. In the following, I assume the anchor space is linear RGB(A).

To convert into linear RGB(A) (or something understood as linear RGB(A)) using an ICC/ICM/whatever profile:

Code: Select all

-import PROFILE_NAME or LOCATION

with some way of toggling "use the embedded if there is one, and otherwise try some reasonable defaults until you find one that imports without an error", for example:

Code: Select all

-import embedded

or

Code: Select all

-import default

(which would consider the embedded profile to be the default if there is one).

To convert out of linear RGB(A) using a profile:

Code: Select all

-export PROFILE_NAME

with some way of toggling "export using the profile used to import this image, and otherwise try some reasonable defaults until it exports without an error", for example:

Code: Select all

-export embedded

or

Code: Select all

-import default

(since often that profile with be the import profile).

To convert to a different colorspace (default assumption being that it is from linear RGB(A), but otherwise going through linear RGB(A) to convert between the relevant pairs):

Code: Select all

-colorspace COLORSPACE_NAME

(This is pretty much what IM7 does already.)

To "inform" IM7 that what is in the image belongs to some colorspace without doing any import/export/conversion:

Code: Select all

-tag COLORSPACE_NAME

(This is pretty much what -colorspace did before IM7.)

No need to explain to me why you don't like this idea if you don't. I have not studied this issue carefully, and I'm not doing this to "win".

[NicolasRobidoux]

In the end, what you want is some way of specifying where you are, and a way of converting from where you are to where you want to be, providing information about how it's to be done and having reasonable defaults kicking in when they should.

And, ideally, when there isn't a direct conversion available between where you are and where you want to be, automatic conversion through one or more "anchor colorspaces".

[NicolasRobidoux]

BABL/GEGL has a careful way of dealing with colorspaces and profiles (information courtesy of Øyvind Kolås a.k.a. pippin):

<pippin>nicolas: dragging CIE Lab into the mix for gegl/babl is not accurate...
There is support for it but the actual reference/canonical format used by babl to verify accuracy of any transformation and fastpaths.. is linear light RGBA with 64 bit doubles as precision
All GeglBuffers are tagged with the specific BablFormat the pixels are stored in
babl provides guaranteed regression tested, runtime profiled fast paths for conversion between any pixelformat that babl supports.
http://gegl.org/babl/
<nicolas> I'll summarize. And yes, I did not discuss the fact that really what you need is pairwise conversions. It's just that a reasonable starting point for such is going through one or more anchor spaces.
<pippin> nicolas: babl is not even about pairwise conversions,. babl provides you with a grammar to construct any pixel format given data types and a color model and babl can synthesise conversions between them, or use fast paths that are verified to have the same result as the synthesized reference conversions
babl only synthesizes conversions when it is the last resort
When it can string together a chain of registered fast paths that produce the same result in less time than the synthesized version,. the single or chain of fast paths is used instead
You _can_ add ICC backed Color models to babl... but it is likely preferable to convert to sane well defined color spaces on import and on export and then use the strongly managed spaces that babl provides internally
nicolas: the point of babl is that it permits dynamically add support for mor esoteric formats - and to add optimized conversions only for conversions that are used very frequently

(My original post had a factual error RE: GEGL/BABL which I fixed following the above chat.)

[NicolasRobidoux]

...
And, ideally, when there isn't a direct conversion available between where you are and where you want to be, automatic conversion through one or more "anchor colorspaces".

For example, -import and -colorspace should ideally be aware of each other and create a fast path when it makes sense. That is: If you import with sRGB and convert to colorspace sRGB (with the same rendering intent), the two operations should be merged into a plain read. And, if the rendering intent are different, the conversion should ideally not go through linear RGB, at least when low bit-depth is used.

(I understand I'm now making things way more complicated. Maybe I should have left my original post alone.)

[NicolasRobidoux]

One more thing: -import, -export and -tag should have -intent modifiers.

[NicolasRobidoux]

Re-reading the VIPS blog entry I mention at the beginning of this thread, I have another possible name for

Code: Select all

-tag COLORSPACE_NAME

To tag data as belonging to some colourspace, one could use

Code: Select all

-interpretation COLORSPACE_NAME

This, of course, corresponds to the old IM use of

Code: Select all

-colorspace

[anthony]

Seems overly complex, with many options.

The main problems with the existing one is -profile handling and 'setting a read colorspace' for some image codecs.
Tha later is also being done by -colorspace but it really should be a separate setting.

[NicolasRobidoux]

I step away from this for a few days, and let this sift itself a bit. And then I'll try to see what simple change(s) would make things better, and still leave room for future extensions.

The reason I took vips/nip2 and babl/gegl as my models is that these systems were built with colour management front and center from the get go.