Thanks for the additional input, James.
I'll be honest - that individual channels may go negative while the overall
luminance remains positive represents a new level of awareness for me. We
strive to get our color-management right and up to now I was considering
negative values (observed to be very small in absolute value) as a bug or side
effect of processing inaccuracy (we know Photoshop doesn't always get things
perfect).
We *haven't*, however, been using the cmsFLAGS_NONEGATIVES flag as we never
observed negative values out of LittleCMS transforms. We use LittleCMS to
convert to our internal working space... It's possible that without the
clamping code our software will just work. We already handle HDR (values
greater than 1.0).
With this new level of understanding I'm going to look over whether the reasons
we had been clamping negative values even still exist - it's possible because
of my misunderstanding that they were only needed during development before our
color-management infrastructure was fully implemented and matured. We did not
start out using a floating point internal representation at first, though we do
now.
Thank you all for prompting me to revisit this.
-Noel
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
