Hi Alastair,
Alastair M. Robinson wrote:
> Dave Neary wrote:
> Assuming we're using lcms, the internal conversion will be applied in
> full precision - the problem is that the destination data, by necessity
> of the GIMP's current limitations, must be 8-bit RGB. Converting 8-bit
> RGB data from one profile to another will not be a 1:1 mapping, so some
> colour information will be lost - I haven't yet conducted empirical
> tests for the severity of this effect, but I suspect that the 8-bit
> source data will be downgraded to something like 7 - 7.25 bit.
I may be misunderstanding things, but if the conversion from the
source colourspace to sRGB is done in lcms losslessly, then all
we're losing is the out-of-gamut colours from the colourspace
conversion. And, of course, the cost of discarding precision in
the data we get after the application of the profile. But I think
we still get the full 8 bits of data (they may not have the exact
colours in the source file, though).
> First of all, a profile on its own is worthless for rendering accurate
> colour - they must be used in pairs, source and destination, to create a
> colour "transform". Thus, if the GIMP is using sRGB internally, then at
> projection time you feed the RGB image data through an sRGB->Monitor
> Profile transformation.
Yes, but since this profile is applied once, on the projection
drawable, as the final step, its application doesn't present any
problems. But I see what you mean - we can go from the source
colourspace directly to the monitor's with one transformation.
This, however, poses problems for say the checkerboard pattern
(which will be transformed differently with different source
profiles), and for any occasion where different profiles get
mixed (cut & paste operations, for example).
I would have thought you would still have to have the 2 profiles
applied though... I'm sure I just don't know how lcms works.
> I'll conduct some tests some time and try and figure out just how bad
> these quantisation errors could be.
Great - quantitative data will really help.
> I can certainly see the appeal of a
> simplistic approach, but if a little extra effort can prevent
> unnecessary destructive changes to the image data, I think it's worth
> exploring.
Sure.
> >I think this is probably a very bad idea.
>
> Could you expand on why you think this? Confusion? Difficulty of
> implementation? Something else?
The "this" was referring to a passage that you cut - I think it
is probably a bad idea to have lots of image data in different
colorspaces. I can't put my finger on why, but I just have this
feeling that we will end up with a certain amount of confusion
when it comes to colour stuff (as you pointed out, the colour
picker is a good example, so is cut & paste).
I'm more than willing to defer to the many experts we have,
though. I wish I knew enough about the subject to consider myself
one.
Cheers,
Dave.
--
David Neary,
Lyon, France
E-Mail: bolsh@xxxxxxxx
CV: http://dneary.free.fr/CV/
