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. 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. 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. 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. 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 ------------------------------------------------------------------------------ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
