Code Monkey home page Code Monkey logo

little-cms's Introduction

Little CMS

About Little CMS

www.littlecms.com

Little CMS intends to be an OPEN SOURCE small-footprint color management engine, with special focus on accuracy and performance. It uses the International Color Consortium standard (ICC), which is the modern standard when regarding to color management. The ICC specification is widely used and is referred to in many International and other de-facto standards. It was approved as an International Standard, ISO 15076-1, in 2005.

Conformance

Little CMS is a FULL IMPLEMENTATION of ICC specification 4.4, it fully supports all kind of V2 and V4 profiles, including abstract, devicelink and named color profiles. Check the tutorial for a exhaustive list of features.

A bit of story

Since the initial release, back in 1998, Little CMS has grown to become one of the most popular open-source color management libraries, and has been used in a large number of production projects, in areas as printer firmware, monitors, digital cameras, RIPs, publishing, scientific, and many others. You can find Little CMS in most Linux distributions, and it's released under an open source license.

Please see the complete documentation in doc folder

little-cms's People

Contributors

amyspark avatar beku avatar chris-liddell avatar danielkaneider avatar dependabot[bot] avatar diogoteles08 avatar dlemstra avatar g-coder avatar goossenp avatar kcwu avatar kleisauke avatar kmilos avatar lovell avatar luzpaz avatar lynx3d avatar mm2 avatar mrserb avatar nijel avatar pathcore-tasos avatar patricknoffke avatar rhalade avatar robinwatts avatar sebras avatar stweil avatar th1722 avatar thesamesam avatar x2018 avatar xclaesse avatar xhmikosr avatar ya1gaurav avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

little-cms's Issues

lcms writes uninitialized strings when writing named colors

Hi, this is Debian bug 815248, https://bugs.debian.org/815248.
Debian is trying to move to reproducible builds (https://wiki.debian.org/ReproducibleBuilds), that is the ability to reproduce byte-identical packages.

lcms is currently using some uninitialized strings when writing named colors, leading to non-identical builds. I attach a patch that rectifies this. Please note that this is not the original patch from the above Debian bug report - the bug submitter changed some more things. Justification for these changes can be found in the bug report. I attach the original patch as well, with a "ORIG" marker in the filename.
Original patch:
dont-write-uninitialized-memory-for-color-strings-ORIG.patch.txt

Changed patch with less changes:
dont-write-uninitialized-memory-for-color-strings.patch.txt

Endianess regression in cmsMLUtranslationsCodes() from 2.7 to 2.8

This is Debian bug 847595, https://bugs.debian.org/847595
In 2.7, cmsMLUtranslationsCodes() used _cmsAdjustEndianess16() to adjust the language and country code for endianess. This is gone in 2.8, where strFrom16() is used. That was originally okay, as strFrom16() contained an endianess swap/check. But 9fdd8a0 dropped that swap.

As a result, lcms will return ne_SU instead of en_US for the language of a profile; see above mentioned Debian bug for the case of colord's cd-iccdump and the test file from https://anonscm.debian.org/git/reproducible/diffoscope.git/plain/tests/data/test1.icc (or lcms' test4.icc). The bug report also contains a patch, but I am not sure if the patch does just pamper over the problem (there is after all a reason for 9fdd8a0).

Using lcms2 in Poppler or Ghostscript slows down rendering performance

For Ubuntu Precise (12.04) we want to migrate completely from the old liblcms1 to liblcms2, as the new library is maintained upstream:

https://bugs.launchpad.net/ubuntu/+source/lcms/+bug/885324

Unfortunately there is a regression in liblcm2. Most files get rendered slightly slower (5-10%) when Poppler is linked with liblcms2 instead of liblcms1 (for Ghostscript I have no test results).

But most important is that some files render significantly slower. An example is altona_technical_1v2_x3.pdf from http://www.eci.org/doku.php?id=es:downloads. Simply run it through "pdftops" (convert to PostScript with Poppler) or "gs" (screen-display with Ghostscript) on Ubuntu Onneiric (11.10, using liblcms1) and Ubuntu Precise (12.04, using liblcms2) and you see that the rendering is between 5 and 10 times slower with liblcms2. See also comments #16, #37 and #38 on

https://bugs.launchpad.net/ubuntu/+source/lcms/+bug/885324

and

http://www.mail-archive.com/[email protected]/msg06258.html

Estimate/retrieve the display's luminance?

Would it be possible for LittleCMS to somehow retrieve the device's “true” (output) luminance? Is there a metadata tag for this?

I know that all of the ICC profiles are, by convention, normalized to 1.0, but for my use case this is bothersome (I want to do mapping based on the true output brightness).

I could introduce the necessary correction factor myself, but this requires knowing what the display's absolute luminance is.

Wrong CMSEXPORT definitions for MinGW and MSVC++

I have just tried to build the latest Hugin's default branch using MingGW and found out that lcms2.h lacks proper CMSEXPORT definition for MinGW. The definition for MSVC++ also isn't ideal - details here: http://stackoverflow.com/questions/12511451/what-is-the-difference-between-stdcall-and-stdcal.
/J.D.

--- /d/Works/Hugin-MSVC/lcms2-2.7/include/lcms2.h   2015-03-17 11:19:51 +0100
+++ /d/Works/lcms2-2.7/include/lcms2.h  2015-09-17 21:28:49 +0200
@@ -219,7 +219,11 @@
 #        define CMSEXPORT       __stdcall _export
 #        define CMSAPI
 #     else
-#        define CMSEXPORT      _stdcall
+#        ifdef _MSC_VER
+#            define CMSEXPORT      __stdcall
+#        else
+#            define CMSEXPORT      __attribute__((stdcall))
+#        endif
 #        ifdef CMS_DLL_BUILD
 #            define CMSAPI    __declspec(dllexport)
 #        else

Segfault on running sample roundtrip with ASAN

Compile:
g++ -fno-omit-frame-pointer -fsanitize=address -g3 roundtrip.c -o roundtrip -I../../include/ -L../../src/.libs/ -llcms2
Run:
./roundtrip ../../testbed/test1.icc

ASAN:SIGSEGV

==10718== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f634eeb302c sp 0x7fff570ac170 bp 0x7fff570ac210 T0)
AddressSanitizer can not provide additional info.
==10718== WARNING: Trying to symbolize code, but external symbolizer is not initialized!
#0 0x7f634eeb302b (/home4/Little-CMS-master/src/.libs/liblcms2.so.2+0x7002b)
src/cmsxform.c:189
#1 0x400f95 (/home4/Little-CMS-master/utils/samples/roundtrip+0x400f95)
utils/samples/roundtrip.c:67
#2 0x7f634e799ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
#3 0x400a48 (/home4/Little-CMS-master/utils/samples/roundtrip+0x400a48)
==10718== ABORTING

Analysis:
It fails with test1.icc,test2.icc & bad.icc. Pass with test3.icc, test4.icc & test5.icc
It faults in dereference:
189 p -> xform(p, InputBuffer, OutputBuffer, Size, 1, &stride);

DESTDIR and "remember to run `libtool --finish /usr/lib'"

gcc --version
gcc (GCC) 4.2.2

Using DESTDIR when installing results in several warnings.

[quote]

make DESTDIR=/opt/temp/lcms2-2.8 install
Making install in src
make[1]: Entering directory /opt/lcms2-2.8/src' make[2]: Entering directory /opt/lcms2-2.8/src'
.././install-sh -c -d '/opt/temp/lcms2-2.8/usr/lib'
/bin/sh ../libtool --mode=install /usr/bin/ginstall -c liblcms2.la '/opt/temp/lcms2-2.8/usr/lib'
libtool: install: /usr/bin/ginstall -c .libs/liblcms2.so.2.0.8 /opt/temp/lcms2-2.8/usr/lib/liblcms2.so.2.0.8
libtool: install: (cd /opt/temp/lcms2-2.8/usr/lib && { ln -s -f liblcms2.so.2.0.8 liblcms2.so.2 || { rm -f liblcms2.so.2 && ln -s liblcms2.so.2.0.8 liblcms2.so.2; }; })
libtool: install: (cd /opt/temp/lcms2-2.8/usr/lib && { ln -s -f liblcms2.so.2.0.8 liblcms2.so || { rm -f liblcms2.so && ln -s liblcms2.so.2.0.8 liblcms2.so; }; })
libtool: install: /usr/bin/ginstall -c .libs/liblcms2.lai /opt/temp/lcms2-2.8/usr/lib/liblcms2.la
libtool: install: /usr/bin/ginstall -c .libs/liblcms2.a /opt/temp/lcms2-2.8/usr/lib/liblcms2.a
libtool: install: chmod 644 /opt/temp/lcms2-2.8/usr/lib/liblcms2.a
libtool: install: ranlib /opt/temp/lcms2-2.8/usr/lib/liblcms2.a
libtool: install: warning: remember to run `libtool --finish /usr/lib'

[/quote]

The command finishes installing lcms2 with additional warnings.

The libs are installed in the temp path directories, despite the warnings.

Does installing this way affect the functioning of lcms2 when compared to just using 'make install' or 'new2dir make install' ?

note: new2dir uses installwatch.

Fix UndefinedBehavior

Compiling the current master with UBSan triggers some errors about integer overflows.

I used :

$ CC=clang-3.9 CFLAGS="-O0 -g -fsanitize=undefined -fsanitize=integer -fno-sanitize-recover=undefined,integer -fno-omit-frame-pointer" LDFLAGS="-fsanitize=undefined,integer" ./configure
$ make
$ make check
[...]
Installing debug memory plug-in ... done.
Installing error logger ... done.
Supported intents:
    0 - Perceptual
    1 - Relative colorimetric
    2 - Saturation
    3 - Absolute colorimetric
    10 - Perceptual preserving black ink
    11 - Relative colorimetric preserving black ink
    12 - Saturation preserving black ink
    13 - Perceptual preserving black plane
    14 - Relative colorimetric preserving black plane
    15 - Saturation preserving black plane

Checking Base types ...Ok.
Checking endianess ...Ok.
Checking quick floor ...Ok.
Checking quick floor word ...Ok.
Checking Fixed point 15.16 representation ...Ok.
Checking Fixed point 8.8 representation ...Ok.
Checking D50 roundtrip ...Ok.
Checking Creation of test profiles ...............cmsintrp.c:178:53: runtime error: unsigned integer overflow: 4294966357 * 15439 cannot be represented in type 'unsigned int'
make[1]: *** [check] Error 1
make[1]: Leaving directory `/home/jmalik/dev/src/senbox/tools/Little-CMS/testbed'
make: *** [check-recursive] Error 1

Actually, we are running UBSan build for OpenJPEG, which integrated LittleCMS as a dependency, and a number of our UBSan reports come from LittleCMS.
We recently updated to latest master to fix unaligned address reported by UBSan and fixed by 40c6403 , but we still get some others failures from lcms :

cmsopt.c:1582:33: runtime error: signed integer overflow: 2139127808 + 8388608 cannot be represented in type 'int'

cmspack.c:1781:17: runtime error: signed integer overflow: 44441 * 65281 cannot be represented in type 'int'

which seem to come from the FROM_16_TO_8 macro

undefined reference error in make check

While running make check. Getting following error:

lcms2-2.4/testbed/testcms2.c:528: undefined reference to _cmsStageAllocIdentityCurves' lcms2-2.4/testbed/testcms2.c:530: undefined reference to_cmsStageAllocIdentityCurves'
lcms2-2.4/testbed/testcms2.c:541: undefined reference to _cmsStageAllocIdentityCurves' lcms2-2.4/testbed/testcms2.c:543: undefined reference to_cmsStageAllocIdentityCurves'
testcms2.o: In function CheckFormattersHalf': lcms2-2.4/testbed/testcms2.c:4037: undefined reference to_cmsHalf2Float'
lcms2-2.4/testbed/testcms2.c:4041: undefined reference to _cmsFloat2Half' testcms2.o: In functionCheckNamedColorLUT':
lcms2-2.4/testbed/testcms2.c:3412: undefined reference to _cmsStageAllocNamedColor' lcms2-2.4/testbed/testcms2.c:3412: undefined reference to_cmsStageAllocNamedColor'
testcms2.o: In function CheckLab2LabMatLUT': lcms2-2.4/testbed/testcms2.c:3376: undefined reference to_cmsStageAllocLab2XYZ'
lcms2-2.4/testbed/testcms2.c:3378: undefined reference to _cmsStageAllocXYZ2Lab' testcms2.o: In functionCheckXYZ2XYZLUT':
lcms2-2.4/testbed/testcms2.c:3358: undefined reference to _cmsStageAllocXYZ2Lab' lcms2-2.4/testbed/testcms2.c:3359: undefined reference to_cmsStageAllocLab2XYZ'
testcms2.o: In function CheckLab2LabLUT': lcms2-2.4/testbed/testcms2.c:3341: undefined reference to_cmsStageAllocLab2XYZ'
lcms2-2.4/testbed/testcms2.c:3342: undefined reference to _cmsStageAllocXYZ2Lab' testcms2.o: In functionCombineGamma16':
lcms2-2.4/testbed/testcms2.c:2664: undefined reference to _cmsQuantizeVal' testcms2.o: In functionExhaustiveCheck3DinterpolationTrilinear16':
lcms2-2.4/testbed/testcms2.c:1409: undefined reference to _cmsComputeInterpParams' lcms2-2.4/testbed/testcms2.c:1432: undefined reference to_cmsFreeInterpParams'
lcms2-2.4/testbed/testcms2.c:1428: undefined reference to _cmsFreeInterpParams' testcms2.o: In functionExhaustiveCheck3DinterpolationTetrahedral16':
lcms2-2.4/testbed/testcms2.c:1362: undefined reference to _cmsComputeInterpParams' lcms2-2.4/testbed/testcms2.c:1384: undefined reference to_cmsFreeInterpParams'
lcms2-2.4/testbed/testcms2.c:1380: undefined reference to `_cmsFreeInterpParams'
:::::::
:::::::

Please suggest how to resolve this issue.

Negative value returned by cmsfilelength

long int CMSEXPORT cmsfilelength(FILE* f)
{
long int p , n;

p = ftell(f); // register current file position

if (fseek(f, 0, SEEK_END) != 0) {
    return -1;
}

n = ftell(f);
fseek(f, p, SEEK_SET); // file position restored

return n;

}
As seen above cmsfilelength can return -1.
Also ftell can fail and return -1, so n=ftell(f) can make n as -1.
Now, cmsfilelength is used at many places to calculate length & do malloc or some other operation which may not expect negative value as input.
So, it need to change either cmsfilelength function return value or secondly wherever cmsfilelength is called, there should be check for returned size.

Q: cmsDoTransform(): using same buffer for in and out

Hi.

Unfortunately LittleCMS2.7 tutorial.pdf is not verbose-enough.

I would like to get a clarification about:

It is safe to use same block for input and output, but only if the input and output are coded in
same format. For example, you can safely use only one buffer for RGB to RGB but you cannot use
same buffer for RGB as input and CMYK as output.

In particular, that does mean that i can not use the same buffer to convert from TYPE_RGBA_FLT to TYPE_LabA_FLT, but i can use the same buffer to convert from TYPE_RGBA_FLT to TYPE_RGBA_FLT?

Virtual profiles for more color spaces?

It's easy to create an RGB profile with LittleCMS, but I'm having a hard time creating a profile for more color spaces (in particular, YCbCr).

I could copy/paste the libvirt.c stuff and make some changes to adapt it from RGB to YCbCr, but some of the functions used are private/internal functions, and I'm also not sure what tags exactly LittleCMS needs internally in order to actually use the profile to transform colors, so I'm not sure how much is redundant or not for my use case.

Would it be possible to add LittleCMS functions for these kinds of profiles, in particular creating YCbCr profiles?

cmsChannelsOf is not complet

Hi everyone,

I noticed something weird with "cmsChannelsOf" function.
cmsSigMCH4Data, cmsSigMCH3Data, cmsSigMCH2Data, cmsSigMCH4Data are not taken into account ? So Channel value is always 3 for their ColorSpaceSignatures.

Another point, what is the difference between cmsSigXcolorData and cmsSigMCHXData ?

Best regards,

Pierre-Henri

tiffio.h and jpeglib.h

Hi,

Compiler shows error tiffio.h and jpeglib.h are missing and I cannot find them in files in this project.
Should I get them from somewhere else?

Please add a way for clients to set the creation date/time in profile headers

Hi, this is Debian bug 814883, https://bugs.debian.org/814883
Debian is trying to move to reproducible builds (https://wiki.debian.org/ReproducibleBuilds), that is the ability to reproduce byte-identical packages.

lcms is currently always using the current time to set the creation time in profile headers. The attached patch adds a function cmsSetHeaderCreationDateTime() that allows clients to set an explicit creation date/time.
add_set_header_creation_date_time.patch.txt

Segfault when setting sRGB profile via imagemagick

Hi!

I have a PHP script that generates images off of PDFs (via imagick -> imagemagick -> ghostscript), it reproducibly segfaults when assigning a profile to it. I've attached a gdb stack trace.

I hope this isn't due to some other bug elsewhere in the stack.

I'm using:
ghostscript 9.10-r2
lcms 2.6-r1 (most recent in Gentoo Portage)
imagemagick 6.9.0.3

Linux a 3.17.7-gentoo #1 SMP Mon Jan 5 13:34:45 UTC 2015 x86_64 Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz GenuineIntel GNU/Linux

Core was generated by `/usr/bin/php /var/www/npiece/vendors/cake/console/cake.php -app /var/www/npiece'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f8824f8121d in _cmsMallocZeroDefaultFn (ContextID=<optimized out>, size=3752)
    at /var/tmp/portage/media-libs/lcms-2.6-r1/work/lcms2-2.6/src/cmserr.c:97
#2  0x00007f8824f87eb2 in cmsCreateProfilePlaceholder (ContextID=ContextID@entry=0x1d31420)
    at /var/tmp/portage/media-libs/lcms-2.6-r1/work/lcms2-2.6/src/cmsio0.c:460
#3  0x00007f8824f892e8 in cmsOpenProfileFromMemTHR (ContextID=ContextID@entry=0x1d31420, MemPtr=0x1cdef20, dwSize=dwSize@entry=3048)
    at /var/tmp/portage/media-libs/lcms-2.6-r1/work/lcms2-2.6/src/cmsio0.c:1118
#4  0x00007f88252e104a in ProfileImage (image=0x1d31420, name=name@entry=0x7f882cd51c50 "icc", datum=datum@entry=0x1cb8d80, length=length@entry=3048, 
    magick_unused_clone=magick_unused_clone@entry=MagickTrue) at magick/profile.c:865
#5  0x00007f88256274eb in MagickProfileImage (wand=0x1961790, name=0x7f882cd51c50 "icc", profile=0x1cb8d80, length=3048) at wand/magick-property.c:1728
#6  0x00007f88258c3bb0 in zim_imagick_profileimage (ht=<optimized out>, return_value=0x1cb3a48, return_value_ptr=<optimized out>, this_ptr=<optimized out>, 
    return_value_used=<optimized out>) at /var/tmp/portage/dev-php/pecl-imagick-3.2.0_rc1/work/php5.5/imagick_class.c:4545
#7  0x00000000008017da in zend_do_fcall_common_helper_SPEC (execute_data=<optimized out>)
    at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/Zend/zend_vm_execute.h:550
#8  0x000000000077a3d8 in execute_ex (execute_data=0x7f882cd88df8) at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/Zend/zend_vm_execute.h:363
#9  0x0000000000742e38 in zend_call_function (fci=fci@entry=0x7fffd18235e0, fci_cache=<optimized out>, fci_cache@entry=0x7fffd18235b0)
    at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/Zend/zend_execute_API.c:934
#10 0x0000000000658312 in zif_call_user_func_array (ht=<optimized out>, return_value=0x1c1d8a8, return_value_ptr=<optimized out>, this_ptr=<optimized out>, 
    return_value_used=<optimized out>) at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/ext/standard/basic_functions.c:4812
#11 0x00000000008017da in zend_do_fcall_common_helper_SPEC (execute_data=<optimized out>)
    at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/Zend/zend_vm_execute.h:550
#12 0x000000000077a3d8 in execute_ex (execute_data=0x7f882cd88518) at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/Zend/zend_vm_execute.h:363
#13 0x0000000000752210 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3)
    at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/Zend/zend.c:1327
#14 0x00000000006f3b52 in php_execute_script (primary_file=primary_file@entry=0x7fffd1825b40)
    at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/main/main.c:2525
#15 0x000000000080358e in do_cli (argc=11, argv=0xf95df0) at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/sapi/cli/php_cli.c:994
#16 0x000000000047aca0 in main (argc=11, argv=0xf95df0) at /var/tmp/portage/dev-lang/php-5.5.24/work/sapis-build/cli/sapi/cli/php_cli.c:1378
(gdb) 

Comparison with size_t

Hi,
I've been compiling Luminance HDR with Clang, and I get this warning:

/opt/local/include/lcms.h:1418:14: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if (size < 0) return NULL; // Prevent signed size_t exploits
~~~~ ^ ~

integer overflow in FillFirstShaper()

When cmsEvalToneCurveFloat() return infinite value or -Inf, DOUBLE_TO_1FIXED14() will overflow when casting from double to int.

1557            y   = cmsEvalToneCurveFloat(Curve, R);
1558
1559            Table[i] = DOUBLE_TO_1FIXED14(y);

p.s. this is my #108 trying to handle.

CMS_NO_HALF_SUPPORT

It appears that CMS_NO_HALF_SUPPORT no longer works in the latest version. The 'new' file cmsalpha.c uses functions that are not available when CMS_NO_HALF_SUPPORT is enabled (

*(cmsUInt16Number*)dst = _cmsFloat2Half(n);
). I am not sure if adding check for the define inside FormatterPos and inside the various HLF methods would fix this. But if that would fix it correctly I wouldn't mind sending in a pull request for it.

Warnings from Visual Studio 2017 code analysis

 src\cmsgamma.c(1043): warning C6262: Function uses '49196' bytes of stack:  exceeds /analyze:stacksize '16384'.  Consider moving some data to heap.
 src\cmsplugin.c(765): warning C6387: 'p' could be '0':  this does not adhere to the specification for the function 'CloseHandle'. 
 src\cmsplugin.c(955): warning C28182: Dereferencing NULL pointer. 'prev' contains the same NULL value as '_cmsContextPoolHead' did. 

unaligned access on mips/mipsel Linux with 2.6

Hi Marti,
this is Debian bug #749975, https://bugs.debian.org/749975, which I copy in full below. The issue was found using colord's testsuite, that's why colord is mentioned.

colord fails to build from source on both mips/mipsel due to an unaligned access (SIGBUS):
https://buildd.debian.org/status/fetch.php?pkg=colord&arch=mips&ver=1.2.0-3&stamp=1401475533
https://buildd.debian.org/status/fetch.php?pkg=colord&arch=mipsel&ver=1.2.0-3&stamp=1401374635

The MIPS architecture requires that load/stores are done with an alignment corresponding to the type, so even if it is a 32-bit architecture accesses to double values (8-bytes) require a 64-bit alignment.

Currently the lcms2 memory allocator only guarantee an alignment corresponding the size of (void *). Since version 2.6, lcms2 now also store double values (called cmsFloat64Number), causing some random issues on mips/mipsel, depending on how lucky we are about the alignement. SPARC is likely to also be affected, as the same alignment requirement applies.

There are two ways of fixing that, either increasing the alignment to 64-bit on mips/mipsel/sparc:

--- a/src/lcms2_internal.h
+++ b/src/lcms2_internal.h
@@ -56,8 +56,13 @@
// Alignment of ICC file format uses 4 bytes (cmsUInt32Number)
#define _cmsALIGNLONG(x) (((x)+(sizeof(cmsUInt32Number)-1)) & ~(sizeof(cmsUInt32Number)-1))

-// Alignment to memory pointer
-#define _cmsALIGNMEM(x) (((x)+(sizeof(void *) - 1)) & ~(sizeof(void *) - 1))
+// Alignment to maximum required alignment
+// On MIPS and SPARC, access to double values need to be 8-bytes aligned
+#if defined(mips) || defined(sparc)
+# define _cmsALIGNMEM(x) ((x + 7) & ~7)
+#else
+# define _cmsALIGNMEM(x) (((x)+(sizeof(void *) - 1)) & ~(sizeof(void *) - 1))
+#endif

// Maximum encodeable values in floating point
#define MAX_ENCODEABLE_XYZ (1.0 + 32767.0/32768.0)

As it seems storing 64-bit values is not the common case, the otheralternative is to tell GCC that the stored double values are aligned to (void *), so that it generate code to do unaligned access if needed. This can be specified independently of the architecture as this isalways true, and might even help GCC to generate better code. This is what the patch below does:

--- a/src/lcms2_internal.h
+++ b/src/lcms2_internal.h
@@ -479,11 +479,13 @@
const struct _cmsContext_struct* src);

// Container for adaptation state -- not a plug-in
+// The chunks are only guaranteed to be aligned to void *, tell that to the
+// compiler so that it can generate unaligned access instructions if needed.
typedef struct {

 cmsFloat64Number  AdaptationState;

-} _cmsAdaptationStateChunkType;
+} _cmsAdaptationStateChunkType attribute ((aligned(alignof(void *))));

// The global Context0 storage for adaptation state
extern _cmsAdaptationStateChunkType _cmsAdaptationStateChunk;

How to apply profile with PCS = cmsSigXYZData, Color Space = cmsSigGrayData ?

Hello,

I have a jpeg 2000 file with an ICC profile.

PCS is cmsSigXYZData and color space is cmsSigGrayData.

The file can be found here: GrokImageCompression/grok#38

I am working on a library that decodes the jpeg 2000 file and applies the ICC profile, using LCMS.

Currently, I have this code:

in_type = TYPE_GRAY_8;
out_type = TYPE_RGB_8;
out_prof = cmsCreate_sRGBProfile();

and I can create the transform and apply the ICC profile, but the output is an RGB file.
What I would like is to output a grayscale file.

So, if I instead call

out_prof = cmsCreateGrayProfile(NULL,NULL);

then cmsCreateTransform returns NULL and I can't apply the profile.

What is the best way of creating a transform for this kind of grayscale image ?

Thanks so much,
Aaron

out of bounds stack buffer read

Type_NamedColor_Read() creates a "Root" buffer of size 33 without 0-termination (local buffer is uninitalised) and reads 32 bytes from io, also without check for null termination:

        char Root[33];

        memset(Colorant, 0, sizeof(Colorant));
        if (io -> Read(io, Root, 32, 1) != 1) return NULL;
        if (!_cmsReadUInt16Array(io, 3, PCS)) goto Error;
        if (!_cmsReadUInt16Array(io, nDeviceCoords, Colorant)) goto Error;

        if (!cmsAppendNamedColor(v, Root, PCS, Colorant)) goto Error;

cmsAppendNamedColor then applies strncpy with huge cmsMAX_PATH:

    if (Name != NULL) {

        strncpy(NamedColorList ->List[NamedColorList ->nColors].Name, Name, cmsMAX_PATH-1);
        NamedColorList ->List[NamedColorList ->nColors].Name[cmsMAX_PATH-1] = 0;

and strncpy() reads behind Root/Name. You may reproduce the bug as follows:

>./configure CC="clang" CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer -fPIC"
>make
>./utils/psicc/psicc -imin.icc
==24151== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffc1104c24 at pc 0x4130c5 bp 0x7fffc1104270 sp 0x7fffc1103a28
READ of size 1 at 0x7fffc1104c24 thread T0
...

base64 representation of min.icc is

AAABCgAAAAAAAAAAbm1jbAAAAAAAAAAAAAAAAAAAAAAAAAAAYWNzcAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABbmNsMgAAAJAAAAB6bmNsMgAAAAAAAAAAAAAAAQAAAABhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWEAAAAAAAA=

lcms: ICC profile version check security fix - CVE-2014-0459

Yesterday, a commit was made to OpenJDK (and the same issue fixed in Oracle JDK via Oracle Critical Patch Update Advisory - April 2014) fixing an issue in embedded lcms.

http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d6739b8326a4
http://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html#AppendixJAVA

Fix adds code that validates profile version.

There are no real details available, CVSS score used in the CPU indicates that lack of the check impacts application availability, possibly causing crash.

This check is currently not part of the Little-CMS git master. I'm unsure if you were notified about this issue by Oracle, or if you may have more details about affected versions (i.e. whether 1.x and 2.x are affected).

don't overwrite user CFLAGS

testbed/Makefile.am overwrites CFLAGS, but people might want to specify their own, for example for building a 32bit lcms2 on a 64bit system using -m32 or for various other reasons.

Instead, it should rather set AM_CFLAGS. the user's CFLAGS will then be added to it

Adding iccjpeg.c to the public API

Hi,
Chromium (open source version of Google Chrome browser) currently ships a copy of iccjpeg.c as found in utils/jpgicc. Would it be possible to "merge" this file into lcms2's public API? Or provide a shared library just for this code?
The goal here is to avoid code duplication.

Reference: Debian bug #747839, https://bugs.debian.org/747839

psicc truncates file

With improper usage psicc truncates input files.

Create an arbitrary file, use it as parameter for psicc and enjoy your file of size 0:

>dd if=/dev/zero of=profile.icc bs=1M count=1
>psicc profile.icc
[usage message]
>ls -l
-rw-rw-r-- 1 _ _     0 Jul 11 17:37 profile.icc

Swapped red and green ICC not un-swapping when soft-proofing

Hello

RawTherapee uses LCMS, and there is work currently being done on implementing soft-proofing support.

When the output profile is set to SwappedRedAndGreen.icc, and the monitor profile is set to the same, and soft-proofing is enabled, the assumption is that the end result will be a correctly looking image. However that is not the case - when SwappedRedAndGreen.icc is set as the monitor profile, the preview image is correctly swapped, but when activating soft-proofing using that ICC as output, nothing really happens.

@mm2 do you know of any reason why that would be the case? Is there a catch?

References:
Beep6581/RawTherapee#3406 (comment)
Beep6581/RawTherapee#3406 (comment)

Kind regards

How can I get Look up table or conversion matrix in cmsHTRANSFORM

Hello. I'm trying to apply CMS to my renderer which is implemented using OpenGL.

Specifically I supposed generated image in GPU buffer(rendered image) is in sRGB space and I'm trying to convert that image into my monitor's RGB space inside of my fragment shader.

So I made simple transform which looks like this.

hTransform = cmsCreateTransform(profile_sRGB, TYPE_BGR_8, profile_leftMonitor, TYPE_BGR_8, INTENT_PERCEPTUAL, 0);

To accomplish CMS inside of GPU I should send matrix or LUT as form of uniform variable. So that my fragment shader can access to information about color transform .

I have basic knowldege about CMS so I thought cmsHTRANSFORM has some sort of conversion matrix or look up table to compute source to target RGB conversion.

So first thing that I tried to find was 3x3(or 4x4) conversion matrix or look up table
which convert RGB in color space A to RGB in color space B in cmsHTRANSFORM.
But I couldn't find anything like that in API documents.
Maybe I don't know the keyword related to it.
Does LCMS support LUT or 3x3 conversion matrix?

If not, is there any way to achieve CMS in my renderer?

cmsMLUsetASCII and cmsMLUsetWide write a NULL Termination but shouldn't

Hi Marti,

I noticed that cmsMLUsetASCII and cmsMLUsetWide write a Null termination in the MLU but it seems that it should not (ICC1v43_2010-12.pdf page 61).
Just removing the + 1 in len assignment solves the problem and getters look fine as they add the null termination.

Best Regards,
Eric

transicc stack buffer overflow in TakeFloatValues > GetLine

There is a very simple stack buffer overflow in transicc:

$ ./transicc -i ../../testbed/test1.icc 
LittleCMS ColorSpace conversion calculator - 4.3 [LittleCMS 2.07]

Enter values, 'q' to quit
C? 1
=================================================================
==10338==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc0e6606f0 at pc 0x7fa6864c31d2 bp 0x7ffc0e660060 sp 0x7ffc0e660018
WRITE of size 4096 at 0x7ffc0e6606f0 thread T0
    #0 0x7fa6864c31d1 in scanf_common ../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors_scanf.inc:307
    #1 0x7fa6864c3911 in __interceptor___isoc99_vscanf ../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:598
    #2 0x7fa6864c39f7 in __interceptor___isoc99_scanf ../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:630
    #3 0x40f38e in GetLine /home/mikispag/Downloads/lcms2-2.7/utils/transicc/transicc.c:630
    #4 0x40f994 in TakeFloatValues /home/mikispag/Downloads/lcms2-2.7/utils/transicc/transicc.c:746
    #5 0x40b55d in main /home/mikispag/Downloads/lcms2-2.7/utils/transicc/transicc.c:1274
    #6 0x7fa685bd7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #7 0x40e52c (/home/mikispag/Downloads/lcms2-2.7/utils/transicc/transicc+0x40e52c)

Address 0x7ffc0e6606f0 is located in stack of thread T0 at offset 928 in frame
    #0 0x40f7af in TakeFloatValues /home/mikispag/Downloads/lcms2-2.7/utils/transicc/transicc.c:719

  This frame has 7 object(s):
    [32, 34) 'index'
    [96, 136) 'Name'
    [192, 232) 'Prefix'
    [288, 328) 'Suffix'
    [384, 640) 'ChannelName'
    [672, 928) 'Buffer'
    [960, 5056) 'Buffer' <== Memory access at offset 928 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors_scanf.inc:307 scanf_common
Shadow bytes around the buggy address:
  0x100001cc4080: f2 f2 00 00 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00
  0x100001cc4090: 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00
  0x100001cc40a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100001cc40b0: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00
  0x100001cc40c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100001cc40d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2
  0x100001cc40e0: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100001cc40f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100001cc4100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100001cc4110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100001cc4120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==10338==ABORTING

This is because in TakeFloatValues (transicc.c:746) a:

char Buffer[cmsMAX_PATH];

with cmsMAX_PATH = 256 is declared and passed to GetLine, and then, in transicc.c:630, a:

res = scanf("%4095s", Buffer);

overflows it.

Incorrect 16 to 8 bit conversion in MatShaperEval16 function

The MatShaperEval16 function extracts only the lower 8-bits of the input word when applying the matrix-shaper evaluator. The function assumes that 8-bit values (in the image) were converted to 16-bit using the FROM_8_TO_16 macro. However, the aforementioned assumption breaks down when custom input formatter plugins are used, because the lower 8-bits may be padded in a different way.

I have created a pull request (#118) that fixes the problem. I have also included a code snippet in the pull request comment that allows you to replicate the bug.

When is v2.8 expected?

The last release was more than a year ago.
After that there are many fixes/improvement.
Can you release new version for Little-CMS, so that users can adopt the current changes.
It is difficult to adopt github code because maintaining versions history becomes difficult.
Is there any schedule for new version ?

Potential out of memory error

Given a crafted input, it's possible to request lcms to allocate a lot more memory then it will need, potentially causing an OOM. The ReadPositiontable method can be updated to verify the amount of data available in the input is more then what will be needed to read before allocating the arrays and existing early if the input is bad.

A potential fix can be seen at: https://pdfium-review.googlesource.com/c/5110/ (https://pdfium.googlesource.com/pdfium/+/master/third_party/lcms2-2.6/0018-verify-size-before-reading.patch)

cmsio0.c compile error (MSVC 2013)

Hello,

I have a compile error in cmsio0.c at line 1857.

error C2440: '=' : cannot convert from 'int' to 'cmsTagSignature'

the solution to cast 0 to cmsTagSignature:

Icc->TagNames[i] = (cmsTagSignature)0;

Regards
Zolee

A bug in utils/tificc.c ?

When input image and output image are both PLANARCONFIG_SEPARATE, they might have different number of planes , such as RGB as input and CMYK as output, but in function StripBasedXform and TileBasedXform , a parameter "nPlanes" is used to represent the number of planes of input image and output image ,thus the numbers are always the same, is this a bug?

License on utils/jpgicc/iccjpeg.c?

What exactly is the license on this file? There does not seem to be any licensing information included in the file itself or in its directory. Does that mean the LittleCMS 2 license applies?

I'm confused because eg. Chromium includes it under the IJG license: https://chromium.googlesource.com/chromium/chromium/+/master/third_party/iccjpeg/LICENSE with the reasoning being that it was authored by a member of the IJG group, however I did not find this file included in any of the IJG's jpeg distributions.

I would love to use this code, but I can't really do that without knowing for sure what the license on it is.

make check triggers a stack buffer overflow

When compiled with ASAN (-fsanitize=address), make check gives:

Checking Profile creation .....................=================================================================
==31486==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd564bdd8 at pc 0x2aec9c17593d bp 0x7ffdd564b9a0 sp 0x7ffdd564b978
READ of size 392 at 0x7ffdd564bdd8 thread T0
    #0 0x2aec9c17593c in __interceptor_memmove ../../.././libsanitizer/asan/asan_interceptors.cc:358
    #1 0x463b5a in _cmsDupDefaultFn /home/mikispag/Downloads/lcms2-2.7/src/cmserr.c:172
    #2 0x4aee47 in cmsWriteTag /home/mikispag/Downloads/lcms2-2.7/src/cmsio0.c:1686
    #3 0x449f6b in CheckICCViewingConditions /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:4992
    #4 0x449f6b in CheckProfileCreation /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:5319
    #5 0x41f187 in Check /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:310
    #6 0x407322 in main /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:8339
    #7 0x2aec9d55dec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #8 0x408e9c (/home/mikispag/Downloads/lcms2-2.7/testbed/testcms+0x408e9c)

Address 0x7ffdd564bdd8 is located in stack of thread T0 at offset 280 in frame
    #0 0x4452af in CheckProfileCreation /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:5192

  This frame has 6 object(s):
    [32, 39) 'Buffer'
    [96, 112) 'c'
    [160, 184) 'Curves'
    [224, 280) 's'
    [320, 392) 'c' <== Memory access at offset 280 partially underflows this variable
    [448, 704) 'Buffer' <== Memory access at offset 280 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../.././libsanitizer/asan/asan_interceptors.cc:358 __interceptor_memmove
Shadow bytes around the buggy address:
  0x10003aac1760: 00 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
  0x10003aac1770: 00 00 04 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
  0x10003aac1780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac1790: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 07 f4 f4 f4
  0x10003aac17a0: f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 00 f4
=>0x10003aac17b0: f2 f2 f2 f2 00 00 00 00 00 00 00[f4]f2 f2 f2 f2
  0x10003aac17c0: 00 00 00 00 00 00 00 00 00 f4 f4 f4 f2 f2 f2 f2
  0x10003aac17d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac17e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac17f0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac1800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==31486==ABORTING

tiffio.h and jpeglib.h

Hi,

Compiler shows error tiffio.h and jpeglib.h are missing and I cannot find them in files in this project.
Do you know how can I resolve this problem?

Error 17 error C1083: Cannot open include file: 'tiffio.h': No such file or directory c:\temp\little-cms-master\utils\tificc\tifdiff.c 28 1 tiffdiff

Error 15 error C1083: Cannot open include file: 'jpeglib.h': No such file or directory c:\temp\little-cms-master\utils\jpgicc\iccjpeg.h 20 1 jpegicc

Error 14 error C1083: Cannot open include file: 'jpeglib.h': No such file or directory c:\temp\little-cms-master\utils\jpgicc\jpgicc.c 30 1 jpegicc

No function to retrieve cmsProfileID

I see a definition for cmsProfileID in lcms2.h, and it's referenced inside cmsICCHeader, but I cannot find any way to retrieve this information through the actual LittleCMS 2 API.

Is it possible to get the profile ID somehow? If not, could it be added?

My use case: I want to quickly figure out if an ICC profile has changed, as that invalidates my cache. Currently I am comparing the entire file against a reference copy, but that doesn't play nicely with profiles loaded from memory (or generated from scratch), and it's also less efficient to store a full copy of a potentially large ICC profile rather than just a 128-bit hash.

Error building git version on debian sid

run:

./autogen.sh
make

shows:

Making all in src
make[1]: Entering directory `/var/build/lcms2/src'
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DPACKAGE_NAME=\"lcms2\" -DPACKAGE_TARNAME=\"lcms2\" -DPACKAGE_VERSION=\"2.6\" -DPACKAGE_STRING=\"lcms2\ 2.6\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD=1 -DHasTHREADS=1 -DHasJPEG=1 -DHasZLIB=1 -DHasTIFF=1 -DHAVE_TIFFCONF_H=1 -I. -I../include -I../include    -g -O2 -pthread -MT cmscnvrt.lo -MD -MP -MF .deps/cmscnvrt.Tpo -c -o cmscnvrt.lo cmscnvrt.c
libtool: Version mismatch error.  This is libtool 2.4, but the
libtool: definition of this LT_INIT comes from libtool 2.4.2.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4
libtool: and run autoconf again.
make[1]: *** [cmscnvrt.lo] Error 63
make[1]: Leaving directory `/var/build/lcms2/src'
make: *** [all-recursive] Error 1

on Debian 3.13.6-1 (2014-03-19) x86_64 GNU/Linux
libtool 2.4.2
autoconf 2.69
automake 1.14.1

Checksum for 2.8 SourceForge

Hi,
We just got an issue filed over at Homebrew about the checksum recorded in the little-cms2.rb formula file not matching the checksum of the downloaded archive, so Homebrew errored out due to the mismatch: https://github.com/Homebrew/homebrew-versions/issues/1321

I happened to still have a copy of the original in my cache, and noticed that the difference appears to be just that the original archive was not gzip compressed, while the newly uploaded one is.

In the future, it would be really helpful if you could actually bump the version, or at least add a release note on SourceForge explaining why the checksum changed, since we hard code the checksum for security purposes, and then have to wait for a user to notify us that the checksum "mysteriously" changed, then go ping upstream to find out what happened, etc., and make sure there hasn't been a security compromise.

Thanks

Test failure with git 1948a466f43e5ccd4b3e2f47e3e3d337c9400ed9

Hi,
I have a test failure with current git HEAD (1948a46):

Checking Known values across matrix-shaper ...FAIL!
Known values across matrix-shaper:
(Z): Must be 39.425916, But is 39.438471

This is a current Debian unstable (amd64, gcc 4.8.2). "git bisect" suggests that the problem is 74ba391 (sanity check on profile versions).

Impossible to initialize a Lab->Other or Other->Lab DeviceLink Profile

Hi,

It seems that there is an inversion in test:
inside function: _cmsReadDevicelinkLUT (cmsio1.c: 747 and 751 on version 2.4, but version 2.5 might be affected too):

if (cmsGetPCS(hProfile) == cmsSigLabData) {
        cmsPipelineInsertStage(Lut, cmsAT_BEGIN, _cmsStageAllocLabV4ToV2(ContextID));
}

if (cmsGetColorSpace(hProfile) == cmsSigLabData) {
        cmsPipelineInsertStage(Lut, cmsAT_END, _cmsStageAllocLabV2ToV4(ContextID));
}

Should be replaced by:
if (cmsGetColorSpace(hProfile) == cmsSigLabData) {
cmsPipelineInsertStage(Lut, cmsAT_BEGIN, _cmsStageAllocLabV4ToV2(ContextID));
}

if (cmsGetPCS(hProfile) == cmsSigLabData) {
        cmsPipelineInsertStage(Lut, cmsAT_END, _cmsStageAllocLabV2ToV4(ContextID));
}

Thanks,
Eric

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.