On 11/03/2016 05:59 PM, marti.ma...@littlecms.com wrote: > > > Hi Elle, > > You are right, gamut check was not intended to work in unbounded mode > and also, due to the way it works, it needs a space perceptually uniform > to perform good. This is because gamut check uses a LUT driven by CIE > L*a*b* to hold the distance of each color to gamut boundary. Works well > for traditional 8-bit imaging but definitevely not for linear spaces > close to XYZ. > > This is not a bug, but a limitation due to the algorithm used. I take > two action items: fully de-activate gamut check on unbounded mode and > document the limitation. Will happen in 2.9 > > Thanks for reporting > Marti. >
I understand that the current LCMS gamut check was designed for use with 8-bit integer perceptually uniform RGB source color spaces, and specifically for cases where the destination color space is a printer profile. But image editing and soft proofing needs have changed as the underlying technology has opened up new editing and output possibilities: * We are no longer limited by our hardware or software to editing 8-bit sRGB images. * Various softwares that use LCMS also support high bit depth floating point editing. * Many people choose to edit at high bit depths in linear gamma color spaces to take advantage of radiometrically correct color mixing. * LCMS makes possible ICC profile conversions that don't clip out of gamut channel values, and editing softwares are being rewritten to remove clipping code to allow HDR editing, and this is wonderfully useful even though it has caused issues for existing LCMS gamut check algorithms. * Printers are now taking 16-bit images rather than 8-bit images. * The output space to which a person might want to soft proof a given image might a printer, an electronic display device, or to sRGB for display on the web, or even all three. So perhaps it would be possible to augment the current LCMS gamut check algorithm with new algorithms that might produce more accurate gamut checks for people editing high bit depth floating point and/or linear gamma images? The PhotoFlow raw processor uses LCMS but also has its own gamut-check code that seems to generate pretty accurate gamut checks. It works for source floating point images in color spaces that support unbounded RGB values and for destination profiles that are matrix as well as LUT profiles. Here's a link to the branch in which the soft proofing code is being worked on: https://github.com/aferrero2707/PhotoFlow/tree/linear_gamma AFAIK, the PhotoFlow code for soft proofing to LUT profiles is similar to LCMS code, but does do the calculations for every pixel. The code for soft proofing to matrix profiles also does the calculations for every pixel, but the code is very different from the LCMS soft proofing code, involving taking the actual difference after a round-trip conversion. If the PhotoFlow soft proofing and gamut check code could be ported to/modified for incorpation into LCMS, then the existing LCMS code could be kept as the "fast execution" option for 8-bit integer perceptually uniform RGB source images. And the PhotoFlow-type code paths could be available as the "maybe not so fast but very accurate for floating point and linear gamma images" option. Although in terms of speed of execution, at least in PhotoFlow the gamut check/soft proofing code doesn't seem to noticeably slow down operations. Best, Elle ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
