lcms implementation in IM

[miket]

Hi,

I'm running icc profile conversions on HDR (.exr) images using Q16 HDR IM. The profiles are simple matrix profiles (i.e. not LUT profiles)

It appears that running the profile command is mapping a floating point value into a 16bit integer value following icc conversion and, further, is clipping any post conversion values which are greater than 65,535.

identify -list Configure confirms that I have lcms2 library installed (which should deal with floating point icc conversions).

Can anybody confirm if floating point lcms2 is fully implemented in IM? (I'm using IM through PerlMagic).

Code: Select all

Path: /usr/local/lib/ImageMagick-7.0.5//config-Q16HDRI/configure.xml

Name           Value
-------------------------------------------------------------------------------
CC             gcc
CFLAGS         -I/usr/include/libxml2 -I/usr/include/libpng12  -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/OpenEXR  -I/usr/include/lqr-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -I/usr/include/graphviz -I/usr/include/freetype2 -I/usr/include/freetype2 -pthread    -fopenmp -g -O2 -Wall -mtune=core2 -fexceptions -pthread -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16
CODER_PATH     /usr/local/lib/ImageMagick-7.0.5/modules-Q16HDRI/coders
CONFIGURE      ./configure  '--with-modules=yes' '--enable-shared=yes' '--with-perl'
CONFIGURE_PATH /usr/local/etc/ImageMagick-7/
COPYRIGHT      Copyright (C) 1999-2016 ImageMagick Studio LLC
CPPFLAGS       -I/usr/local/include/ImageMagick-7
CXX            g++
CXXFLAGS       -g -O2 -pthread
DEFS           -DHAVE_CONFIG_H
DELEGATES      bzlib djvu mpeg fftw fontconfig freetype jbig jng jpeg lcms lqr lzma openexr pango png ps tiff wmf x xml zlib
DISTCHECK_CONFIG_FLAGS  --disable-deprecated  --with-quantum-depth=16  --with-jemalloc=no  --with-umem=no  --with-autotrace=no  --with-gslib=no  --with-fontpath=  --with-rsvg=no 
DOCUMENTATION_PATH /usr/local/share/doc/ImageMagick-7
EXEC-PREFIX    /usr/local
EXECUTABLE_PATH /usr/local/bin
FEATURES       DPC HDRI Cipher OpenMP Modules
FILTER_PATH    /usr/local/lib/ImageMagick-7.0.5/modules-Q16HDRI/filters
GIT_REVISION   11790
HOST           x86_64-unknown-linux-gnu
INCLUDE_PATH   /usr/local/include/ImageMagick-7
LDFLAGS        -L/usr/local/lib  
LIB_VERSION    0x705
LIB_VERSION_NUMBER 7,0,5,5
LIBRARY_PATH   /usr/local/lib/ImageMagick-7.0.5
LIBS            -llcms2 -lfreetype  -llqr-1 -lglib-2.0 -lfftw3  -lfontconfig -lfreetype -lXext   -lSM -lICE -lX11  -lXt -llzma -lbz2 -lz -lltdl  -lm -lgomp    
NAME           ImageMagick
PCFLAGS        -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16
PREFIX         /usr/local
QuantumDepth   16
RELEASE_DATE   2017-04-03
SHARE_PATH     /usr/local/share/ImageMagick-7
SHAREARCH_PATH /usr/local/lib/ImageMagick-7.0.5/config-Q16HDRI
TARGET_CPU     x86_64
TARGET_OS      linux-gnu
TARGET_VENDOR  unknown
VERSION        7.0.5
WEBSITE        http://www.imagemagick.org

Path: [built-in]

Name           Value
-------------------------------------------------------------------------------
FEATURES       OpenMP 
NAME           ImageMagick
QuantumDepth   16

Code: Select all

Version: ImageMagick 7.0.5-5 Q16 x86_64 2017-04-03 http://www.imagemagick.org
Copyright: © 1999-2017 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP 
Delegates (built-in): bzlib djvu fftw fontconfig freetype gvc jbig jng jpeg lcms lqr ltdl lzma openexr pangocairo png tiff wmf x xml zlib

[snibgo]

I have noticed that "-profile" conversion always give results that are within gamut, ie 0 to 100% of QuantumRange, with a calculation that depends on "-intent" (ie it isn't simply clipping). I think that is reasonable behaviour, although I would like a fifth "-intent", that allows out-of-gamut colours. I doubt if the LCMS library has that facility (but it might).

I hadn't noticed that "-profile" conversion gives integer results, but that does seem to be the case. Again, I don't know whether this is an LCMS limitation or an IM problem that can be easily fixed.

To see the problem, create a gradient, and dump it to "txt:". We get fractional values:

Code: Select all

f:\web\im>%IMDEV%convert -size 1x10 gradient:red-blue -precision 15 txt:
# ImageMagick pixel enumeration: 1,10,4294967295,srgb
0,0: (4294967295,0,0)
0,1: (3817748706.66667,0,477218588.333334)
0,2: (3340530118.33333,0,954437176.666667)
0,3: (2863311530,0,1431655765)
0,4: (2386092941.66667,0,1908874353.33333)
0,5: (1908874353.33333,0,2386092941.66667)
0,6: (1431655765,0,2863311530)
0,7: (954437176.666667,0,3340530118.33333)
0,8: (477218588.333334,0,3817748706.66667)
0,9: (0,0,4294967295)

Repeat, with profile conversion. Results are exact integers:

Code: Select all

f:\web\im>%IMDEV%convert -size 1x10 gradient:red-blue -precision 15 -profile sRGB.icc -profile AdobeRGB1998.icc txt:
# ImageMagick pixel enumeration: 1,10,4294967295,srgb
0,0: (3463433839,0,0)
0,1: (3096033417,0,526327647)
0,2: (2740953951,0,849490594)
0,3: (2358807704,0,1199392637)
0,4: (1965978926,0,1525045990)
0,5: (1559321841,0,1931899686)
0,6: (1196836694,0,2322172521)
0,7: (868037565,0,2588121667)
0,8: (229772722,309990010,2851318259)
0,9: (0,443619953,3213737869)

I used IM v6.9.3-7 Q32 HDRI.

Note that numbers like 3463433839 are not divisible by 256 or 257, so Q32 HDRI is giving me more resolution than Q16 HDRI would.

[miket]

Thanks for this Snibgo,

I ran a similar test on my (Q16) system with similar results.

I'm processing "true" HDR images (Dmax around 4.5, 15 or so fstops) which have good and accurate detail in the shadows, therefore this integer rounding is causing me some jip.

I understand that lcms2 does work with floating point arithmetic, so it may just be that IM has not implemented that functionality yet. (I don't think the original lcms 1 had floating point functionality and think it was only 16 bit precision). Given there are more of us working with "true" HDR images, it would be really good to see this implemented in IM.

I have seen (older) posts which suggested the need to specifically specify "with-lcms2" when building IM, but that does not seem to be listed in the current build instruction. I'm assuming that was at a time where lcms2 (which was a major re-write of lcms1) was new and that lcms 2 is now the default setting. It would be good if one of the wizards could comment on that.

With regard to gamut clipping - I'd agree that that is what color management is all about. However, with HDR images luminocities (or lightness) values greater than one are quite possible. Without in any way being an expert on this, it looks as if icc is working it's way to accommodating >1 luminocites.

In the meantime, I guess I could resort to processing with colour matrices (ColorMatrix). It would be a bit of a phaff and nowhere near as neat and maintainable as color profiles.

Let's see what the wizards have to say.

Mike

[magick]

We'll investigate supporting floating point in the profile conversion. Its not a straightforward port from the existing 16-bit integer conversion so it may take a bit of time to implement / test.

[miket]

Many thanks folks

Given the increased use of HDR I'd be very surprised if I'm the only one who would benefit from this. Hopefully it's not too tricky a task.

Mike