[Development] Color Management support in Qt 5?

[Alessandro Portale]

Allow me jump into this topic to contribute to its liveliness :)

The term "Color Management" has been used in different ways here on
the list. Lately, it was about how to blend images in a non-linear
color space. That is IMHO perhaps a small and not "that typical" part
of what color management means for imaging applications.

I like the idea of re-starting small, and quite a bit of what was done
in Nokia times can certainly be re-used.
What if Qt started by simply *enabling* color management. I.e. giving
access to the information that an application needs to perform color
management tasks itself. In a much later iteration Qt could perhaps
perform color management operations. Qt should IMHO avoid automatic
color management under the hood, especially without providing API to
control it.

Milestones could be:
1) QImage[Reader] gives access to image color profile. Either whole
profile or just an identifier in case of standard spaces such as sRgb.
2) QScreen gives access to the current display color profile for that
specific screen.
3) There are notifications (signals?) when the a window changes to
another screen, or when a screen profile is changed in the system.
4) Same as "2" but for installed Printers on the system.
...
99) QColorEngine can do color conversions using an input profile, a
source Image an output profile plus different parameters.

Ideas? Kai-Uwe, what color management feature (or enabler) are you
missing most in Qt?

Br,
Alessandro


On Fri, Nov 8, 2013 at 11:53 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 08.11.2013 14:17, schrieb Sorvig Morten:
>>
>> On 07 Nov 2013, at 12:48, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>>
>>> Detecting a colour space and converting to device colour spaces is around the same amount of developer time as for special casing sRGB. Detecting sRGB among hundrets of ICC profiles is not trivial or fast, while such a detection does not matter in a generic colour managed environment.
>>>
>>> EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is a thiny bit of grafic processing, which is needed for handling colour space conversions.
>>> The spec is clear to not doing anything about dislpaying sRGB images on a monitor. So this OpenGL extension does not help much with colour management.
>>>
>>> Short term support for sRGB only would make Qt a pretty limiting choice for many colour managed applications.
>>>
>>> IMHO, limiting support to RGB in a first development stage is a more sound target.
>>
>>
>> Hello!
>>
>> You did not give me much wiggle room with this reply - did you simply want to end the discussion?
>
> Oh, I joined the discussion to keep it alive. Sorry, if my reply was
> perceived in a different mode.
>
>> For example, the existance of EXT_framebuffer_sRGB supports my argument that limiting support to sRGB will be simpler, but you don’t mention it at all.
>
> As I mentioned, the GL extension does no complete colour space
> conversion as it handles only gamma and not colour primaries. It is
> intented for memory storage savings, which are unrelated to any colour
> management concerns. In fact a small shader can do a similar gamma
> correction. On the other hand a different shader could do as well a full
> colour space conversion. sRGB is other than for storage not of much value.
>
> Nonetheless sRGB is traditionally used as factual blending space. But
> e.g. wayland devs think seriously around linear gamma blending spaces,
> which give lesser artefacts.
>
> If one plans for mobile only, then a single blending colour space with
> low bit depth storage might be an option. But I wanted to point out,
> that this appears to me like a serious regression on desktop. The
> implications are certainly up to decide by the Qt community.
>
> kind regards
> Kai-Uwe Behrmann
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development