lcms-user — For users of the little cms library

Re: [Lcms-user] converting to K-only CMYK

[Marti M. <mar...@li...>]

Hello,

Indeed a very good question.

The short answer is  no, there is no way in traditional ICC workflow to do
that.

The long answer is, yes, we can do it with some additional effort. 

As you already know, an ICC profile is a "black box" that performs color
space translations. In the case of a CMYK profile, we have a black box that
converts CIE L*a*b <=> CMYK. Since CMYK is a 4 dimension space and CIE
L*a*b* has 3 dimensions, there are redundancy and when converting Lab ->
CMYK the profile has to choose one from the many ways it can do it. 

On the other hand, black ink often is not pure black, it has some chroma for
a observer adapted to D50 which is the ICC PCS. So, when we feed gray Lab
to a CMYK profile, we often get CMY components. This is the gray generation
and each profile vendor does it differently.

sRGB here is out of the equation, what you need is a customized profile that
would return K (and only K!) For all PCS input.  To build it,  we need also
a conversion to gray. Since Lab is very good in splitting chroma and luma,
we  can use (L*, 0, 0) to force gray values. 

Here is the cooking recipe:

- Create a CMYK to Lab transform by using your CMYK profile.
- Measure L* of K at regular points by using this transform. i.e. for (k=0;
k < 255; k++)  transform (0, 0, 0, k) -> Lab;  get L and discard a, b;  
- Normalize those point from 0..100 to 0..0xffff and create a sampled tone
curve. This curve will implement L*(k), and should be monotonic. If not
monotonic, the CMYK profile is not good and the game is over 
- Reverse the curve by using cmsReverseToneCurveEx. You will end with a
curve implementing K(L*)
- Create a constant zero tone curve by using two points set to 0.
- Build a profile with cmsCreateLinearizationDeviceLink by using the
reversed curve for L* and two zero curves for a* and *b. Mark this profile
as Lab as input and 3 channels as output. Probably labeling it as output
profile would be a good move. The profile has a weir output format (K, 0, 0)
but this makes things a lot simpler. To do it "well" you would need to use a
CLUT. 

Now you can use this profile as output in a sRGB to KXX transform. You will
find K in the first output channel. As additional bonus you can use any
input profile other than sRGB and any color other than R=G=B.

Regards
Marti Maria
The LittleCMS project
http://www.littlecms.com 

-----Original Message-----
From: Peter Wang [mailto:nov...@gm...] 
Sent: miércoles, 7 de septiembre de 2016 3:11
To: lcm...@li...
Subject: [Lcms-user] converting to K-only CMYK

Hi,

Is there a recommended way to convert a gray level in a source profile
(namely sRGB) to a K value in a CMYK space?  That is, I would like the C,M,Y
channels to be zero.

Peter

(sorry if this is a repost)

----------------------------------------------------------------------------
--
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] converting to K-only CMYK

[Peter W. <nov...@gm...>]

Hi,

Is there a recommended way to convert a gray level in a source profile
(namely sRGB) to a K value in a CMYK space?  That is, I would like the
C,M,Y channels to be zero.

Peter

(sorry if this is a repost)

Re: [Lcms-user] Using an embedded profile

[Christopher P. <cpo...@gl...>]

I have never looked into color management before, or had to deal with it. Taken with a huge grain of salt.



________________________________
From: Marco Freudenberger <Mar...@en...>
Sent: Friday, September 2, 2016 3:35:36 PM
To: Christopher Polewczuk; lcm...@li...
Subject: RE: Using an embedded profile

Christopher,

that depends on the profiles and settings. In most real world scenarios, they are not. Usually, especially when using 8bit per channel (in contrast to for example unbound floating point) it's not reversible without a certain loss of information due to integer math and gamut clipping. If you convert an image from one profile to the other, one of the profiles will likely have a smaller gamut, so you lose either "color range" or "color accuracy", otherwise the profiles would be identical or don't make much sense in color management (for example, exchanging channels or reversing).

Back to you example - you might likely end up with something like:
"Original image" (= RGB value in input color space) -> 224,122,50
"Transformed Image" (= 'closest match' RGB value in destination color space) -> 255, 110,80
transformed back to original color space: (= 'closest match' RGB value to that in input color space) -> 212, 123, 48
Also, it rarely makes sense to transform images force and back.

Excuse me for being so direct, I hope you don't take this as offence, but your questions seem to be "extremely basic" and not so much related to the implementation or usage of littleCMS, but touching very basics of color management in general, don't you think a basic training in color management might be a good idea before trying to use a library to implement a color managed application?

Best regards,
Marco

From: Christopher Polewczuk [mailto:cpo...@gl...]
Sent: Freitag, 2. September 2016 16:59
To: lcm...@li...
Subject: Re: [Lcms-user] Using an embedded profile

More specifically I guess I am wondering if it is possible to reverse a transform with a profile.

Original Image 224,122,50
Transformed Image 224,122,18
Then convert from the transformed image back to 224,122,50

Thanks

Re: [Lcms-user] Using an embedded profile

[Marco F. <Mar...@en...>]

Christopher,

that depends on the profiles and settings. In most real world scenarios, they are not. Usually, especially when using 8bit per channel (in contrast to for example unbound floating point) it's not reversible without a certain loss of information due to integer math and gamut clipping. If you convert an image from one profile to the other, one of the profiles will likely have a smaller gamut, so you lose either "color range" or "color accuracy", otherwise the profiles would be identical or don't make much sense in color management (for example, exchanging channels or reversing).

Back to you example - you might likely end up with something like:
"Original image" (= RGB value in input color space) -> 224,122,50
"Transformed Image" (= 'closest match' RGB value in destination color space) -> 255, 110,80
transformed back to original color space: (= 'closest match' RGB value to that in input color space) -> 212, 123, 48
Also, it rarely makes sense to transform images force and back.

Excuse me for being so direct, I hope you don't take this as offence, but your questions seem to be "extremely basic" and not so much related to the implementation or usage of littleCMS, but touching very basics of color management in general, don't you think a basic training in color management might be a good idea before trying to use a library to implement a color managed application?

Best regards,
Marco

From: Christopher Polewczuk [mailto:cpo...@gl...]
Sent: Freitag, 2. September 2016 16:59
To: lcm...@li...
Subject: Re: [Lcms-user] Using an embedded profile

More specifically I guess I am wondering if it is possible to reverse a transform with a profile.

Original Image 224,122,50
Transformed Image 224,122,18
Then convert from the transformed image back to 224,122,50

Thanks

Re: [Lcms-user] Using an embedded profile

[Christopher P. <cpo...@gl...>]

More specifically I guess I am wondering if it is possible to reverse a transform with a profile.

Original Image 224,122,50
Transformed Image 224,122,18
Then convert from the transformed image back to 224,122,50

Thanks

Re: [Lcms-user] Lcms-user Digest, Vol 112, Issue 1

[Roger B. <gr...@vi...>]

I was going to say, make sure you assign the same ICC profile to the image
in Photoshop that you use to make the conversion in Lcms. Otherwise, you are
comparing apples with oranges.

/ Roger

-----Original Message-----
From: lcm...@li...
[mailto:lcm...@li...] 
Sent: Thursday, September 1, 2016 8:06 AM
To: lcm...@li...
Subject: Lcms-user Digest, Vol 112, Issue 1

Send Lcms-user mailing list submissions to
	lcm...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/lcms-user
or, via email, send a message with subject or body 'help' to
	lcm...@li...

You can reach the person managing the list at
	lcm...@li...

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Lcms-user digest..."


Today's Topics:

   1. Conversion issues (Christopher Polewczuk)
   2. Re: Conversion issues (Christopher Polewczuk)
   3. Re: Conversion issues (Marti Maria)


----------------------------------------------------------------------

Message: 1
Date: Wed, 31 Aug 2016 13:30:50 +0000
From: Christopher Polewczuk <cpo...@gl...>
Subject: [Lcms-user] Conversion issues
To: "lcm...@li..."
	<lcm...@li...>
Message-ID:
	
<YQB...@YQ....
COM>
	
Content-Type: text/plain; charset="us-ascii"

I have a rgb tiff with an embedded profile from a calibrated scanner. I am
using that profile and an output sRGB profile, but the results do not match
photoshop's results, when opening the same file and converting with the
inbuilt profile.

The results do match gimp though, but our color calibration tool matches
photoshop.

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 2
Date: Wed, 31 Aug 2016 17:16:25 +0000
From: Christopher Polewczuk <cpo...@gl...>
Subject: Re: [Lcms-user] Conversion issues
To: "lcm...@li..."
	<lcm...@li...>
Message-ID:
	
<YQB...@YQ....
COM>
	
Content-Type: text/plain; charset="us-ascii"

For my input profile,

Color Space : Rgb
Pcs: Lab

I do a transform from the embedded profile to lab using
cmsCreateLab4Profile,Then I convert from lab to rgb using
cmsCreateLab4Profile & cmsCreate_sRGBProfile. No flags and using perceptual
from the icc

The resulting image is darker than the one generated in photoshop or gimp.

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Wed, 31 Aug 2016 20:28:07 +0200
From: Marti Maria <mar...@li...>
Subject: Re: [Lcms-user] Conversion issues
To: Christopher <cpo...@gl...>, lcms-user
	<lcm...@li...>
Message-ID: <fkd...@em...>
Content-Type: text/plain; charset="utf-8"

Hi,
In general, lcms matches quite well photoshop. But to get same results you
have to use same profiles and same settings. For example, if PS is using the
file based sRGB v2, you should use this file instead of the built-in sRGB,
which is v4. In perceptual and converting to lab there is a difference
between v2 and v4. You could also use a direct transform, from the embedded
profile to v2  sRGB. Tifficc may be handy here. If the direct transform
fails, send me the embedded profile and a the numbers of a couple of rgb
values (please, don't send the whole tiff!) And i will take a look.
Regards
Marti
On Aug 31, 2016 7:16 PM, Christopher Polewczuk
<cpo...@gl...> wrote:
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

----------------------------------------------------------------------------
--


------------------------------

_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user


End of Lcms-user Digest, Vol 112, Issue 1
*****************************************

[Lcms-user] Using an embedded profile

[Christopher P. <cpo...@gl...>]

I am trying to emulate the same results as Photoshop and gimp when choosing the option to keep the embedded profile, not to convert to the working profile.

How can I go about doing this?

Thanks.

Re: [Lcms-user] Conversion issues

[Marti M. <mar...@li...>]

Hi,
In general, lcms matches quite well photoshop. But to get same results you have to use same profiles and same settings. For example, if PS is using the file based sRGB v2, you should use this file instead of the built-in sRGB, which is v4. In perceptual and converting to lab there is a difference between v2 and v4. You could also use a direct transform, from the embedded profile to v2  sRGB. Tifficc may be handy here. If the direct transform fails, send me the embedded profile and a the numbers of a couple of rgb values (please, don't send the whole tiff!) And i will take a look.
Regards
Marti
On Aug 31, 2016 7:16 PM, Christopher Polewczuk <cpo...@gl...> wrote:

Re: [Lcms-user] Conversion issues

[Christopher P. <cpo...@gl...>]

For my input profile,

Color Space : Rgb
Pcs: Lab

I do a transform from the embedded profile to lab using cmsCreateLab4Profile,Then I convert from lab to rgb using cmsCreateLab4Profile & cmsCreate_sRGBProfile. No flags and using perceptual from the icc

The resulting image is darker than the one generated in photoshop or gimp.

[Lcms-user] Conversion issues

[Christopher P. <cpo...@gl...>]

I have a rgb tiff with an embedded profile from a calibrated scanner. I am using that profile and an output sRGB profile, but the results do not match photoshop's results, when opening the same file and converting with the inbuilt profile.

The results do match gimp though, but our color calibration tool matches photoshop.

Re: [Lcms-user] Soft proofing problems when the destination profile supports unbounded profile conversions

[Tobias E. <me...@ho...>]

Am Mittwoch, 17. August 2016, 13:32:51 CEST schrieb Marti Maria:
> > don't you just have to introduce a range model of the media being proofed
> 
> ?
> 
> Hi Graeme, neat idea. And while I was trying to implement that, I found a
> solution that seems simpler to me.
> 
> What about a function like that:
> 
> cmsBool cmsAllowUnboundedMode(cmsHPROFILE hProfile, cmsBool on)

So that setting would become part of the profile instead of the transform? I 
would prefer the latter as I tend to keep profiles around in memory and using 
them once for softproofing would taint them for other uses with a system as 
proposed.

> So, the user could turn on/off the unbounded processing per-profile basis.
> Then, soft proofing would always turn off unbounded mode of proofed profile.
> if you want to gamut check in unbounded mode, you could still roundtrip the
> profile by using multiprofile transforms.
> 
> Doing that means a change on the behavior of standard softproofing, but this
> is just what we intend for, right? and the CMM grows in one interesting
> feature.
> 
> Thoughts?
> 
> Marti Maria
> The LittleCMS project
> http://www.littlecms.com

Tobias

[...]

Re: [Lcms-user] Soft proofing problems when the destination profile supports unbounded profile conversions

[Marti M. <mar...@li...>]

> don't you just have to introduce a range model of the media being proofed
?

Hi Graeme, neat idea. And while I was trying to implement that, I found a
solution that seems simpler to me.

What about a function like that:

cmsBool cmsAllowUnboundedMode(cmsHPROFILE hProfile, cmsBool on)


So, the user could turn on/off the unbounded processing per-profile basis.
Then, soft proofing would always turn off unbounded mode of proofed profile.
if you want to gamut check in unbounded mode, you could still roundtrip the
profile by using multiprofile transforms.  

Doing that means a change on the behavior of standard softproofing, but this
is just what we intend for, right? and the CMM grows in one interesting
feature.

Thoughts?

Marti Maria
The LittleCMS project
http://www.littlecms.com 

-----Original Message-----
From: Graeme Gill [mailto:gr...@ar...] 
Sent: viernes, 12 de agosto de 2016 2:23
To: LCMS mailing list <lcm...@li...>
Subject: Re: [Lcms-user] Soft proofing problems when the destination profile
supports unbounded profile conversions

Marti Maria wrote:

> Anybody else on that? I would like to know what lcms users  think and 
> eventually modify the behavior for next release.

Hi Marti,
	don't you just have to introduce a range model of the media being
proofed ?

For (say) printed media, the corresponding model would clip the CMYK value
to the range 0.0 - 1.0. For some other media (i.e. your hypothetical file
format), the appropriate range would be enforced.

Bonus points for the range model emitting a meta-channel flagging out of
gamut values.

Cheers,

Graeme.


----------------------------------------------------------------------------
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Marti M. <mar...@li...>]

>temp = pow(abs(x))
>out = copysign(temp, x)

Yes, this is reasonable. But it should be placed in the profile by the
profile creator, not performed by the CMM. 
CMM should never "guess" data. If the profile gives a valid math expression
for negative numbers, the CMM is free to use it and deal with negative
numbers, or to clip to zero as many CMMs does.  
But this does not work in the inverse way: if the profile does NOT give any
clue on what to do on negative numbers,  then the CMM has to clip them to
zero. This is a sort of critical thing for inter-operability sake.

Regards
Marti Maria
The LittleCMS project
http://www.littlecms.com 

-----Original Message-----
From: Kevin Wheatley [mailto:kev...@gm...] 
Sent: miércoles, 17 de agosto de 2016 11:05
To: LCMS mailing list <lcm...@li...>
Subject: Re: [Lcms-user] Negative channel values are clipped upon floating
point conversions to profiles with true gamma TRCs

besides the cases already covered with gamut mapping etc, you can also get
"negative" values due to uncertainty of where black is. Take for example the
case of a digital sensor in a camera, if you capture with the lens cap on,
noise will mean you will get a range of values about a mean value, if this
is value considered as 0 then there will be some pixels where the value is
less than zero, throwing away this by clipping degrades the quality of the
images.

on the subject of extending/extrapolating trc, one approach is to mirror the
function similar to Elle's suggestion using

temp = pow(abs(x))
out = copysign(temp, x)

this tends to be reasonable as it gives a continuous gradient.

Kevin

----------------------------------------------------------------------------
--
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Marco F. <Mar...@en...>]

I see, I was assuming pow() being a sqr function :-)

Thanks.

-----Original Message-----
From: Kevin Wheatley [mailto:kev...@gm...] 
Sent: Mittwoch, 17. August 2016 12:39
To: Marco Freudenberger
Cc: LCMS mailing list
Subject: Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

On Wed, Aug 17, 2016 at 10:21 AM, Marco Freudenberger <Mar...@en...> wrote:
> All,
>
> excuse me, not all that important and I didn't follow the details of the previous discussion.
> I didn't understand why the pow() function might have any issues with negative values.
>         pow(abs(x)) == pow(x)
> or where is my thought mistake?

ignoring the mistake I made with only including the value x and missing the y parameter, the function pow(x, y)

when x is negative and y is not an integer then mathematically you can't represent it as a real number in the general case, that is why it returns NaN see https://en.wikipedia.org/wiki/Exponentiation#Real_exponents_with_negative_bases

Kevin

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Kevin W. <kev...@gm...>]

On Wed, Aug 17, 2016 at 10:21 AM, Marco Freudenberger
<Mar...@en...> wrote:
> All,
>
> excuse me, not all that important and I didn't follow the details of the previous discussion.
> I didn't understand why the pow() function might have any issues with negative values.
>         pow(abs(x)) == pow(x)
> or where is my thought mistake?

ignoring the mistake I made with only including the value x and
missing the y parameter, the function pow(x, y)

when x is negative and y is not an integer then mathematically you
can't represent it as a real number in the general case, that is why
it returns NaN see
https://en.wikipedia.org/wiki/Exponentiation#Real_exponents_with_negative_bases

Kevin

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Marco F. <Mar...@en...>]

All,

excuse me, not all that important and I didn't follow the details of the previous discussion.
I didn't understand why the pow() function might have any issues with negative values.
	pow(abs(x)) == pow(x)
or where is my thought mistake?



-----Original Message-----
From: Kevin Wheatley [mailto:kev...@gm...] 
Sent: Mittwoch, 17. August 2016 11:05
To: LCMS mailing list
Subject: Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

besides the cases already covered with gamut mapping etc, you can also get "negative" values due to uncertainty of where black is. Take for example the case of a digital sensor in a camera, if you capture with the lens cap on, noise will mean you will get a range of values about a mean value, if this is value considered as 0 then there will be some pixels where the value is less than zero, throwing away this by clipping degrades the quality of the images.

on the subject of extending/extrapolating trc, one approach is to mirror the function similar to Elle's suggestion using

temp = pow(abs(x))
out = copysign(temp, x)

this tends to be reasonable as it gives a continuous gradient.

Kevin

------------------------------------------------------------------------------
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Kevin W. <kev...@gm...>]

besides the cases already covered with gamut mapping etc, you can also
get "negative" values due to uncertainty of where black is. Take for
example the case of a digital sensor in a camera, if you capture with
the lens cap on, noise will mean you will get a range of values about
a mean value, if this is value considered as 0 then there will be some
pixels where the value is less than zero, throwing away this by
clipping degrades the quality of the images.

on the subject of extending/extrapolating trc, one approach is to
mirror the function similar to Elle's suggestion using

temp = pow(abs(x))
out = copysign(temp, x)

this tends to be reasonable as it gives a continuous gradient.

Kevin

[Lcms-user] Suggestion to get the 'System' color profile

[Roger B. <gr...@vi...>]

Thank YOU!!! So much, Edgar.

It is a LOT of arbeit!

MfG / Roger

----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Aug 2016 10:14:39 +0200
From: Edgar Loser <lo...@co...>
Subject: Re: [Lcms-user] Suggestion to get the 'System' color profile
	(monitor) on Windows?
To: lcm...@li...
Message-ID: <c03...@co...>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi Roger,

I had it on my ToDo list as well: Get the system profile for monitor.

I published some C# code here
http://stackoverflow.com/questions/13533754/code-example-for-wcsgetdefaultco
lorprofile/38959070#38959070

Edgar

Am 12.07.2016 um 20:26 schrieb Roger Breton:
> Looks like LittleCMS does not offer any help as far as retrieving the 
> host system "Active" monitor profile on Windows.
>
> Been searching a number of possible places.
>
> I guess I have to look at WcsGetDefaultColorProfile?
>
> Suppose I finally obtain the information, how would I then be able to 
> pass this information to LittleCMS?
>
> Another interesting challenge...
>
> Best / Roger
>
> BTW Is there a way to change my subscription from daily digest?
>
>
>
>
> ----------------------------------------------------------------------
> -------- What NetFlow Analyzer can do for you? Monitors network 
> bandwidth and traffic patterns at an interface-level. Reveals which 
> users, apps, and protocols are consuming the most bandwidth. Provides 
> multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make 
> informed decisions using capacity planning 
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

--
lakeBits Inh. Edgar Loser
Haydnstr. 25
78464 Konstanz
Tel 0049 7531 5844154 0
Fax 0049 7531 5844154 9
http://www.colymp.com/
mailto:lo...@co...



------------------------------

----------------------------------------------------------------------------
--


------------------------------

_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user


End of Lcms-user Digest, Vol 111, Issue 5
*****************************************

Re: [Lcms-user] Suggestion to get the 'System' color profile (monitor) on Windows?

[Edgar L. <lo...@co...>]

Hi Roger,

I had it on my ToDo list as well: Get the system profile for monitor.

I published some C# code here
http://stackoverflow.com/questions/13533754/code-example-for-wcsgetdefaultcolorprofile/38959070#38959070

Edgar

Am 12.07.2016 um 20:26 schrieb Roger Breton:
> Looks like LittleCMS does not offer any help as far as retrieving the host
> system "Active" monitor profile on Windows.
>
> Been searching a number of possible places.
>
> I guess I have to look at WcsGetDefaultColorProfile?
>
> Suppose I finally obtain the information, how would I then be able to pass
> this information to LittleCMS?
>
> Another interesting challenge...
>
> Best / Roger
>
> BTW Is there a way to change my subscription from daily digest?
>
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

-- 
lakeBits Inh. Edgar Loser
Haydnstr. 25
78464 Konstanz
Tel 0049 7531 5844154 0
Fax 0049 7531 5844154 9
http://www.colymp.com/
mailto:lo...@co...

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Graeme G. <gr...@ar...>]

Noel Carboni wrote:

> To us negative values can't possibly make sense.

Note that in some contexts they do. Viewed as a 3D space,
there are an infinite range of possible coordinates.

When transforming through different appearance spaces,
you can end up with intermediate values that are valid
(in the sense that they mean something) but that are
imaginary (they correspond to no realizable color).

If you are gamut mapping, then you would like even imaginary
values to be mapped in a way that preserves their fundamental
characteristics (hue, lightness, saturation) as much as
possible, as well as their relationships between each other.

Clipping -ve per component values is easy to implement, but
just like the whiter than the white point case, you can
end up with hue shifts and other undesirable changes to
the intended color.

Graeme Gill.

Re: [Lcms-user] Soft proofing problems when the destination profile supports unbounded profile conversions

[Graeme G. <gr...@ar...>]

Marti Maria wrote:

> Anybody else on that? I would like to know what lcms users  think and
> eventually modify the behavior for next release.

Hi Marti,
	don't you just have to introduce a range model
of the media being proofed ?

For (say) printed media, the corresponding model would clip the CMYK value
to the range 0.0 - 1.0. For some other media (i.e. your hypothetical file format),
the appropriate range would be enforced.

Bonus points for the range model emitting a meta-channel flagging
out of gamut values.

Cheers,

Graeme.

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Elle S. <ell...@ni...>]

On 08/11/2016 06:37 AM, Marti Maria wrote:
>
> Hi,
>
>> but would code like this make it possible to not clip when converting at
> floating point to a profile with a true gamma TRC?
>
>
> Pow of a negative values is a NaN for very good reasons. I can extend
> parametric curves that have negative domain defined, but guessing numbers is
> a bad  practice because would work for some cases and completely fail on
> others. If you use the extension you propose to pivot points in gamut
> mapping, for example, the results will come completely messed out.
>
> sRGB can do be extended, because in lower part gamma uses a linear ramp that
> is defined in negative zone. AdobeRGB cannot because is a pure exponential.

Hi Marti,

What you say makes sense as numbers calculated using my suggestion for 
getting around the NaN issue do very rapidly get very large. Does this 
means these RGB numbers don't produce the same XYZ colors in the 
destination color space as in the source color space?

I have a follow-up question. For unbounded floating point conversions to 
sRGB, values below zero are extended linearly. Are values above 1.0 also 
extended linearly, perhaps using the slope at 1.0? I had assumed they 
were extended using gamma=2.4 calculations, but now I'm guessing this 
assumption might be wrong.

Best regards,
Elle

>
> Regards
>
> Marti Maria
> The LittleCMS project
> http://www.littlecms.com
>
> -----Original Message-----
> From: Elle Stone [mailto:ell...@ni...]
> Sent: miércoles, 10 de agosto de 2016 16:26
> To: Lcms Liste <lcm...@li...>
> Subject: [Lcms-user] Negative channel values are clipped upon floating point
> conversions to profiles with true gamma TRCs
>
> Hi Marti and all,
>
> It seems that floating point (unbounded) conversions to RGB matrix profiles
> with true gamma TRCs (other than gamma=1.0), such as ClayRGB with gamma=2.2
> TRC, will clip negative channel values to zero. But unbounded conversions to
> profiles with parametric TRCs, such as the sRGB parametric TRC, does not
> clip negative channel values.
>
> I understand that pow(value, gamma) is undefined for negative values, but
> would code like this make it possible to not clip when converting at
> floating point to a profile with a true gamma TRC? Or perhaps the results
> wouldn't make any sense?
>
> if (value < 0)
>        {
>        value = -1.0 * value;
>        value =  pow (value, gamma);
>        value = -1.0 * value;
>        }
>
> Best regards,
> Elle
> --
> http://ninedegreesbelow.com
> Color management and free/libre photography
>

Re: [Lcms-user] Soft proofing problems when the destination profile supports unbounded profile conversions

[Elle S. <ell...@ni...>]

On 08/11/2016 06:31 AM, Marti Maria wrote:
>
> Hello Elle et al,
>
> I've been considering the case and here are some thoughts.
>
> I understand that when softproofing  some "perfect" profiles would be nice
> to return gamut clip, no matter the profile does not apply this clip in
> unbounded mode.
>
> The amount of changes in lcms code to implement this is not trivial.
> Actually, softproofing is implemented as a multiprofile transform with a
> round trip of proofed profile in the middle. If the profile does not
> introduce any artifact, then roundtrip is same and proofing does not show
> any change. To implement what you ask for, I have to clip values before and
> after this roundtrip.
> There are some use cases lost if I do this change. Just imagine somebody
> previewing which artifacts would get if using a certain embedded profile in
> a floating point image file format. If the file format supports negatives
> and highlights, the embedded profile would have no effect, and actually this
> is what softproofing gives you: the right answer. After the modification you
> ask for, the softproofing will return a gamut clip that the file format will
> not suffer. Of course this may be just a corner case, but this is just a
> sample.
>
> Anybody else on that? I would like to know what lcms users  think and
> eventually modify the behavior for next release.

Hi Marti,

Thank you! very much! for considering the use case of soft proofing to a 
profile that supports unbounded conversions, and having the soft proofed 
channel values be clipped to show what the image will look like at 
integer precision.

Given the use case you mention of converting to floating point where the 
user really does want to see the unclipped results, perhaps a flag to 
clip negative channel values (that could be used when soft proofing), 
and another flag to clip channel values >1.0? This would cover three 
different use cases: 1. the user doesn't want to clip; 2. the user only 
wants to clip negative channel values because the goal is to convert to 
a floating point file format that supports channel values > 1.0f but not 
negative channel values; 3. the user wants to convert to integer 
precision for output for printing or display on the web.

Best regards,
Elle

Re: [Lcms-user] Negative channel values are clipped upon floating point conversions to profiles with true gamma TRCs

[Marti M. <mar...@li...>]

Hi,

> but would code like this make it possible to not clip when converting at
floating point to a profile with a true gamma TRC?


Pow of a negative values is a NaN for very good reasons. I can extend
parametric curves that have negative domain defined, but guessing numbers is
a bad  practice because would work for some cases and completely fail on
others. If you use the extension you propose to pivot points in gamut
mapping, for example, the results will come completely messed out. 

sRGB can do be extended, because in lower part gamma uses a linear ramp that
is defined in negative zone. AdobeRGB cannot because is a pure exponential.

Regards

Marti Maria
The LittleCMS project
http://www.littlecms.com 

-----Original Message-----
From: Elle Stone [mailto:ell...@ni...] 
Sent: miércoles, 10 de agosto de 2016 16:26
To: Lcms Liste <lcm...@li...>
Subject: [Lcms-user] Negative channel values are clipped upon floating point
conversions to profiles with true gamma TRCs

Hi Marti and all,

It seems that floating point (unbounded) conversions to RGB matrix profiles
with true gamma TRCs (other than gamma=1.0), such as ClayRGB with gamma=2.2
TRC, will clip negative channel values to zero. But unbounded conversions to
profiles with parametric TRCs, such as the sRGB parametric TRC, does not
clip negative channel values.

I understand that pow(value, gamma) is undefined for negative values, but
would code like this make it possible to not clip when converting at
floating point to a profile with a true gamma TRC? Or perhaps the results
wouldn't make any sense?

if (value < 0)
       {
       value = -1.0 * value;
       value =  pow (value, gamma);
       value = -1.0 * value;
       }

Best regards,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography

----------------------------------------------------------------------------
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Soft proofing problems when the destination profile supports unbounded profile conversions

[Marti M. <mar...@li...>]

Hello Elle et al,

I've been considering the case and here are some thoughts.

I understand that when softproofing  some "perfect" profiles would be nice
to return gamut clip, no matter the profile does not apply this clip in
unbounded mode. 

The amount of changes in lcms code to implement this is not trivial.
Actually, softproofing is implemented as a multiprofile transform with a
round trip of proofed profile in the middle. If the profile does not
introduce any artifact, then roundtrip is same and proofing does not show
any change. To implement what you ask for, I have to clip values before and
after this roundtrip.

There are some use cases lost if I do this change. Just imagine somebody
previewing which artifacts would get if using a certain embedded profile in
a floating point image file format. If the file format supports negatives
and highlights, the embedded profile would have no effect, and actually this
is what softproofing gives you: the right answer. After the modification you
ask for, the softproofing will return a gamut clip that the file format will
not suffer. Of course this may be just a corner case, but this is just a
sample.

Anybody else on that? I would like to know what lcms users  think and
eventually modify the behavior for next release.

Best regards,
Marti Maria
The LittleCMS project
http://www.littlecms.com 

-----Original Message-----
From: Elle Stone [mailto:ell...@ni...] 
Sent: miércoles, 10 de agosto de 2016 12:24
To: Lcms Liste <lcm...@li...>
Subject: [Lcms-user] Soft proofing problems when the destination profile
supports unbounded profile conversions

Hi Marti and all,

I am unable to get useable results when using GIMP (which uses LCMS) to soft
proof from an RGB working space profile to an output profile.

Soft proofing only provides useable visual results if the destination
profile doesn't support unbounded ICC profile conversions (this is with the
gamut checks disabled, as the gamut checks introduce additional issues):

      * Soft proofing to a LUT printer profile that doesn't support
unbounded ICC profile conversions works the way I expect soft proofing to
work: Out of gamut colors are clipped during soft proofing and so they
display as they would be displayed if the image were actually converted to
the destination profile.

      * Soft proofing to a matrix RGB profile with a point curve (such as a
V2 sRGB profile) also works as expected - again the out of gamut colors are
clipped during the soft proofing conversion.

      * But soft proofing to a matrix RGB profile that has a parametric TRC
(such as V4 sRGB with a parametric TRC) does *not* produce the expected
results. Instead of being clipped to the color gamut of the destination
color space, the soft proofed colors are simply converted using channel
values that are less than zero and/or greater than 1.0f. 
This is the case even when the image is at integer precision, and so of
course the image colors will be clipped as soon as the actual ICC profile
conversion is done.

       So when soft proofing to profiles that support unbounded profile
conversions the "soft proofed" colors look exactly like they would look if
the user hadn't activated soft proofing. So the user has no visual
indication that colors might actually be out of gamut, which entirely
defeats the point of soft proofing.

       Would it be possible to put in a flag for soft proofing that says
"after transforming to the destination profile clip the channel values to
fit within the bounded color gamut of the destination color space, even if
the profile supports unbounded conversons"?

Or even make it the default behavior that soft proofing results are clipped
to the bounded color gamut of the destination color space? 
Personally I can't think of a single use case for soft proofing where
results of soft proofing shouldn't reflect the actual *bounded* color gamut
of the destination color space.

Speaking of flags, I've tried modifying the GIMP soft proofing transform
code to use "cmsFLAGS_NONEGATIVES". But using or not using this flag doesn't
seem to have any effect on the soft proofing transform (though it definitely
affects normal ICC profile conversions). Is this by design? Or perhaps is
there an issue with the GIMP code that sets up the soft proofing transform?

Best regards,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography

----------------------------------------------------------------------------
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user