mm2 / little-cms Goto Github PK
View Code? Open in Web Editor NEWA free, open source, CMM engine. It provides fast transforms between ICC profiles.
Home Page: https://www.littlecms.com
License: MIT License
A free, open source, CMM engine. It provides fast transforms between ICC profiles.
Home Page: https://www.littlecms.com
License: MIT License
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.
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?
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.
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.
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 function
CheckNamedColorLUT':
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 function
CheckXYZ2XYZLUT':
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 function
CombineGamma16':
lcms2-2.4/testbed/testcms2.c:2664: undefined reference to _cmsQuantizeVal' testcms2.o: In function
ExhaustiveCheck3DinterpolationTrilinear16':
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 function
ExhaustiveCheck3DinterpolationTetrahedral16':
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.
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?
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.
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 (
Line 94 in a47e96c
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.building lcms-1.19:
cmsio1.c:118:8: warning: implicit declaration of function ‘swab’
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
in the libpng 1.6, they claimed the old hp srgb color profile has problem, the old HP sRGP profile has a bad whitepoint and they're trying to do away with it. So is it possible the creast_sRGBProfile create the new v4 or any good version of the SRGB color profile.
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
The white point tag triggers a warning in
$ iccDumpProfile -v devicelink.icc
...
Profile has warning(s)
Warning! - LinkClass - Tag exclusion test failed.
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
when convert from TYPE_RGBA8 TO TYPE_RGBA16
the alpha channel seems been discarded. the alpha channel should be scaled.
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.
None of the current parametric transfer curves seem equipped to handle SMPTE ST.2048.
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.
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)
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
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
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 ?
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
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)
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.
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=
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
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
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
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
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
Profiles created using cmsCreateRGBProfileTHR() appear to always get the D50 white point, not whatever is passed in. Is this a bug?
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
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
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).
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
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
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).
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;
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?
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.
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?
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
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).
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
?
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
Compile:
g++ -fno-omit-frame-pointer -fsanitize=address -g3 roundtrip.c -o roundtrip -I../../include/ -L../../src/.libs/ -llcms2
Run:
./roundtrip ../../testbed/test1.icc
==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);
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
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.
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
~~~~ ^ ~
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.