lcms-user Mailing List for Little cms color engine (Page 15)
An ICC-based CMM for color management
Brought to you by:
mm2
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(15) |
Jun
(24) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(12) |
Nov
(17) |
Dec
(31) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(34) |
Feb
(7) |
Mar
(7) |
Apr
(16) |
May
(4) |
Jun
(14) |
Jul
(34) |
Aug
(54) |
Sep
(11) |
Oct
(25) |
Nov
(1) |
Dec
(6) |
2003 |
Jan
(27) |
Feb
(54) |
Mar
(23) |
Apr
(68) |
May
(82) |
Jun
(36) |
Jul
(45) |
Aug
(45) |
Sep
(49) |
Oct
(30) |
Nov
(65) |
Dec
(23) |
2004 |
Jan
(52) |
Feb
(52) |
Mar
(35) |
Apr
(38) |
May
(93) |
Jun
(22) |
Jul
(51) |
Aug
(50) |
Sep
(73) |
Oct
(28) |
Nov
(30) |
Dec
(51) |
2005 |
Jan
(22) |
Feb
(79) |
Mar
(38) |
Apr
(51) |
May
(95) |
Jun
(60) |
Jul
(56) |
Aug
(49) |
Sep
(22) |
Oct
(43) |
Nov
(15) |
Dec
(40) |
2006 |
Jan
(51) |
Feb
(31) |
Mar
(37) |
Apr
(25) |
May
(9) |
Jun
(13) |
Jul
(17) |
Aug
(66) |
Sep
(7) |
Oct
(12) |
Nov
(14) |
Dec
(31) |
2007 |
Jan
(18) |
Feb
(9) |
Mar
(22) |
Apr
(18) |
May
(5) |
Jun
(25) |
Jul
(2) |
Aug
(15) |
Sep
(12) |
Oct
(40) |
Nov
(10) |
Dec
(23) |
2008 |
Jan
(21) |
Feb
(56) |
Mar
(12) |
Apr
(23) |
May
(47) |
Jun
(75) |
Jul
(24) |
Aug
(2) |
Sep
(7) |
Oct
(26) |
Nov
(20) |
Dec
(16) |
2009 |
Jan
(14) |
Feb
(1) |
Mar
(29) |
Apr
(54) |
May
(18) |
Jun
(16) |
Jul
(5) |
Aug
(3) |
Sep
(38) |
Oct
(6) |
Nov
(25) |
Dec
(28) |
2010 |
Jan
(11) |
Feb
(26) |
Mar
(2) |
Apr
(10) |
May
(45) |
Jun
(94) |
Jul
(11) |
Aug
(32) |
Sep
(18) |
Oct
(37) |
Nov
(19) |
Dec
(34) |
2011 |
Jan
(21) |
Feb
(16) |
Mar
(16) |
Apr
(29) |
May
(17) |
Jun
(18) |
Jul
(7) |
Aug
(21) |
Sep
(10) |
Oct
(7) |
Nov
(15) |
Dec
(6) |
2012 |
Jan
(13) |
Feb
(16) |
Mar
(15) |
Apr
(12) |
May
(15) |
Jun
(31) |
Jul
(22) |
Aug
(15) |
Sep
(46) |
Oct
(21) |
Nov
(15) |
Dec
(33) |
2013 |
Jan
(19) |
Feb
(17) |
Mar
(31) |
Apr
(17) |
May
(27) |
Jun
(24) |
Jul
(26) |
Aug
(11) |
Sep
(9) |
Oct
(22) |
Nov
(14) |
Dec
(16) |
2014 |
Jan
(20) |
Feb
(66) |
Mar
(29) |
Apr
(13) |
May
(9) |
Jun
|
Jul
(11) |
Aug
(21) |
Sep
(15) |
Oct
(5) |
Nov
(5) |
Dec
(10) |
2015 |
Jan
(6) |
Feb
(26) |
Mar
(26) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(5) |
Aug
(11) |
Sep
(8) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
(9) |
Apr
(3) |
May
(16) |
Jun
(26) |
Jul
(32) |
Aug
(27) |
Sep
(9) |
Oct
|
Nov
(4) |
Dec
(10) |
2017 |
Jan
(11) |
Feb
(44) |
Mar
(6) |
Apr
(8) |
May
(1) |
Jun
(2) |
Jul
(34) |
Aug
(28) |
Sep
(3) |
Oct
(9) |
Nov
(3) |
Dec
|
2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(6) |
Dec
|
2019 |
Jan
(18) |
Feb
(16) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(3) |
Oct
(10) |
Nov
(1) |
Dec
(3) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(17) |
Jun
(23) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(10) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
(8) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(13) |
Nov
(12) |
Dec
|
2023 |
Jan
|
Feb
(1) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(5) |
Jul
(3) |
Aug
(8) |
Sep
|
Oct
|
Nov
(1) |
Dec
(9) |
2024 |
Jan
(8) |
Feb
|
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Elle S. <ell...@ni...> - 2017-03-01 12:46:04
|
On 03/01/2017 04:48 AM, Martí Maria wrote: > > > Hi Elle, > > After checking the sample, there is a small glitch in tifficc which I > will fix in next release. The glitch is the "of 9 channels" part of > error message. The error diagnostic should be only "unsupported color > space". Hi Marti, I would have made this bug report even if "unsupported color space" had been the error message, as this still makes it sound like the profile is the problem. Perhaps "unsupported color space for file format" might be more informative? > You got this because TIFF files does not support, at least not > directly, XYZ spaces. See > https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf In tiff6.pdf XYZ is mentioned 7 times in various contexts, but there doesn't seem to be a statement that XYZ isn't supported. Are you saying that because XYZ is not explicitly listed in Part 1 (Baseline TIFF) or Part 2 (TIFF Extensions) it's not supported to save an XYZ image to disk as a TIFF? What file formats do support the XYZ color space? I don't personally use XYZ for editing, but apparently some people do find use cases. I can verify (from testing) that tiffs can indeed be saved to disk in the XYZ color space and then opened again, with the XYZ data intact. Best, Elle |
From: Martí M. <mar...@li...> - 2017-03-01 09:49:07
|
Hi Elle, After checking the sample, there is a small glitch in tifficc which I will fix in next release. The glitch is the "of 9 channels" part of error message. The error diagnostic should be only "unsupported color space". You got this because TIFF files does not support, at least not directly, XYZ spaces. See https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf Thanks for reporting Regards Marti On 01/03/2017 0:52, Elle Stone wrote: > On 02/28/2017 04:20 PM, Marti wrote: >> Hi Elle, >> >> Profiles seems ok, and tifficc and other programs read them just fine. >> May I have the " red-no-alpha.tif" tiff file? It seems to me this is the >> source of trouble. > > Hi Marti, and thanks! for checking into this. Here's a link to the file: > > http://ninedegreesbelow.com/files/test-images/red-no-alpha.tif > > Best, > Elle > >> >> Regards >> Marti >> >> -----Original Message----- >> From: Elle Stone [mailto:ell...@ni...] >> Sent: Tuesday, February 28, 2017 8:21 PM >> To: Lcms Liste <lcm...@li...> >> Subject: [Lcms-user] tificc reports "Unsupported color space of 9 >> channels" >> with XYZ profile >> >> Hi All, >> >> I tried to use tificc v6.2 [LittleCMS 2.08] to convert an sRGB image >> to XYZ >> and got this error message: >> >> [tificc fatal error]: Unsupported color space of 9 channels >> >> One possibility is that the XYZ profile is defective, but it seems to >> produce exactly correct conversions with test images. >> >> So I'm wondering if there might be a problem in tificc itself. Does >> tificc >> actually support conversions to XYZ? >> >> Here's the command line I used with a sample image called >> "red-no-alpha.tif": >> >> tificc -w32 -i sRGB-elle-V4-srgbtrc.icc -o XYZ-D50-Identity-elle-V4.icc >> red-no-alpha.tif red-tificc.tif >> >> The two profiles can be downloaded here: >> https://github.com/ellelstone/elles_icc_profiles and are located in the >> "profiles" folder. >> >> The code snippet that generates the XYZ profile is as follows: >> >> profile = cmsCreateXYZProfile(); >> cmsWriteTag(profile, cmsSigCopyrightTag, copyright); description = >> cmsMLUalloc(NULL, 1); cmsMLUsetASCII(description, "en", "US", >> "XYZ-D50-Identity-elle-V4.icc"); >> filename = >> "../profiles/XYZ-D50-Identity-elle-V4.icc"; >> cmsSaveProfileToFile(profile, filename); cmsMLUfree(description); >> >> >> Thanks! for any help in figuring out what the issue is, whether in >> tificc or in the profile (or both?). >> >> Best, >> Elle >> > > |
From: Elle S. <ell...@ni...> - 2017-03-01 00:12:01
|
On 02/28/2017 04:20 PM, Marti wrote: > Hi Elle, > > Profiles seems ok, and tifficc and other programs read them just fine. > May I have the " red-no-alpha.tif" tiff file? It seems to me this is the > source of trouble. Hi Marti, and thanks! for checking into this. Here's a link to the file: http://ninedegreesbelow.com/files/test-images/red-no-alpha.tif Best, Elle > > Regards > Marti > > -----Original Message----- > From: Elle Stone [mailto:ell...@ni...] > Sent: Tuesday, February 28, 2017 8:21 PM > To: Lcms Liste <lcm...@li...> > Subject: [Lcms-user] tificc reports "Unsupported color space of 9 channels" > with XYZ profile > > Hi All, > > I tried to use tificc v6.2 [LittleCMS 2.08] to convert an sRGB image to XYZ > and got this error message: > > [tificc fatal error]: Unsupported color space of 9 channels > > One possibility is that the XYZ profile is defective, but it seems to > produce exactly correct conversions with test images. > > So I'm wondering if there might be a problem in tificc itself. Does tificc > actually support conversions to XYZ? > > Here's the command line I used with a sample image called > "red-no-alpha.tif": > > tificc -w32 -i sRGB-elle-V4-srgbtrc.icc -o XYZ-D50-Identity-elle-V4.icc > red-no-alpha.tif red-tificc.tif > > The two profiles can be downloaded here: > https://github.com/ellelstone/elles_icc_profiles and are located in the > "profiles" folder. > > The code snippet that generates the XYZ profile is as follows: > > profile = cmsCreateXYZProfile(); > cmsWriteTag(profile, cmsSigCopyrightTag, copyright); description = > cmsMLUalloc(NULL, 1); cmsMLUsetASCII(description, "en", "US", > "XYZ-D50-Identity-elle-V4.icc"); > filename = > "../profiles/XYZ-D50-Identity-elle-V4.icc"; > cmsSaveProfileToFile(profile, filename); cmsMLUfree(description); > > > Thanks! for any help in figuring out what the issue is, whether in > tificc or in the profile (or both?). > > Best, > Elle > -- http://ninedegreesbelow.com Color management and free/libre photography |
From: Marti <mar...@li...> - 2017-02-28 21:20:51
|
Hi Elle, Profiles seems ok, and tifficc and other programs read them just fine. May I have the " red-no-alpha.tif" tiff file? It seems to me this is the source of trouble. Regards Marti -----Original Message----- From: Elle Stone [mailto:ell...@ni...] Sent: Tuesday, February 28, 2017 8:21 PM To: Lcms Liste <lcm...@li...> Subject: [Lcms-user] tificc reports "Unsupported color space of 9 channels" with XYZ profile Hi All, I tried to use tificc v6.2 [LittleCMS 2.08] to convert an sRGB image to XYZ and got this error message: [tificc fatal error]: Unsupported color space of 9 channels One possibility is that the XYZ profile is defective, but it seems to produce exactly correct conversions with test images. So I'm wondering if there might be a problem in tificc itself. Does tificc actually support conversions to XYZ? Here's the command line I used with a sample image called "red-no-alpha.tif": tificc -w32 -i sRGB-elle-V4-srgbtrc.icc -o XYZ-D50-Identity-elle-V4.icc red-no-alpha.tif red-tificc.tif The two profiles can be downloaded here: https://github.com/ellelstone/elles_icc_profiles and are located in the "profiles" folder. The code snippet that generates the XYZ profile is as follows: profile = cmsCreateXYZProfile(); cmsWriteTag(profile, cmsSigCopyrightTag, copyright); description = cmsMLUalloc(NULL, 1); cmsMLUsetASCII(description, "en", "US", "XYZ-D50-Identity-elle-V4.icc"); filename = "../profiles/XYZ-D50-Identity-elle-V4.icc"; cmsSaveProfileToFile(profile, filename); cmsMLUfree(description); Thanks! for any help in figuring out what the issue is, whether in tificc or in the profile (or both?). Best, Elle -- http://ninedegreesbelow.com Color management and free/libre photography ---------------------------------------------------------------------------- -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Lcms-user mailing list Lcm...@li... https://lists.sourceforge.net/lists/listinfo/lcms-user |
From: Elle S. <ell...@ni...> - 2017-02-28 19:44:40
|
Hi All, I tried to use tificc v6.2 [LittleCMS 2.08] to convert an sRGB image to XYZ and got this error message: [tificc fatal error]: Unsupported color space of 9 channels One possibility is that the XYZ profile is defective, but it seems to produce exactly correct conversions with test images. So I'm wondering if there might be a problem in tificc itself. Does tificc actually support conversions to XYZ? Here's the command line I used with a sample image called "red-no-alpha.tif": tificc -w32 -i sRGB-elle-V4-srgbtrc.icc -o XYZ-D50-Identity-elle-V4.icc red-no-alpha.tif red-tificc.tif The two profiles can be downloaded here: https://github.com/ellelstone/elles_icc_profiles and are located in the "profiles" folder. The code snippet that generates the XYZ profile is as follows: profile = cmsCreateXYZProfile(); cmsWriteTag(profile, cmsSigCopyrightTag, copyright); description = cmsMLUalloc(NULL, 1); cmsMLUsetASCII(description, "en", "US", "XYZ-D50-Identity-elle-V4.icc"); filename = "../profiles/XYZ-D50-Identity-elle-V4.icc"; cmsSaveProfileToFile(profile, filename); cmsMLUfree(description); Thanks! for any help in figuring out what the issue is, whether in tificc or in the profile (or both?). Best, Elle -- http://ninedegreesbelow.com Color management and free/libre photography |
From: Aaron B. <bo...@gm...> - 2017-02-27 16:53:49
|
On Mon, Feb 27, 2017 at 11:25 AM, Marco Freudenberger < Mar...@en...> wrote: > Well… any usual conversion from UTF-16 to char* (not sure if you expect to > store UTF-8 or whatever else encoding, I also don’t remember from the top > of my head which encoding libpng/the PNG specification expects). > > > > This is a bit off-topic for lcms J You should find plenty of options on > google. > Got it. Thanks again. Aaron *Von:* Aaron Boxer [mailto:bo...@gm...] > *Gesendet:* Montag, 27. Februar 2017 10:20 > *An:* Marco Freudenberger > *Cc:* lcm...@li... > *Betreff:* Re: [Lcms-user] Extract name from ICC profile > > > > Cool. So, this gives an array of wchar_t. > > I need to pass this to libpng, which is expecting a pointer to char. > > Is there an easy way of converting? > > Thanks > > Aaron > > > > On Mon, Feb 27, 2017 at 11:06 AM, Marco Freudenberger < > Mar...@en...> wrote: > > Not sure if it’s the best way, here’s a sniplet of what I was using once > to get the display name (C++11): > > > > // assuming you have the profile open – hprofile is the handle to the > profile > > cmsUInt32Number bufferSize = cmsGetProfileInfo(hprofile, > cmsInfoDescription, cmsNoLanguage, cmsNoCountry, nullptr, 0); > > size_t numWideChars = (bufferSize + 1) / 2; > > std::unique_ptr<wchar_t[]> description(new wchar_t[numWideChars]); > > cmsUInt32Number result = cmsGetProfileInfo(hprofile, cmsInfoDescription, > cmsNoLanguage, cmsNoCountry, description.get(), bufferSize); > > > > Note that you might want to check if the profile name is available a > certain language…. > > You also could directly store it to a pre-sized std::wstring rather than > the unique_ptr<wchar_t[]>; I don’t remember why Idid it that way. > > > > Marco > > > > *Von:* Aaron Boxer [mailto:bo...@gm...] > *Gesendet:* Montag, 27. Februar 2017 09:58 > *An:* lcm...@li... > *Betreff:* [Lcms-user] Extract name from ICC profile > > > > Hello Again, > > What is the best way of using lcms to extract an ICC profile name? > > Thanks so much, > > Aaron > > > |
From: Marco F. <Mar...@en...> - 2017-02-27 16:25:16
|
Well… any usual conversion from UTF-16 to char* (not sure if you expect to store UTF-8 or whatever else encoding, I also don’t remember from the top of my head which encoding libpng/the PNG specification expects). This is a bit off-topic for lcms ☺ You should find plenty of options on google. Marco Von: Aaron Boxer [mailto:bo...@gm...] Gesendet: Montag, 27. Februar 2017 10:20 An: Marco Freudenberger Cc: lcm...@li... Betreff: Re: [Lcms-user] Extract name from ICC profile Cool. So, this gives an array of wchar_t. I need to pass this to libpng, which is expecting a pointer to char. Is there an easy way of converting? Thanks Aaron On Mon, Feb 27, 2017 at 11:06 AM, Marco Freudenberger <Mar...@en...<mailto:Mar...@en...>> wrote: Not sure if it’s the best way, here’s a sniplet of what I was using once to get the display name (C++11): // assuming you have the profile open – hprofile is the handle to the profile cmsUInt32Number bufferSize = cmsGetProfileInfo(hprofile, cmsInfoDescription, cmsNoLanguage, cmsNoCountry, nullptr, 0); size_t numWideChars = (bufferSize + 1) / 2; std::unique_ptr<wchar_t[]> description(new wchar_t[numWideChars]); cmsUInt32Number result = cmsGetProfileInfo(hprofile, cmsInfoDescription, cmsNoLanguage, cmsNoCountry, description.get(), bufferSize); Note that you might want to check if the profile name is available a certain language…. You also could directly store it to a pre-sized std::wstring rather than the unique_ptr<wchar_t[]>; I don’t remember why Idid it that way. Marco Von: Aaron Boxer [mailto:bo...@gm...<mailto:bo...@gm...>] Gesendet: Montag, 27. Februar 2017 09:58 An: lcm...@li...<mailto:lcm...@li...> Betreff: [Lcms-user] Extract name from ICC profile Hello Again, What is the best way of using lcms to extract an ICC profile name? Thanks so much, Aaron |
From: Aaron B. <bo...@gm...> - 2017-02-27 16:19:53
|
Cool. So, this gives an array of wchar_t. I need to pass this to libpng, which is expecting a pointer to char. Is there an easy way of converting? Thanks Aaron On Mon, Feb 27, 2017 at 11:06 AM, Marco Freudenberger < Mar...@en...> wrote: > Not sure if it’s the best way, here’s a sniplet of what I was using once > to get the display name (C++11): > > > > // assuming you have the profile open – hprofile is the handle to the > profile > > cmsUInt32Number bufferSize = cmsGetProfileInfo(hprofile, > cmsInfoDescription, cmsNoLanguage, cmsNoCountry, nullptr, 0); > > size_t numWideChars = (bufferSize + 1) / 2; > > std::unique_ptr<wchar_t[]> description(new wchar_t[numWideChars]); > > cmsUInt32Number result = cmsGetProfileInfo(hprofile, cmsInfoDescription, > cmsNoLanguage, cmsNoCountry, description.get(), bufferSize); > > > > Note that you might want to check if the profile name is available a > certain language…. > > You also could directly store it to a pre-sized std::wstring rather than > the unique_ptr<wchar_t[]>; I don’t remember why Idid it that way. > > > > Marco > > > > *Von:* Aaron Boxer [mailto:bo...@gm...] > *Gesendet:* Montag, 27. Februar 2017 09:58 > *An:* lcm...@li... > *Betreff:* [Lcms-user] Extract name from ICC profile > > > > Hello Again, > > What is the best way of using lcms to extract an ICC profile name? > > Thanks so much, > > Aaron > |
From: Marco F. <Mar...@en...> - 2017-02-27 16:06:32
|
Not sure if it’s the best way, here’s a sniplet of what I was using once to get the display name (C++11): // assuming you have the profile open – hprofile is the handle to the profile cmsUInt32Number bufferSize = cmsGetProfileInfo(hprofile, cmsInfoDescription, cmsNoLanguage, cmsNoCountry, nullptr, 0); size_t numWideChars = (bufferSize + 1) / 2; std::unique_ptr<wchar_t[]> description(new wchar_t[numWideChars]); cmsUInt32Number result = cmsGetProfileInfo(hprofile, cmsInfoDescription, cmsNoLanguage, cmsNoCountry, description.get(), bufferSize); Note that you might want to check if the profile name is available a certain language…. You also could directly store it to a pre-sized std::wstring rather than the unique_ptr<wchar_t[]>; I don’t remember why Idid it that way. Marco Von: Aaron Boxer [mailto:bo...@gm...] Gesendet: Montag, 27. Februar 2017 09:58 An: lcm...@li... Betreff: [Lcms-user] Extract name from ICC profile Hello Again, What is the best way of using lcms to extract an ICC profile name? Thanks so much, Aaron |
From: Aaron B. <bo...@gm...> - 2017-02-27 15:58:29
|
Hello Again, What is the best way of using lcms to extract an ICC profile name? Thanks so much, Aaron |
From: Aaron B. <bo...@gm...> - 2017-02-27 15:21:45
|
Noel,Marco, Thanks! I understand - no gamma applied to alpha channel. Cheers, Aaron On Mon, Feb 27, 2017 at 10:01 AM, Noel Carboni < NCa...@pr...> wrote: > Hi Aaron, > > > > As far as I know, an alpha channel (transparency) is considered linear and > not subject to profile-based transformation. That says it should be > perfectly valid to have one - or not - in a profile-tagged image. > > > > Not long ago Marti added the ability for LittleCMS to preserve extra > channel values as a transform is done by Little CMS (e.g. for passing alpha > channel data through unchanged). That reduced the application code needed > to handle RGBA and GA data if transforms are not done in place (i.e., from > one buffer to another). > > > > -Noel > > > > *From:* Aaron Boxer [mailto:bo...@gm...] > *Sent:* Mon, February 27, 2017 9:33 AM > *To:* lcm...@li... > *Subject:* [Lcms-user] ICC Monochrome Input Profile and alpha > > > > Not directly related to lcms, but I have a question about the Monochrome > Input Profile: > > is it valid to have an image with this profile, and to also have an alpha > channel ? > > Thanks, > > Aaron > > > |
From: Noel C. <NCa...@Pr...> - 2017-02-27 15:01:44
|
Hi Aaron, As far as I know, an alpha channel (transparency) is considered linear and not subject to profile-based transformation. That says it should be perfectly valid to have one - or not - in a profile-tagged image. Not long ago Marti added the ability for LittleCMS to preserve extra channel values as a transform is done by Little CMS (e.g. for passing alpha channel data through unchanged). That reduced the application code needed to handle RGBA and GA data if transforms are not done in place (i.e., from one buffer to another). -Noel From: Aaron Boxer [mailto:bo...@gm...] Sent: Mon, February 27, 2017 9:33 AM To: lcm...@li... Subject: [Lcms-user] ICC Monochrome Input Profile and alpha Not directly related to lcms, but I have a question about the Monochrome Input Profile: is it valid to have an image with this profile, and to also have an alpha channel ? Thanks, Aaron |
From: Marco F. <Mar...@en...> - 2017-02-27 15:01:09
|
Aaron, Alpha channels are „independent“ from color profiles. There’s no reason why that wouldn’t be valid. Von: Aaron Boxer [mailto:bo...@gm...] Gesendet: Montag, 27. Februar 2017 08:33 An: lcm...@li... Betreff: [Lcms-user] ICC Monochrome Input Profile and alpha Not directly related to lcms, but I have a question about the Monochrome Input Profile: is it valid to have an image with this profile, and to also have an alpha channel ? Thanks, Aaron |
From: Aaron B. <bo...@gm...> - 2017-02-27 14:33:17
|
Not directly related to lcms, but I have a question about the Monochrome Input Profile: is it valid to have an image with this profile, and to also have an alpha channel ? Thanks, Aaron |
From: Aaron B. <bo...@gm...> - 2017-02-22 15:16:03
|
On Tue, Feb 21, 2017 at 3:51 PM, Marco Freudenberger <Marco.Freudenberger@ entrustdatacard.com> wrote: > Well, if you set BOTH gammas to 2.2, it should work. > > > > What test cases do you have and what are the expected results? > Unit tests compare decoded image with reference image, which were probably decoded with gamma=1.0 configuration. > >> > > |
From: Aaron B. <bo...@gm...> - 2017-02-22 15:15:03
|
On Tue, Feb 21, 2017 at 4:07 PM, Marco Freudenberger < Mar...@en...> wrote: > PS: A lot of the reaction of course also depend on how you handle the > image data once loaded – and obviously what your expected unit test results > are. > > > > I’ve tried to implement a full “image handling” library a while ago (a > layer up from libpng, tiff, …) , when I found that most higher level open > source library don’t do a very good job with color management in my > opinion, at least not the ones I’ve tested. Unfortunately I didn’t have the > time yet to finish it or get it to a point where it is really useful for > others, especially the “build system” is more than clunky (I wanted to > create cmake environment, so that it is easy to use it cross platform … ) > and the unit tests are more manual test entry points than real unit tests > at this time. Again haven’t got a lot of time to work on that as it’s a > private project and I’m currently loaded with job-work, but if I remember > correctly, the PNG READ handling should be OK to some extent. If I also > remember correctly, the code to write PNG files is not checked in as I > haven’t validated it’s correctness for all color formats and bit depths. > > > > The library Itself doesn’t do a lot “upstream” with the image files, > although I think the (more manual …) test code had some color space > conversion examples, especially like “convert everything to sRGB” if I > remember correctly. > > > > https://github.com/freudi74/mfimage > Cool project! Thanks for sharing this. > > *Von:* Marco Freudenberger > *Gesendet:* Dienstag, 21. Februar 2017 14:51 > *An:* 'Aaron Boxer' > *Cc:* Noel Carboni; lcm...@li... > *Betreff:* AW: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color > Space = cmsSigGrayData > > > > Well, if you set BOTH gammas to 2.2, it should work. > > > > What test cases do you have and what are the expected results? > > > > *Von:* Aaron Boxer [mailto:bo...@gm...] > *Gesendet:* Dienstag, 21. Februar 2017 12:58 > *An:* Marco Freudenberger > *Cc:* Noel Carboni; lcm...@li... > *Betreff:* Re: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color > Space = cmsSigGrayData > > > > > > > > On Tue, Feb 21, 2017 at 1:15 PM, Marco Freudenberger <Marco.Freudenberger@ > entrustdatacard.com> wrote: > > No. I’m actually talking about images that do not have an ICC profile > embedded. Well – maybe all, actually. > > > > Lines 187-191: > > > > if( !png_get_gAMA(png, info, &gamma)) > > > > gamma = 1.0; > > > > > > /* we're not displaying but converting, screen gamma == 1.0 */ > > png_set_gamma(png, 1.0, gamma); > > > > > > > > > > - You try to read the file gamma. If none found, you set it to > 1.0. That I think is the first mistake… > > - Then you set the screen gamma to 1.0. This is PROBABLY the > next mistake, as the typical screen gamma is ~ 2.2. Linear gamma is > unusual. The two “mistakes” might eliminate each other for images with NO > gAMA chunk (because no correction is done for the screen). > > - I think png_set_gamma actually makes sure that the RGB (or > gray …) values you are getting from the file are adjusted by (file gamma) / > (screen gamma) – so you are not reading the values originally encoded in > the file... I might be wrong, I didn’t check the documentation. > > So … > > - If the file has an embedded gamma of 2.2, you would modify the > values because the “screen gamma” is set to 1.0 > > > > Thanks. I tried using 2.2 and it broke a lot of my unit tests. I guess > allowing the user to set the gamma would be best - can blame the user if > something goes wrong :) > > > > > > Another big problem is, that this seems to be applied EVEN THOUGH an ICC > profile might be embedded in the file, which already does any file color > space -> screen color space for you. So if you have a file gamma AND an ICC > profile, you might change values (especially “light intensity” of colors) > while actually the ICC profile does all of that. > > IF you want to use the file gamma to correct images when displaying them > (or converting to another ICC profile), you should rather generate an “on > the fly” icc profile based on the file gamma (and given (cHRM chunk) or > assumed chromatic primaries rather than having libpng modifying the values > you read for you. This is often an area of confusion with libpng ... I hope > I expressed that all in a way that it can be understood… I’m not a English > is not my mothers tongue and I tend to make technical descriptions > extremely complicated … > > > > Thanks, your writing is crystal clear - just a lot of detail to think > over. I have changed my code so that gamma is only applied if there is no > ICC. > > > > Best, > > Aaron > |
From: Marco F. <Mar...@en...> - 2017-02-21 21:07:23
|
PS: A lot of the reaction of course also depend on how you handle the image data once loaded – and obviously what your expected unit test results are. I’ve tried to implement a full “image handling” library a while ago (a layer up from libpng, tiff, …) , when I found that most higher level open source library don’t do a very good job with color management in my opinion, at least not the ones I’ve tested. Unfortunately I didn’t have the time yet to finish it or get it to a point where it is really useful for others, especially the “build system” is more than clunky (I wanted to create cmake environment, so that it is easy to use it cross platform … ) and the unit tests are more manual test entry points than real unit tests at this time. Again haven’t got a lot of time to work on that as it’s a private project and I’m currently loaded with job-work, but if I remember correctly, the PNG READ handling should be OK to some extent. If I also remember correctly, the code to write PNG files is not checked in as I haven’t validated it’s correctness for all color formats and bit depths. The library Itself doesn’t do a lot “upstream” with the image files, although I think the (more manual …) test code had some color space conversion examples, especially like “convert everything to sRGB” if I remember correctly. https://github.com/freudi74/mfimage Hope that helps more than adding more confusion… Marco Von: Marco Freudenberger Gesendet: Dienstag, 21. Februar 2017 14:51 An: 'Aaron Boxer' Cc: Noel Carboni; lcm...@li... Betreff: AW: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color Space = cmsSigGrayData Well, if you set BOTH gammas to 2.2, it should work. What test cases do you have and what are the expected results? Von: Aaron Boxer [mailto:bo...@gm...] Gesendet: Dienstag, 21. Februar 2017 12:58 An: Marco Freudenberger Cc: Noel Carboni; lcm...@li... Betreff: Re: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color Space = cmsSigGrayData On Tue, Feb 21, 2017 at 1:15 PM, Marco Freudenberger <Mar...@en...<mailto:Mar...@en...>> wrote: No. I’m actually talking about images that do not have an ICC profile embedded. Well – maybe all, actually. Lines 187-191: if( !png_get_gAMA(png, info, &gamma)) gamma = 1.0; /* we're not displaying but converting, screen gamma == 1.0 */ png_set_gamma(png, 1.0, gamma); - You try to read the file gamma. If none found, you set it to 1.0. That I think is the first mistake… - Then you set the screen gamma to 1.0. This is PROBABLY the next mistake, as the typical screen gamma is ~ 2.2. Linear gamma is unusual. The two “mistakes” might eliminate each other for images with NO gAMA chunk (because no correction is done for the screen). - I think png_set_gamma actually makes sure that the RGB (or gray …) values you are getting from the file are adjusted by (file gamma) / (screen gamma) – so you are not reading the values originally encoded in the file... I might be wrong, I didn’t check the documentation. So … - If the file has an embedded gamma of 2.2, you would modify the values because the “screen gamma” is set to 1.0 Thanks. I tried using 2.2 and it broke a lot of my unit tests. I guess allowing the user to set the gamma would be best - can blame the user if something goes wrong :) Another big problem is, that this seems to be applied EVEN THOUGH an ICC profile might be embedded in the file, which already does any file color space -> screen color space for you. So if you have a file gamma AND an ICC profile, you might change values (especially “light intensity” of colors) while actually the ICC profile does all of that. IF you want to use the file gamma to correct images when displaying them (or converting to another ICC profile), you should rather generate an “on the fly” icc profile based on the file gamma (and given (cHRM chunk) or assumed chromatic primaries rather than having libpng modifying the values you read for you. This is often an area of confusion with libpng ... I hope I expressed that all in a way that it can be understood… I’m not a English is not my mothers tongue and I tend to make technical descriptions extremely complicated … Thanks, your writing is crystal clear - just a lot of detail to think over. I have changed my code so that gamma is only applied if there is no ICC. Best, Aaron |
From: Aaron B. <bo...@gm...> - 2017-02-21 18:59:35
|
> > On Tue, Feb 21, 2017 at 1:15 PM, Marco Freudenberger <Marco.Freudenberger@ > entrustdatacard.com> wrote: > >> No. I’m actually talking about images that do not have an ICC profile >> embedded. Well – maybe all, actually. >> >> >> >> Lines 187-191: >> >> >> >> if( !png_get_gAMA(png, info, &gamma)) >> >> gamma = 1.0; >> >> >> >> /* we're not displaying but converting, screen gamma == 1.0 */ >> >> png_set_gamma(png, 1.0, gamma); >> >> >> >> >> >> >> >> >> >> - You try to read the file gamma. If none found, you set it to >> 1.0. That I think is the first mistake… >> >> - Then you set the screen gamma to 1.0. This is PROBABLY the >> next mistake, as the typical screen gamma is ~ 2.2. Linear gamma is >> unusual. The two “mistakes” might eliminate each other for images with NO >> gAMA chunk (because no correction is done for the screen). >> >> - I think png_set_gamma actually makes sure that the RGB (or >> gray …) values you are getting from the file are adjusted by (file gamma) / >> (screen gamma) – so you are not reading the values originally encoded in >> the file... I might be wrong, I didn’t check the documentation. >> >> So … >> >> - If the file has an embedded gamma of 2.2, you would modify >> the values because the “screen gamma” is set to 1.0 >> >> > Thanks. I tried using 2.2 and it broke a lot of my unit tests. I guess > allowing the user to set the gamma would be best - can blame the user if > something goes wrong :) > >> >> > > >> Another big problem is, that this seems to be applied EVEN THOUGH an ICC >> profile might be embedded in the file, which already does any file color >> space -> screen color space for you. So if you have a file gamma AND an ICC >> profile, you might change values (especially “light intensity” of colors) >> while actually the ICC profile does all of that. >> >> IF you want to use the file gamma to correct images when displaying them >> (or converting to another ICC profile), you should rather generate an “on >> the fly” icc profile based on the file gamma (and given (cHRM chunk) or >> assumed chromatic primaries rather than having libpng modifying the values >> you read for you. This is often an area of confusion with libpng ... I hope >> I expressed that all in a way that it can be understood… I’m not a English >> is not my mothers tongue and I tend to make technical descriptions >> extremely complicated … >> > > Thanks, your writing is crystal clear - just a lot of detail to think > over. I have changed my code so that gamma is only applied if there is no > ICC. > > Best, > Aaron > |
From: Aaron B. <bo...@gm...> - 2017-02-21 18:00:05
|
Marco, Thanks so much for the code review, really appreciate the level of detail in your posts. It will take me some time to digest this information. One question - you mention that my current PNG reader might "creates issues if the file have “correct” embedded gAMA of 1/2.2 or something even better." Do you mean that the ICC profile may have a better gAMA than 1 ? In this case, if there is an ICC profile, I suppose I should not set gAMA, yes? Side note - one of the applications for my library is in medical imaging, CT scans etc. where I understand there is no need for a gamma curve. Thanks again, Aaron On Tue, Feb 21, 2017 at 11:51 AM, Marco Freudenberger < Mar...@en...> wrote: > Oh, and Aaron: > > > > I just saw you are setting compression to Z_BEST_COMPRESSION (9). That is > probably not a good idea either, because it can be REALLY slow with little > or none advantage in regards to the resulting file size. But that depends > on your application as well, if you rarely write images and they are > targeting the web, it MIGHT be the right thing to do. Although – I did > tests with some images and found that many times lower compression rates > even give you smaller file sizes. I ended up with using level 3, which is > ways faster and not really much worse, But that may really depend on the > images and perhaps on more detailed compression settings like compression > buffer sizes (of which libpng specification basically says “leave them > alone unless you know exactly what you are doing” – I didn’t so I left them > at defaults). > > > > Marco > > > > > > *Von:* Marco Freudenberger > *Gesendet:* Dienstag, 21. Februar 2017 10:45 > *An:* 'Aaron Boxer' > *Cc:* Noel Carboni; lcm...@li... > *Betreff:* AW: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color > Space = cmsSigGrayData > > > > > > Just something „cosmetic“: > > 1) I would set parameter 4 to PNG_COMPRESSION_TYPE_BASE rather than > 0 (same value, just more obvious what it means). > > 2) I would try to extract the ICC profile name from the profile > using lcms API (don’t remember how off the top of my head) and supply it as > parameter 3. > > Both are not required, just my love for detail… > > > > In regards to gAMA: I don’t see anything in the code that is writing the > image that actually deals with gAMA. However, there are a view things in > the image READ part regarding gama that make me wonder > > > > 1) The code assumes the gamma is 1.0 when there is no gAMA chunk > present. That is, what some image readers do, but I think this is really > bad practice, because according to the PNG specification you should use the > most likely gAMA of the system writing it. That would normally be either > ~2.2 or 1.8 (the latter if it was written by an old MAC OS). > > 2) Then you use png_set_gamma() to set the SCREEN gamma to 1.0; My > guess it that it’s extremely unlikely that the screen gamma is 1.0; it is > more likely ~2.2 (or 1.8 on old MACs), see above. This basically “fixes” > your assumption of file gamma of 1/1.0, but also creates issues if the file > have “correct” embedded gAMA of 1/2.2 or something even better. Also, I > think png_set_gamma() will “correct” the actual RGB or gray or whatever > values, in 8 bit mode, that means you might lose color precision… > Note that it’s a total misconception that a gamma value of 1.0 is a good > “neutral” or “default” value. For example, when reading files like BMP or > GIF or such without gamma information, you should – if you don’t know > better – that it has the same gamma as your screen, which is “nominally” > either sRGB gamma (~2.2) or 2.2. > > > > There are other things I saw, but it depends on how “serious” you are > about color management. Unfortunately, PNG is a bit complicated because the > specification wanted to make it “all right” and some applications do things > not according to the standard. > > > > 3) You seem to ignore the sRGB chunk, which – if present – > explicitely says an image is in sRGB color space. In that case, gamma = > sRGB gamma (~2.2) > > 4) You ignore the cHRM chunks. Depending on what level of color > management you want to achieve, it CAN be important to evaluate them > (chroma values are a “simplified way” to define a color space). Although, > they are rarely used. Applications that are serious about color management > usually embed ICC profiles in the image. > > 5) Depending on what version of libpng you are using – libpng > internally “explicitely” skips reading one specific sRGB profile > (identified I think by it’s length and name, don’t remember the details) > because the original author states that’s a “known bad” profile. I think it > is actually just a little bit inprecise. Unfortunately, that profile is > wide spread, and what libpng does – totally skipping the profile, leaving > you with no color information at all – is highly controversial, because it > leaves you behind without ANY color space information, although the intent > is that it should be sRGB. There is a configuration to turn that off: > > png_set_option(png, PNG_SKIP_sRGB_CHECK_PROFILE, PNG_OPTION_ON); // > turn “ON” skipping the check for an sRGB profile that is “wrong” in the > libpng author’s opinion -> i.e. allow that profile. > > > > Having that all said, I don’t really know what your exact use case is, > maybe all the above is “nitpicking” when it comes to your use case, but if > you are serious about color management, you should really try to have all > those things (and some more in regards to PNG) right, otherwise you might > be contributing to a lot of issues with the PNG format that are already > “out there”. An ambigious rule in the first version of the PNG > specification (I don’t remember what it was about) makes it even worse. I > think it took me ~2 weeks to fully handle all those cases, but my > application was really a high-precision color management application with > tons of images from different sources from customers. > > Many different applications handle PNG VERY differently unfortunately > (most of them wrong, even Photoshop, the reference app for color management > most of the time does some things about gAMA wrong) and the only way to > avoid any “customer specific maintenance” was to really make sure to go > 100% by the PNG specification and tell customers that THEIR IMAGES might > not be according to the standard. > > > > Marco > > > > > > *Von:* Aaron Boxer [mailto:bo...@gm... <bo...@gm...>] > *Gesendet:* Dienstag, 21. Februar 2017 07:34 > *An:* Marco Freudenberger > *Cc:* Noel Carboni; lcm...@li... > > *Betreff:* Re: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color > Space = cmsSigGrayData > > > > Hi Marco, > > Thanks a lot! Would you be able to take a quick look at my changes ? > > Commit is here: > > https://github.com/GrokImageCompression/grok/commit/ > 8d62e2252fefd4a15124cac73c7f47a65fde651d > > and complete file is here: > > https://github.com/GrokImageCompression/grok/blob/master/src/bin/jp2/ > convertpng.cpp > > Existing code already had some code for gamma curve, so perhaps I need to > disable that? > > Cheers, > > Aaron > > > > > > On Tue, Feb 21, 2017 at 2:28 AM, Marco Freudenberger <Marco.Freudenberger@ > entrustdatacard.com> wrote: > > Aaron, > > > > I might be able to help a little. > > > > You need to write the iCCP chunk. Also make sure you have no conflicting > entries in other chunks (sRGB, gAMA, cHRM chunk). PNG is a bit delicate in > terms of possible ambiguous color space info in header. > > You also need to know, that some PNG readers don’t handle the color space > chucks gracefully (specifically gAMA, cHRM – even Photoshop is clunky in > that aspect, at least if no iCCP chunk is present). > > > > Do you use libpng ? If so, you need to do call > > png_set_iCCP() > > during your file creation to write the ICC profile. > > > > Marco > > > > *Von:* Noel Carboni [mailto:NCa...@Pr...] > *Gesendet:* Montag, 20. Februar 2017 13:03 > *An:* 'Aaron Boxer' > *Cc:* lcm...@li... > *Betreff:* Re: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color > Space = cmsSigGrayData > > > > >Noel, do you know where I could find sample code to read/write ICC > profiles for PNG format? > > Sorry, I really don't, offhand. I'd probably rely heavy on Google for > that. > > > > -Noel > > > > > |
From: Aaron B. <bo...@gm...> - 2017-02-21 13:34:05
|
Hi Marco, Thanks a lot! Would you be able to take a quick look at my changes ? Commit is here: https://github.com/GrokImageCompression/grok/commit/8d62e2252fefd4a15124cac73c7f47a65fde651d and complete file is here: https://github.com/GrokImageCompression/grok/blob/master/src/bin/jp2/convertpng.cpp Existing code already had some code for gamma curve, so perhaps I need to disable that? Cheers, Aaron On Tue, Feb 21, 2017 at 2:28 AM, Marco Freudenberger < Mar...@en...> wrote: > Aaron, > > > > I might be able to help a little. > > > > You need to write the iCCP chunk. Also make sure you have no conflicting > entries in other chunks (sRGB, gAMA, cHRM chunk). PNG is a bit delicate in > terms of possible ambiguous color space info in header. > > You also need to know, that some PNG readers don’t handle the color space > chucks gracefully (specifically gAMA, cHRM – even Photoshop is clunky in > that aspect, at least if no iCCP chunk is present). > > > > Do you use libpng ? If so, you need to do call > > png_set_iCCP() > > during your file creation to write the ICC profile. > > > > Marco > > > > *Von:* Noel Carboni [mailto:NCa...@Pr...] > *Gesendet:* Montag, 20. Februar 2017 13:03 > *An:* 'Aaron Boxer' > *Cc:* lcm...@li... > *Betreff:* Re: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color > Space = cmsSigGrayData > > > > >Noel, do you know where I could find sample code to read/write ICC > profiles for PNG format? > > Sorry, I really don't, offhand. I'd probably rely heavy on Google for > that. > > > > -Noel > > > |
From: Marco F. <Mar...@en...> - 2017-02-21 08:02:55
|
Aaron, I might be able to help a little. You need to write the iCCP chunk. Also make sure you have no conflicting entries in other chunks (sRGB, gAMA, cHRM chunk). PNG is a bit delicate in terms of possible ambiguous color space info in header. You also need to know, that some PNG readers don’t handle the color space chucks gracefully (specifically gAMA, cHRM – even Photoshop is clunky in that aspect, at least if no iCCP chunk is present). Do you use libpng ? If so, you need to do call png_set_iCCP() during your file creation to write the ICC profile. Marco Von: Noel Carboni [mailto:NCa...@Pr...] Gesendet: Montag, 20. Februar 2017 13:03 An: 'Aaron Boxer' Cc: lcm...@li... Betreff: Re: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color Space = cmsSigGrayData >Noel, do you know where I could find sample code to read/write ICC profiles for PNG format? Sorry, I really don't, offhand. I'd probably rely heavy on Google for that. -Noel |
From: Noel C. <NCa...@Pr...> - 2017-02-20 19:02:51
|
>Noel, do you know where I could find sample code to read/write ICC profiles for PNG format? Sorry, I really don't, offhand. I'd probably rely heavy on Google for that. -Noel |
From: Aaron B. <bo...@gm...> - 2017-02-20 17:58:37
|
Noel, do you know where I could find sample code to read/write ICC profiles for PNG format? Thanks, Aaron On Mon, Feb 20, 2017 at 12:20 PM, Noel Carboni < NCa...@pr...> wrote: > > For other formats, such as PNG, I would need to transform. > > > > I believe a PNG file can carry a color profile tag, but there are > certainly formats that can't. > > > > Not to belabor this, but does your design specify what color space the > data will be in if it saved in an image file format that does not carry a > profile tag? > > > > There is no standard for what color space untagged images should be stored > in. Because of the mix of computers in the world and the things that have > been done in the past, you might meet expectations more of the time if you > were save color images in the sRGB IEC61966-2.1 color space. Windows has > been described as embracing "sRGB by default", for example. But that's up > to you. > > > > If you are anticipating prompting the user for target color space > information, then that could resolve the problem. > > > > -Noel > > > > *From:* Aaron Boxer [mailto:bo...@gm...] > *Sent:* Mon, February 20, 2017 12:02 PM > *To:* Noel Carboni > *Cc:* lcm...@li... > *Subject:* Re: [Lcms-user] Apply profile with PCS = cmsSigXYZData, Color > Space = cmsSigGrayData > > > > Thanks, Noel. That is a good point. For TIFF, I can store the profile in > the TIFF file, and avoid transforming. > > For other formats, such as PNG, I would need to transform. > > > > On Mon, Feb 20, 2017 at 11:49 AM, Noel Carboni < > NCa...@pr...> wrote: > > > Thanks, Noel. This is not for display on monitor. JPEG 2000 supports > embedded ICC profiles, and I am > > > trying to use the profile when decoding the image. > > > > I guess I'm still not clear: Why are you transforming the data into > another color space? > > > > If you're trying to decode it then save it as another kind of file (e.g., > .tiff or .jpg or something that can carry its own color profile tag), maybe > you should consider just maintaining the color profile it's already got. > > > > What I'm saying is that maybe you just want to decode the data, then save > the data in another file, and tag that file with the same profile the > JPEG2000 file started with, making no color transformation on the decoded > data at all. LittleCMS need not be involved with that. > > > > As Marti mentioned, if you DO want to transform the color values into a > different color space, you need to specify what that color space is. > > > > -Noel > > > > > |
From: Aaron B. <bo...@gm...> - 2017-02-20 17:53:07
|
Noel, thank you! I am beginning to understand. Currently, in my design, the user cannot specify the colour space that they will save the data in. I think this needs to be implemented. Currently, we always assume sRGB. But, for grayscale, this may not be the best approach, as you mentioned. Following your suggestion, for TIFF, I am now simply storing the ICC information in the TIFF file and NOT applying a transform. I will also look into doing this for PNG. For other formats, I will need to allow the user to specify the gamma and white point, I suppose. On Mon, Feb 20, 2017 at 12:34 PM, Noel Carboni < NCa...@pr...> wrote: > Oh, and one more thing I meant to mention... > > > > A tone curve with a pure 2.2 gamma function is very different than an sRGB > tone curve where it really counts - down in the small values (near black). > > > > Just thought I'd throw that out there as food for thought. > > > > -Noel > |
From: Aaron B. <bo...@gm...> - 2017-02-20 17:50:01
|
Thanks very much, Marti. Colour spaces are quite interesting! I will play around with this code. On Mon, Feb 20, 2017 at 12:04 PM, Martí Maria <mar...@li...> wrote: > > Hi, > > I just C&P from testbed, sorry. > > A portable function should be like this: > > static > cmsHPROFILE Create_Gray22(void) > { > cmsHPROFILE hProfile; > cmsToneCurve* Curve = cmsBuildGamma(0, 2.2); > if (Curve == NULL) return NULL; > > hProfile = cmsCreateGrayProfileTHR(0, cmsD50_xyY(), Curve); > cmsFreeToneCurve(Curve); > > return hProfile; > } > Regards > Marti > > > > On 20/02/2017 17:33, Aaron Boxer wrote: > > Thanks, Marti. Is the white point and transfer function not already > specified in the profile? Pardon my ignorance, > not that familiar with colour transforms. > > On Mon, Feb 20, 2017 at 11:28 AM, Martí Maria <mar...@li...> > wrote: > >> >> Hi, >> >> You need to specify white point and transfer function to >> cmsCreateGrayProfile(), see manual page 28 >> >> Regards >> >> Marti >> On 20/02/2017 7:04, Aaron Boxer wrote: >> >> 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: https://github.com/GrokImageCo >> mpression/grok/issues/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 >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> >> _______________________________________________ >> Lcms-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/lcms-user >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most engaging >> tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ Lcms-user mailing list >> Lcm...@li... https://lists.sourceforge.net/ >> lists/listinfo/lcms-user > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > _______________________________________________ > Lcms-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/lcms-user > > |