I am building a 3D LUT to map LAB values back to RGB using a texture. For this (texture lookup) to work I need to normalize the Lab values in the range 0.0...1.0.
I think indirectly you gave me the answer: by slicing the target RGB color space I can find the actual min & max a* b* values - and use that for building the LUT / texture lookup. I guess this is much better than hardcoding any a*b* range. If I choose ranges to small, I clamp, if the ranges are too large, I loose precision during the linear interpolation. Makes any sence to you? Regards mark On 15.02.2011, at 13:21, Kai-Uwe Behrmann wrote: > Am 15.02.11, 12:59 +0100 schrieb Mark: >> I'm trying to find the ranges of a* and b* so I can normalize Lab values to >> 0.0...1.0. >> For this I sliced several RGB color spaces (srgb, adobe rgb, prophoto, wide >> gamut) and printed out the resulting Lab values. >> >> For "wide gamut" I am seeing a* values as high as -211 and b* of +166. >> >> Digging into the LCMS source code I saw the "integer encodable" ranges for >> a* b* are defined as >> #define MIN_ENCODEABLE_ab4 (-128.0) >> #define MAX_ENCODEABLE_ab4 (127.0) > > Thats the typical value range. > >> Does that mean that "wide gamut" contains RGB values that are outside of >> the max encodable ICC a*b* ranges (for integer encoding) ? > > Thats normal up to virtual colours which are not physically reproducible. > >> So, now I am a bit lost how to best convert a* and b* to the ranges 0...1.0 > > Given that the range of 0...1.0 is tailored to RGB, you might ask yourself > what to do with pure chroma channels in *a and *b. Present in a UI? pass > through RGB workflows with accoring tools? > >> I will not be using color spaces largen than adobe rgb (which fits fine >> inside MIN_ENCODEABLE_ab4 and MAX_ENCODEABLE_ab4. > > That value use just the limit of the integer representations. For floats such > a limitation does not exist. The gamut can well exceed that range and colours > can fit into that range, which will physically not exist. > >> So I'm thinking of just normalizing using these limits and clamping as >> necessary. > > Why clamping? The whole point of floating point processing is not to clamp, > except maybe for final display and print. > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management www.behrmann.name + www.oyranos.org > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
