Hi Dave,
Dave Neary wrote:
Yes, this is what was discussed at the conference, with one important difference. We don't convert back to AdobeRGB or whatever at save time, we simply save the working image data, with the sRGB color profile.
OK - I agree that converting back to the original space is in most situations unneccessary.
I see your point. Perhaps there could be some kind of pre-loading where we apply the color profile in floating-point, and quantise afterwards? Just thinking out loud, this may be completely unfeasible.
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. For me, seeing as 8-bit RGB is already inadequate for smooth subtle gradients (cf. my gradient dither patch of a few months back) this is unacceptable. I concede, however, that not everybody will see it this way!
How does this fit in with display calibration? If we work on the unmodified
image data as we read it in, then on what data should the monitor's calibration
profile work during projection? Should it work on the raw RGB data, or should we
apply the input profile at projection time? Would a color profile be a per-layer
thing?
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. If instead you're using the unmodified RGB data from the original file, you just use an Image Profile -> Monitor Profile transform instead. (If the source image has no profile of it's own, then you can just tag it with a default profile.)
In short, projection your way looks like this:
Image (Source Profile) -> Internal data (sRGB) -> Screen (Monitor Profile)
Two transformations, first from Source Profile to sRGB, secondly from sRGB to the Monitor's profile. This would work very nicely if the internal data could be stored in 16-bit or float precision. Because it can't we lose precision.
My way looks like this:
Image (Source Profile) -> Internal data (Source Profile) -> Screen (Monitor Profile)
Just one transformation directly from the source profle to the screen profile, and more importantly, no destructive change to the raw image data.
I don't think it would be feasible to make the profile a per-layer thing. I personally consider per-image to be the best solution, as long as there's some way of warning the user if they're copying and pasting between images with mismatched profiles.
I think these are the kinds of issues that Sven thought about before, and they
make adding color management considerably more complicated. I think that the
simplicity of applying a color profile on imput and not having to worry about it
in the rendering code outweighs the down side of any quantisation that occurs.
I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. 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.
I think this is probably a very bad idea.
Could you expand on why you think this? Confusion? Difficulty of implementation? Something else?
All the best, -- Alastair M. Robinson
_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
