Okay, I figured out how to get the subscription going...
---------- Forwarded message ----------
From: Wolthera <griffinval...@gmail.com>
Date: Sat, Aug 29, 2015 at 9:41 PM
Subject: Re: [Lcms-user] Trying to make a UI for colorspaces, have some
questions.
To: marti.ma...@littlecms.com
Weird... I though I had subscribed... going through the motions again, it
seems I don't get subscribed somehow :/
Anyway,
On Sat, Aug 29, 2015 at 7:42 PM, <marti.ma...@littlecms.com> wrote:
>
>
> Hello,
>
> Thanks for forwarding. The mailing list gets tons of span every day, and
> the only way I found to avoid this pain to all you is to require
> registering for posting.
>
> Regarding the question on gamut, the "good" way to represent a gamut is by
> using a 3D solid, just because our vision have 3 cones that gives us three
> dimensions. The tonge chromaticity diagram can give an idea of the
> primaries, but does not explain how the gray axis affects the color.
>
>
I know that, but right now a lot of artists already find the color
management terrifying, displaying a 3d gamut would be something I would
like postpone until the general krita-user community has gotten used to the
idea that colors have spaces. I've already had a lot of people freak out at
the notion of giving an explanation of what certain properties mean for a
profile, and this is outside the reactions we get on Krita having profiles
at all(after all, there's no need for anything besides a radio button box
with 'RGB' and 'CMYK' for proper artists according to these people). I
imagine giving people a 3d color gamut at this current stage will cause
heart-attacks. Still, it seems the same kind of problems need to be solved
anyhow.
> A way to paint the gamut would be to use the AtoB1 tag, transform a coarse
> sampling of all RGB or CMYK space and then use some sort of convex hull
> algorithm, or alpha shapes, to build the solid on Lab. This may also work
> for the tonge, it is just a matter of converting to xyY and take the xy
> coordinates. Making a color transform from the profile to XYZ identity does
> most of the work. Then there is a function to convert XYZ -> xyY.
>
>
Okay, so you are suggesting I try to take a set of colors, generated spaced
out over the different channels(so if I were to make 10 samples per
channel, RGB would give me 10³ colors and CMYK would give me 10⁴ colors...
perhaps a bit too many samples). Then transform those colors to XYZ(using
relative colorimetric mapping as indicated by your suggestion of the AtoB1
tag), then to xyY, find the outliers, draw a polygon around them, and then
use that to give feedback on the gamut?
> Regarding cmsNamedColorInfo, this is for named color profiles (like
> PANTONE) and for output colorant information. Note very few profiles does
> have this tag. The documentation (LittleCMS API) says:
>
> cmsNamedColorInfo
>
> Gets extended information on a spot color, given its index. Required
> storage is of fixed size.
>
> Parameters:
> NamedColorList: A pointer to a named color list dictionary object.
> nColor: Index to the spot color to retrieve
> Name: Pointer to a 256-char array to get the name, NULL to ignore.
> Prefix: Pointer to a 33-char array to get the prefix, NULL to ignore
> Suffix: Pointer to a 33-char array to get the suffix, NULL to ignore.
> PCS: Pointer to a 3-cmsUInt16Number to get the encoded PCS, NULL to ignore
> Colorant: Pointer to a 16-cmsUInt16Number to get the encoded Colorant,
> NULL to ignore
>
> So, the pointers are pointing to arrays and not to single 16 bit numbers.
>
>
That still doesn't help me because when I use this code, which is the only
version of the code that compiles and doesn't crash(it crashes when I try
to read the PCS as an array)...
if (cmsIsTag(d->profile, cmsSigColorantTableTag)) {
d->namedColorList = ((cmsNAMEDCOLORLIST *)cmsReadTag
(d->profile, cmsSigColorantTableTag));
for (cmsUInt16Number
i=0;i<cmsNamedColorCount(d->namedColorList);i++) {
char name;
char prefix;
char suffix;
cmsUInt16Number pcs;
cmsUInt16Number col;
cmsNamedColorInfo(d->namedColorList, i, &name, &prefix,
&suffix, &pcs, &col);
qDebug()<<d->name<<i<<","<< name<<","<< prefix<<","<<
suffix;
if (pcs){qDebug()<<pcs;} else {qDebug()<<"no pcs
retrieved";}
}
}
}
The only output I can get is this:
"Chemical proof" 0 , C ,
36984
"Chemical proof" 1 , M ,
34083
"Chemical proof" 2 , Y ,
61967
"Chemical proof" 3 , B ,
9583
So there must be something odd going on here. But you are right, I notice
that the Fogra profile that's somehow on my system doesn't give named-color
output.
> Regarding TRC, this is just a stage of the internal conversion tables
> present on the profiles. Legacy matrix-shaper profiles like sRGB or
> AdobeRGB relies more on those curves, but modern V4 profiles may chain
> CLUT, parametric curves and matrices in a complex way and then there is no
> real physical sense on those elements other that provide the math. Things
> will go works on iccMAX, where there is a programming language on calc
> elements. If you plan to only work with that very old profiles, messing
> with TRC is ok. For new profiles the possibilities are so huge that is not
> practical to worry the user with implementation details. Gamma curves in
> those cases are not a single element, but are distributed within many
> others.
>
>
>
Well, I am not very interested in the exact implementation either. As a
Krita programmer, I need three things: A way to linearise values from a
color in a given color space, a way to de-linearise linear values into
colors in a given colorspace(both for luminance calculations in filters),
and a way to give feedback to the user on what they should expect with this
profile. This would be either a curve widget but I am suspecting that a
black-to-white gradient drawn in the given colorspace and then transformed
to sRGB for display ought to give plenty of feedback as well.
Sorry if I am asking too many questions, but I am not very experienced with
programming and in these particular cases it seems there's not many people
who have come before me.
> Best regards
> Marti Maria
>
>
> Quoting Boudewijn Rempt <b...@valdyas.org>:
>
> Hey, weirdly enough Wolthera's mail didn't get through or something? So
>> maybe me forwarding might work...
>>
>> ---------- Forwarded message ----------
>> Date: Sat, 22 Aug 2015 12:02:55 +0200
>> From: Wolthera <griffinval...@gmail.com>
>> To: lcms-user@lists.sourceforge.net
>> Cc: Boudewijn Rempt <b...@valdyas.org>
>> Subject: Trying to make a UI for colorspaces, have some questions.
>>
>> Hi there,
>>
>> I am a Krita developer, and as you know, Krita uses LCMS and has a lot of
>> colorprofiles shipped with it. It confused artists a
>> little, so I set out to make a widget that gives information about a
>> color spaces so people could make a more informed choice,
>> including a cietongue widget I ported from digikam. I got most things
>> working for RGB spaces(including getting the actual
>> whitepoint from V4 type profiles with Elle Stone's help), but I have some
>> questions about the rest.
>>
>> The CIETongue widget I got from digikam is currently not capable of
>> displaying the gamut of CMYK, LAB and XYZ profiles. CMYK is the
>> most important one here.
>>
>> I found the cmsNamedColorInfo function, but the sixth(and seventh)
>> arguments confuse me a little. These are the PCS and Colorant.
>> They are just 16bit integers, and I would expect at the least a triple of
>> intergers to be necessary to give coordinates, especially
>> because cmsAppendNamedColor does request a PCS with 3 indices, but I am
>> not a CS student, so perhaps I am missing some programming
>> trick here. In either case the api reference of cmsNamedColorInfo has pcs
>> listed twice, which is probably a typo.
>>
>> My instinct after that is to just covert the PCS from LAB to XYZ to xyY
>> and draw the points on the xyY diagram and leave the idea
>> of a gamut outline alone because I don't think we'd be able to give any
>> somewhat realistic outline anyway.
>>
>> I am not quite sure what to do with XYZ and LAB in this case. Do you
>> think it's best to just take default points for XYZ and a*/b*
>> and map those, or is there actually something in the lcms functions I can
>> use to help me? I am not quite sure how different XYZ or
>> LAB profiles actually differ.
>>
>> The second part I am mulling over is giving feedback over the Tone
>> Response Curve. Right now the estimated gamma function works
>> pretty well for most TRCs, however, the sRGB, L* and rec 709 trcs all
>> give -1, indicating to me that LCMS has trouble
>> differentiating between them. I could make a curve widget that shows the
>> TRC, but I am not sure what data format the TRC is, and
>> whether it would be wise to chug around the whole TRC to begin with.
>> Perhaps there's some preexisting functionality that allows me
>> to transform a value based on the TRC? What would you think is the best
>> solution for this?
>>
>> Thanks in advance,
>>
>> --
>> Wolthera
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Lcms-user mailing list
>> Lcms-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
>
>
>
--
Wolthera
--
Wolthera
------------------------------------------------------------------------------
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
