Hi John,
Hi Bob,
Thanks a lot for your advises & feed-back.
Bob:
> Assuming that the input images are not in a consistent color space,
then they should
> be color managed before the compositing step or else the result is
indeterminate.
They are. Input images are in the Working Color Space. The extra color
matching I'm speaking about, is for screen rendering (several screen
involved).
> Regardless, premultiplied color does not seem to make a lot of sense
with a color management
> system since color perception varies with intensity and the colorspace
may not be linear across
> the color channels.
Absolutely. This is highly questionable as John noted (see below).
However, my primary goal is to manage it correctly for binary
transparency (fully opaque and fully transparent). I do not care so much
about blended edges where alpha could be ]0..1.0[ or if my customer
choose to deplace the opacity cursor (then, the user will visually
appreciate the new colors).
But if some code in littleCMS supports linked alpha of 0 and 1.0 only
(and not the intermediaries) that would be weird ;-)
John:
> Perhaps you could move your colour management after the compositing
step? So have RGBA
> with pre-multipled alpha as your working space, composite down to a
single plain RGB layer
> for painting to the screen, and do a final pass with lcms on that,
just before sending it out.
Yes, this is possible but less efficient for my case. I used this scheme
in the previous version of my software.
Let me explain quickly my graphic pipeline engine. It is something like :
|various Layers (Working Color Space)|
--> <composition>
--> |Accumulation buffer for all layers|
--> <cmsDoTransform (to screen n)>
--> |final composition with overlay tools effects
+ background, in screen color space|
--> <final blit to screen>
Initially, all my images are color matching into a Working Color Space
(which can be something like sRGB, AdobeRGB or any other RGB standard
color space).
Sometimes, my clients are using 2 screens and each one has obviously a
different icc profile.
All the color matching I want to do on premultiplied alpha buffers is
only for screen preview (from my working space to one screen color space).
Quite often, my clients (textile designers) are zooming a lot (X4 or X8)
to clean-up or tiling their pattern.
In this case, I have my accumulation buffer that I want to color match
which is ~4x4 smaller than the one visible on screen.
In this case, color matching can be 16 times faster (if there is not too
much slow down because of premultiplied format).
If the user zoom out, my buffer is at the same size than the screen.
If is also very frequent that my clients are editing some small objects
(like sprites) and repeat them on the design. More than 50% of the
screen can be fully transparent and no color matching is required for
that (optimization)
Finally, I have a final buffer (same size than screen) where I draw the
background (a solid color or the usual grey and white pattern which
represents transparency). I add the accumulation buffer and finally, I
draw all the tool stuff which can be an animation (like a selection ant
path or anything). This way, there is no need to recomputed the
accumulation buffer during animation.
I can not move the screen color matching step at an earlier place
(having each layer in screen color space) because it is incompatible
with the gamut warning feature (will be blend as any other pixels).
If I move the screen color matching at the very last step of the
pipeline, it will be very unoptimized.
> Compositing device-space images seems possibly questionable anyway.
Won't things like gamma,
> which you won't have control over, affect the result?
This is absolutely true and for that, I don't have a proper answer/fix
except the fact that my clients are mostly using binary transparency
(fully opaque or transparent). My goal is also to move to GEGL in the
future to manage this correctly.
Same problem with gamma even for zooming out... I read some time ago the
very interesting paper about Gamma error in picture scaling
(http://www.4p8.com/eric.brasseur/gamma.html) and it depressed me ;-)
-------
Thanks again for all your inputs. I can easily understand that my needs
could be a little too much specific to change anything to littleCMS but
if the change is not technically too difficult, is there someone who
could guide me in the source code. So I could make a try and bench it to
know if such hack is viable instead of doing such process :
full premultiplied alpha --> convert to unlinked alpha -->
cmsDoTransform --> convert back to premultiplied alpha
I will also try to investigate the other options (moving the color
matching step where there is no premultiplied input), but I'm not sure I
could keep the same performances.
Regards
Seb
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
