lcms-user — For users of the little cms library

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

[Noel C. <NCa...@Pr...>]

Thanks for the additional input, James.

 

I'll be honest - that individual channels may go negative while the overall luminance remains positive represents a new level of awareness for me.  We strive to get our color-management right and up to now I was considering negative values (observed to be very small in absolute value) as a bug or side effect of processing inaccuracy (we know Photoshop doesn't always get things perfect).  

 

We *haven't*, however, been using the cmsFLAGS_NONEGATIVES flag as we never observed negative values out of LittleCMS transforms.  We use LittleCMS to convert to our internal working space...  It's possible that without the clamping code our software will just work.  We already handle HDR (values greater than 1.0).

 

With this new level of understanding I'm going to look over whether the reasons we had been clamping negative values even still exist - it's possible because of my misunderstanding that they were only needed during development before our color-management infrastructure was fully implemented and matured.  We did not start out using a floating point internal representation at first, though we do now.

 

Thank you all for prompting me to revisit this.

 

-Noel 

 

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

[Noel C. <NCa...@Pr...>]

Thank you for the clarifications, Elle.

-Noel

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

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

On 08/10/2016 12:10 PM, Noel Carboni wrote:
> Just a comment related to negative numbers and practical usage...
>
> At ProDigital Software we make Photoshop plug-ins.  One set in
> particular adds lighting effects to images, and we handle any RGB format
> that Photoshop can deliver to us, including 32 bit floating point.
>
> We specifically had to add code that zeroes any negative values
> received, which we found were occasionally being delivered in  images
> expressed in the ColorMatch RGB space.
>
> To us negative values can't possibly make sense.
>
> Put another way, what's blacker than black?  Even modern physics doesn't
> attempt to describe what's inside the event horizon of a black hole.  At
> least not in the same realm as the physics that describe the visible
> universe.

Not all colors that have one or two negative channel value, also have 
negative Luminance. Luminance depends on all three channel values.

Profiles that support unbounded profile conversions include profiles 
with parametric curves such as the V4 sRGB parametric TRC. When using 
unbounded ICC profile conversions and working at floating point 
precision, one can convert any color from any color space to any other 
color space that supports unbounded ICC profile conversions. Any color 
that is out of gamut with respect to the destination color space will 
have one or two channel values that are less than zero.

I'm not sure whether clipping to zero for destination profiles with true 
gamma (non-linear-gamma) TRCs is intended behavior or not, but it 
certainly is unexpected based on how conversions to profiles with 
parametric TRCs behave.

If you don't want floating point conversions to profiles that support 
unbounded conversions, then use the cmsFLAGS_NONEGATIVES flag during the 
profile conversion.

> Granted, the code that ensures no negative values can exist wasn't hard
> to write nor particularly wasteful of resources, but it DOES take a
> little time.  From our perspective, if all color engines were to ensure
> only positive numbers would be generated (as LittleCMS does) we could
> have saved our user a little time starting our software every time it's
> run.
>
> I'm not making a hard case against lifting the restriction against
> emitting negative numbers from LittleCMS transforms, except to say that
> as a tool/engine we currently rely on the current behavior and if it's
> changed we'd like an OPTION to keep it working as it does now.

That restriction was lifted when LCMS V2 was first released and it's 
incredibly useful (understatement) and important contribution to ICC 
profile color management.

http://www.littlecms.com/CIC18_UnboundedCMM.pdf
http://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html
http://ninedegreesbelow.com/photography/high-bit-depth-gimp-tutorial-edit-tonality-color-separately.html#out-of-gamut-colors

Best,
Elle

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

[Noel C. <NCa...@Pr...>]

Just a comment related to negative numbers and practical usage...

At ProDigital Software we make Photoshop plug-ins.  One set in
particular adds lighting effects to images, and we handle any RGB format
that Photoshop can deliver to us, including 32 bit floating point.

We specifically had to add code that zeroes any negative values
received, which we found were occasionally being delivered in  images
expressed in the ColorMatch RGB space.

To us negative values can't possibly make sense.

Put another way, what's blacker than black?  Even modern physics doesn't
attempt to describe what's inside the event horizon of a black hole.  At
least not in the same realm as the physics that describe the visible
universe.

Granted, the code that ensures no negative values can exist wasn't hard
to write nor particularly wasteful of resources, but it DOES take a
little time.  From our perspective, if all color engines were to ensure
only positive numbers would be generated (as LittleCMS does) we could
have saved our user a little time starting our software every time it's
run.

I'm not making a hard case against lifting the restriction against
emitting negative numbers from LittleCMS transforms, except to say that
as a tool/engine we currently rely on the current behavior and if it's
changed we'd like an OPTION to keep it working as it does now.

Thanks.

-Noel

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

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

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/10/2016 06:55 AM, Tobias Ellinghaus wrote:
> That's exactly what I asked for a while ago. It seems that Marti isn't
> convinced of that idea. :-(
>
> https://sourceforge.net/p/lcms/mailman/message/35215540/

Hi Tobias, I was hoping maybe some additional pleading and begging might 
help :) .

Soft proofing is critically important. But the current situation seems 
to be that soft proofing is simply not useable for linear gamma source 
profiles (gamut checks are not reliable) or for destination profiles 
that support unbounded conversions (visual results are misleading).

I've stared long and hard at the LCMS soft proofing code to see if I can 
figure out how to modify LCMS directly. The "Clipper" code is easy to 
modify to also clip out of gamut positive values. But 
cmsFLAGS_NONEGATIVES doesn't affect soft proofing, and the actual LCMS 
soft proofing code is completely out of my league coding-wise.

So I've been trying to figure out where to intervene directly in the 
GIMP code, but so far haven't made much progress.

Best regards,
Elle

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

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

Am Mittwoch, 10. August 2016, 06:23:51 CEST schrieb Elle Stone:

[...]

>        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"?

That's exactly what I asked for a while ago. It seems that Marti isn't 
convinced of that idea. :-(

https://sourceforge.net/p/lcms/mailman/message/35215540/

[...]

> Best regards,
> Elle

Tobias

[Lcms-user] Soft proofing problems with gamut checks

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

Hi Marti and all,

When soft proofing with high bit depth GIMP, which uses LCMS, the gamut 
check isn't reliable. I've confirmed some of the issues using tificc at 
the command line, so it's not GIMP code per se.

1. When using the gamut check, when soft proofing to a destination color 
space that supports unbounded ICC profile conversions, the "bounded" 
color gamut of the source color space affects results. So colors that 
are marked as out of gamut in one source color space will show as in 
gamut in another source color space. In general, the closer the source 
and destination color space gamuts are, the larger the proportion of 
colors that are shown as in gamut with respect to the destination color 
space. This is true even if the entire image is actually out of gamut 
with respect to the selected destination color space.

2. The gamut check results vary depending on the TRC - this affects soft 
proofing not just to profiles that support unbounded conversions, but 
also to LUT printer profiles that don't support unbounded conversions:

      * The LCMS gamut check gives different results depending on 
whether the source color space has a linear gamma TRC or else has a more 
perceptually uniform TRC

      * When editing in a linear gamma RGB color space, the LCMS gamut 
check can easily show most or all of the image as out of gamut, even 
when the entire color gamut of the source image does fit in the 
destination color space's color gamut. Dark and midtone colors are 
marked as out of gamut.

      * For source color spaces with more or less perceptually uniform 
TRCs it seems the exact TRC of the source color space makes a difference 
in the results of soft proofing.

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

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

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

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

[Lcms-user] ANNOUNCE: Little CMS 2.8 released (fwd)

[Boudewijn R. <bo...@va...>]

Awesome news! There are two really big new features here,
alpha carry-through and strides that should allow us to
make krita much, much faster!

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

---------- Forwarded message ----------
Date: Sun, 24 Jul 2016 20:00:35 +0200
From: Marti Maria <mar...@li...>
To: lcm...@li...
Subject: [Lcms-user] ANNOUNCE: Little CMS 2.8 released

 

Hi,

 

I am glad to the announce the release 2.8 of the Little CMS open source
color engine.

 

This release has been sponsored by Alien Skin software
http://www.alienskin.com/

 

Version 2.8 is a featured release. It introduces alpha channel
transportation and a new type of plug-in for enhancing performance, among
bug fixes and other enhancements. XCode and Visual Studio 2015 are supported
in this release.

 

Many thanks to Alien Skin software and also to all users that have tested
this code.

 

Little CMS intends to be a small-footprint color management engine, with
special focus on accuracy and performance. It uses the International Color
Consortium standard (ICC), which is the modern standard when regarding to
color management.

 

The ICC specification is widely used and is referred to in many
International and other de-facto standards.

 

For more information, please take a look on:

 

Main site:

http://www.littlecms.com <http://www.littlecms.com/> 

 

Downloads:

http://www.littlecms.com/download.html

 

Best regards,

Marti Maria

The Little CMS project

 <http://www.littlecms.com/> http://www.littlecms.com

 

 

[Lcms-user] ANNOUNCE: Little CMS 2.8 released

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

 

Hi,

 

I am glad to the announce the release 2.8 of the Little CMS open source
color engine.

 

This release has been sponsored by Alien Skin software
http://www.alienskin.com/

 

Version 2.8 is a featured release. It introduces alpha channel
transportation and a new type of plug-in for enhancing performance, among
bug fixes and other enhancements. XCode and Visual Studio 2015 are supported
in this release.

 

Many thanks to Alien Skin software and also to all users that have tested
this code.

 

Little CMS intends to be a small-footprint color management engine, with
special focus on accuracy and performance. It uses the International Color
Consortium standard (ICC), which is the modern standard when regarding to
color management.

 

The ICC specification is widely used and is referred to in many
International and other de-facto standards.

 

For more information, please take a look on:

 

Main site:

http://www.littlecms.com <http://www.littlecms.com/> 

 

Downloads:

http://www.littlecms.com/download.html

 

Best regards,

Marti Maria

The Little CMS project

 <http://www.littlecms.com/> http://www.littlecms.com

 

 

[Lcms-user] Dumb question

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

My WPF application is starting to take shape -- thank's to Lcms and the help
from Edgar, Noel and the others -- I owe you a beer!

About V4 display profiles.

To understand, would there be an option to obtain an AbsCol conversion from,
say, a v2 D65 RGB profile to a D50-calibrated monitor where the result would
be "bluish", as it used to be in Photoshop CS5? Before Adobe started to
ignore the Media White point of the device?

I need to pursue this for pedagogical reasons.

I want to demonstrate an ICC profile conversion from, say, AdobeRGB or sRGB,
where the result is overall "bluish", in Absolute Colorimetry.

/ Roger

[Lcms-user] cmsFLAGS_GAMUTCHECK

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

Is it possible to cmsDoTransform with cmsFLAGS_GAMUTCHECK?

It looks like it's only possible with cmsCreateExtendedTransform and
cmsCreateProofingTransform, which I am not familiar with.

Is it anything like Photoshop Gamut Warning? 

I would like to convert an image such that, with GamutCheck, say, any out of
gamut colors of the Destination would come out with solid color pixels? 
Gray or red or does not matter.

I guess I am dreaming in color ;-)

Roger Breton

[Lcms-user] Black point compensation

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

I found the dwFlag... Easy to set up in cmsDoTransform :-)

Thank you / Roger Breton

[Lcms-user] Black point compensation

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

How do I go about implementing Black point compensation in
cmsCreateTransform?

On page 77 of LittleCMS API, in Table 40, the documentation shows only the
four basic ICC rendering intents.

I would like to use Relative Colorimetric with Black point compensation as
in Photoshop to convert from sRGB, say, to CMYK.

There is some mention of cmsFLAGS_BLACKPOINTCOMPENSATION on page 28 of the
Tutorial but my understanding is that this only serves "Proofing" transform.

Thank you / Roger Breton

Re: [Lcms-user] Check if ICC is sRGB-like

[Kornel <mai...@po...>]

Thank you for your response.

> On 19 Jul 2016, at 13:36, Richard Hughes <hug...@gm...> wrote:
> 
>> I'd rather not rely on metadata like descriptions of known ICC files, but identify arbitrary ICC profiles by properties of their color space.
> 
> Would doing a "mock" conversion of RGB ramps from one profile to
> another and calculating the delta E work? It might not be good enough
> to get the specifics of BPC and the like, but enough to tell the
> primaries and TRC is close to sRGB.

It's certainly possible. If I understand correctly, I'd have a test image, and convert it using input image's profile to e.g. Lab, and compare (using mean square error?) it to the same conversion using my reference sRGB profile.

How important it is to pick representative colors? If for example I test conversion only on black-red, black-green and black-blue gradients, are there cases where profiles could convert these particular gradients well enough, but behave differently on e.g. gray colors or cause a visible shift in hue?

> I could do something like this
> very easily in libcolord if this is an acceptable dep.

I'm not familiar with libcolord, but I have lcms2 as a dep.

-- 
Kind regards, Kornel

Re: [Lcms-user] Check if ICC is sRGB-like

[Richard H. <hug...@gm...>]

On 19 July 2016 at 13:08, Kornel <mai...@po...> wrote:
> I'd rather not rely on metadata like descriptions of known ICC files, but identify arbitrary ICC profiles by properties of their color space.

Would doing a "mock" conversion of RGB ramps from one profile to
another and calculating the delta E work? It might not be good enough
to get the specifics of BPC and the like, but enough to tell the
primaries and TRC is close to sRGB. I could do something like this
very easily in libcolord if this is an acceptable dep.

Richard

[Lcms-user] Check if ICC is sRGB-like

[Kornel <mai...@po...>]

What's the best way to check whether an ICC profile is "similar" to sRGB? (e.g. color profiles of monitors trying to be sRGB, rather than the canonical sRGB color space definition).

I'd like to convert a bunch of JPEG files with various embedded profiles to sRGB. The problem is that decoding+conversion+encoding is a lossy process, so I'd like to avoid it unless absolutely necessary. If the source image has an embedded color profile that is sRGB-ish, then stripping/replacing the profile without re-encoding may give higher quality, than a very slight colorspace conversion with re-encoding.

I'd rather not rely on metadata like descriptions of known ICC files, but identify arbitrary ICC profiles by properties of their color space.
 
-- 
Kind regards, Kornel

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

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

Hello Roger,

Lcms is portable and not tied to any operating system. Runs on windows, mac, linux but also on embedded systems and I'm pretty confident many people is using it in such way. So there is no way to get the system monitor because each operating system does it differently, there is no portable way to do that, and sometimes there is no monitor at all.

If you can manage to get the monitor profile, either as a file or in a memory block, you can use it in lcms by calling the appropiate cmsOpen... functions.

Regarding subscription options, goto www.littlecms.com and select "mailing list" in the menu at the top left. At the bottom of mailman page you can enter your mail to change options.

Regards
Marti.

On Jul 12, 2016 8:26 PM, Roger Breton <gr...@vi...> wrote:
>
> 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 

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

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

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?

Re: [Lcms-user] Softproofing with parametric tonecurve

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

> However, I am a little puzzled by that design choice. I guess (just a gut 
> feeling) that most people would use softproofing to see the result they 
> get on a physical medium

That is exactly the point. The profile you are using does NOT represent a physical 
medium but an idealized color space. If the profile would represent a physical 
medium, then it will work as you expect. 

You could also try to use 8 bit instead of floats and cmsFLAGS_NOOPTIMIZE.  

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

-----Original Message-----
From: Tobias Ellinghaus [mailto:me...@ho...] 
Sent: martes, 12 de julio de 2016 12:01
To: lcm...@li...
Subject: Re: [Lcms-user] Softproofing with parametric tonecurve

On Donnerstag, 23. Juni 2016 19:13:26 CEST Marti Maria wrote:
> Ok, I see. A profile created in this way, with primaries and 
> parametric curves, behaves like a "perfect" profile. That is, it can 
> be inverted with no loss and its gamut is infinite. You can operate 
> this profile with negative rgb or xyz values. Or with values well over 
> 255. And the roundtrip is exact. So, if you tries to emulate which 
> artifacts the profile causes, the answer is none and this is what you are getting in your softproofing.
> Built-in srgb behaves in same way.
> 
> Another thing is when you flush the profile to disk. Then you are 
> forcing a quantized representation (in the case of v2)  Also, doing 
> that imposes a gamut because no negative numbers or highlights over L* 
> 100 are allowed in the file format. Then softproofing shows you the 
> limitations the file format has.
> 
> So you have to choose whatever the ideal representation and the file based.
> 
> Hope this makes sense to you

Thanks, I changed my code to always take a roundtrip through dumping/reading for softproof profiles and it seems to work fine. However, I am a little puzzled by that design choice. I guess (just a gut feeling) that most people would use softproofing to see the result they get on a physical medium – or anything else that clips the colors. Especially when specifying a rendering intent for the transform.

Would it be possible to add a transform flag like cmsFLAGS_SOFTPROOFING_CLIPPED that does a clipping in an appropriate place? That might be less surprising and avoid the overhead of creating a new profile on the fly.

And maybe document the general issue where softproofing is explained?

> Regards
> Marti

Thank you a lot, even if you don't consider adding what I proposed. lcms is an awesome help and I wouldn't like to do without it.

Tobias

Re: [Lcms-user] Softproofing with parametric tonecurve

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

On Donnerstag, 23. Juni 2016 19:13:26 CEST Marti Maria wrote:
> Ok, I see. A profile created in this way, with primaries and parametric
> curves, behaves like a "perfect" profile. That is, it can be inverted with
> no loss and its gamut is infinite. You can operate this profile with
> negative rgb or xyz values. Or with values well over 255. And the roundtrip
> is exact. So, if you tries to emulate which artifacts the profile causes,
> the answer is none and this is what you are getting in your softproofing.
> Built-in srgb behaves in same way.
> 
> Another thing is when you flush the profile to disk. Then you are forcing a
> quantized representation (in the case of v2)  Also, doing that imposes a
> gamut because no negative numbers or highlights over L* 100 are allowed in
> the file format. Then softproofing shows you the limitations the file
> format has.
> 
> So you have to choose whatever the ideal representation and the file based.
> 
> Hope this makes sense to you

Thanks, I changed my code to always take a roundtrip through dumping/reading 
for softproof profiles and it seems to work fine. However, I am a little puzzled 
by that design choice. I guess (just a gut feeling) that most people would use 
softproofing to see the result they get on a physical medium – or anything else 
that clips the colors. Especially when specifying a rendering intent for the 
transform.

Would it be possible to add a transform flag like cmsFLAGS_SOFTPROOFING_CLIPPED 
that does a clipping in an appropriate place? That might be less surprising 
and avoid the overhead of creating a new profile on the fly.

And maybe document the general issue where softproofing is explained?

> Regards
> Marti

Thank you a lot, even if you don't consider adding what I proposed. lcms is an 
awesome help and I wouldn't like to do without it.

Tobias

[Lcms-user] cmsGetProfileInfo -- Got i!

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

Edgar (and others).

I was not aware of this technique of calling the function *twice*, once to
request the required buffer size and once to request the actual characters.

Your explanation helped greatly.

> cmsGetProfileInfo has to be called twice:
> The first time you pass 0 (Buffer and BufferSize) and cmsGetProfileInfo is
calculating how much memory you have to allocate.
> Then you allocate the memory,
> and call it a second time (passing a pointer to the buffer, and the
calculated size in BufferSize).
> After you're done it's your last job to free this memory.

I also found help here, on msdn :

https://social.msdn.microsoft.com/Forums/vstudio/en-US/d5b655b8-2dde-48f7-9a
be-a0259e2cf08b/dllimport-correct-c-signature?forum=csharpgeneral

and here :

https://limbioliong.wordpress.com/2011/11/01/using-the-stringbuilder-in-unma
naged-api-calls/

Which completely explains the technique.

> Note: Language code and country code are char, i.e. not unicode.
> imho they should be marshaled as
> UnmanagedType.LPStr or UnmanagedType.AnsiBStr

I chose to use the Unicode route, after all.

When I tried with call signature :

[DllImport(@lcms2Path, CharSet = CharSet.Ansi)]
public extern static UInt32 cmsGetProfileInfo(
	IntPtr hProfile,
	uint Info,
	string languageCode,   
	string countryCode,     
	StringBuilder buffer,
	UInt32 bufferSize);

believe it or not, all I was getting in the buffer was "one" silly character
back, the first letter of the profile name.

When I switched to this code :

[DllImport(@lcms2Path, CharSet = CharSet.Unicode)]
public extern static UInt32 cmsGetProfileInfo(
 	IntPtr hProfile,
            	int InfoType,
            	string languageCode,  
            	string countryCode,
            	[Out] StringBuilder buffer,  
            	UInt32 bufferSize);

I got the whole profile name!

According to the above Wordpress link, an "alternative to using the CharSet
argument" is to use the MarshalAsAttribute with UnmanagedType.LPWStr as
argument :

[DllImport("TestDLL.dll", CallingConvention = CallingConvention.StdCall,
EntryPoint = "TestAPIUnicode")]
private static extern UInt32
TestAPIUnicodeUsingStringBuilder([MarshalAs(UnmanagedType.LPWStr)]StringBuil
der lpBuffer, UInt32 uiSize);

Vielen danke, Edgar!!! I'm going to have to take you to the next
OktoberFest!

/ Roger

Re: [Lcms-user] lcms2-2.8 release candidate 1 available for testing

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

 

Hello,

 

Hopefully the final release candidate. If all goes fine, I will do the 2.8
release next week.

 

http://www.littlecms.com/lcms2-2.8rc3.tar.gz

 

 

Best regards

Marti Maria

The LittleCMS project

http://www.littlecms.com 

 

From: Marti Maria [mailto:mar...@li...] 
Sent: lunes, 6 de junio de 2016 21:36
To: 'lcm...@li...' <lcm...@li...>
Subject: lcms2-2.8 release candidate 1 available for testing

 

 

Hi,

 

After some time of inactivity I've taken again the development of lcms, so
here is the first release candidate for lcms 2.8

 

Most of code is sponsored by Alien Skin Software, thank you so much for this
great contribution!

 

Aside of bugfixes, 2.8 does support alpha channel transportation and a new
transform stride function and plug-in which can be used to increase
significantly the processing speed.

 

See here the release candidate http://www.littlecms.com/lcms2-2.8rc1.tar.gz

 

Best regards

 

Marti Maria

The LittleCMS project

http://www.littlecms.com 

 

Re: [Lcms-user] cmsGetProfileInfo

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

Hi Roger,

cmsGetProfileInfo has to be called twice:
The first time you pass 0 (Buffer and BufferSize) and cmsGetProfileInfo 
is calculating how much memory you have to allocate.
Then you allocate the memory,
and call it a second time (passing a pointer to the buffer, and the 
calculated size in BufferSize).
After you're done it's your last job to free this memory.

Note: Language code and country code are char, i.e. not unicode.
imho they should be marshaled as
UnmanagedType.LPStr or UnmanagedType.AnsiBStr

Edgar


Am 10.07.2016 um 23:42 schrieb Roger Breton:
> Looks like I'm becoming a "regular contributor" to this list...
>
> I don't find it easy to figure out C# signature for all the lcms C
> functions...
>
> The original  C function looks like this :
>
> cmsUInt32Number    cmsGetProfileInfo(
> 	cmsHPROFILE hProfile,
> 	cmsInfoType Info,
> 	const char LanguageCode[3],
> 	const char CountryCode[3],
> 	wchar_t* Buffer,
> 	cmsUInt32Number BufferSize);
>
> The "best" DLLImport I could come up with, in C# is this :
>
> [DllImport(@lcms2Path, CharSet = CharSet.Unicode)]
>         	public extern static UInt32 cmsGetProfileInfo(
>             	IntPtr hProfile,
>             	int InfoType,
>             	[MarshalAs(UnmanagedType.BStr)]string languageCode,  //
> UnmanagedType.BStr = A COM-style BSTR with a prefixed length and Unicode
> characters.
>             	[MarshalAs(UnmanagedType.BStr)]string countryCode,
>             	[Out, MarshalAsAttribute(UnmanagedType.LPWStr)]
> StringBuilder buffer,
>             	UInt32 bufferSize);
>
> And, in code, I call the function like this :
>
> StringBuilder Buffer = new StringBuilder(255);
> UInt32 Buffer=0;
> UInt32 descSize;
> descSize = cmsGetProfileInfo(hSource, 0, "en", "US", Buffer, 0);
>
> When I execute the function, descSize = 0 and Buffer is empty...
>
> ----
>
> I also tried this Import statement :
>
>         	[DllImport(@lcms2Path, CharSet = CharSet.Unicode)]
>         	public extern static UInt32 cmsGetProfileInfo(
>             	IntPtr hProfile,
>             	[In] int InfoType,
>             	[In] string languageCode,  // UnmanagedType.BStr = A
> COM-style BSTR with a prefixed length and Unicode characters.
>             	[In] string countryCode,
>             	[Out] StringBuilder buffer,
>             	[Out] UInt32 bufferSize);
>
> But don't get any better?
>
> For curiosity, I also tried the following in C :
>
> 	wchar_t* Buffer;
> 	cmsUInt32Number BufferSize, DescSize;
> 	BufferSize = 0;
>
> 	Buffer = NULL;
>
> 	cmsInfoType Info;
>
> 	Info = cmsInfoDescription;
>
> 	DescSize  = cmsGetProfileInfo(rgbProfile, Info, "en", "US", Buffer,
> BufferSize);
>
> When I execute the function, DescSize = 20 but Buffer is null and BufferSize
> = 0.
>
> / Roger
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> 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...