Hi, I found this logic quite strange because a device is a device and it's intrinsic limits does not (or shouldn't) depend on the encoding format of the data. For me, the gamut information is in the clipping itself, even if the device is a theoretical space like sRGB. For the latter, I never expect to be "purer" than the primaries and I don't see any meaning of a color space if, whatever it can be, it can return the whole Lab range if you go outside the "limits" !
I see limitation (clipping) as a definition of the space boundary, not a limitation of the data format. It has been scaled to the maximum value of the lowest (8 bit) format not the reverse. I can be wrong but thinking the reverse is quite twisted... And I don't see color spaces like Adobe, sRGB or similar as something fundamentally different from a display profile (my Eizo ColorEdge is almost a sRGB device). Showing the sRGB (or other) boundaries is important when a document uses this space compared to the other devices (printer and/or display).I've always seen sRGB and similar spaces as having an actual boundaries ! I checked out the document about the floating point encoding. They mainly speak about problem of precision and bad limitations of the original ICC standard (like XYZ), but boundless conversion is a very specific point (they take example of camera profiles) that is not always desired (or mandatory). Anyway, it's only an opinion and semantic stuff ! Technically, can I create a simple clipping stage (profile) in between (at the third position for my example) that clips for any data format (floating point included) ? Moreover, I have to say that the V2 works great ! there is a large improvement in some profiles I have that caused some "color flips" (yellow that goes to blue) with very saturated colors. Even if I had to change a lot of things because of the removal of the ChangeBufferFormat() function, V2 is a large step ahead in quality. J. -----Message d'origine----- De : marti.ma...@littlecms.com [mailto:marti.ma...@littlecms.com] Envoyé : mercredi 2 juin 2010 12:48 À : Prevost Jerome Cc : lcms-user@lists.sourceforge.net Objet : Re: [Lcms-user] Transform difference with older versions. Hi, You are seeing the unbounded mode in action, which is a feature, not a bug. See a posting on my blog about that: http://littlecms2.blogspot.com/2009/09/unbounded-cmm.html If you use sRGB, which is a matrix and a set of curves, where is the gamut information? Right, the gamut is defined by the device encoding and only by the device encoding. But then you use double values, so the encoding is no longer limiting the gamut, and in this case you see no clamping because there is nothing that forces such clamping. If you want this effect, you need to specify the encoding you want to restrict, TYPE_RGB_16, or TYPE_RGB_8, for example. Regards Marti Quoting Prevost Jerome <j.prev...@lectra.com>: > Hello, > > For profiles without any gamut information (like display profiles) , > I use to use a < back and forth > transform PCS->Device->PCS using > the CreateMultiprofileTransform() function. When I transform the Lab > boundary, I got something similar to the gamut boundary of the > profile. As I'm migrating to V2, I got different results. > > I get sometimes identity. It depends on the profile. For printer > ones, it seems to work. For display ones, some of them return > identity, other return much larger gamut than expected and perhaps > some return the same results than before. I guess that the analysis > of the transformation is different according the stages (LUT, matrix, > CLUTs and so on..). Probably, it's not the way I should do to get > what I expect ! > > Now, this results in an identity profile if I use this code (sRGB profile) : > > double In[3],Out[3]; > > cmsSetLogErrorHandler(ErrorLog); > cmsHPROFILE sRGB=cmsCreate_sRGBProfile(); > cmsHPROFILE XYZ=cmsCreateXYZProfile(); > cmsHPROFILE Profiles[4]={XYZ,sRGB,sRGB,XYZ}; > > cmsHTRANSFORM > Trans=cmsCreateMultiprofileTransform(Profiles,4,TYPE_XYZ_DBL,TYPE_XYZ_DBL,INTENT_ABSOLUTE_COLORIMETRIC,cmsFLAGS_HIGHRESPRECALC); > > In[0]=0.75; > In[1]=0.50; > In[2]=0.45; > > cmsDoTransform(Trans,In,Out,1); > > cmsDeleteTransform(Trans); > cmsCloseProfile(sRGB); > > The Out array always have the original values whatever the In array > contains, not the ones expected because of some gamut mapping. I > guess that's it's an optimization somewhere that detects an identity > where there is not. Is it normal ? Or, is there a different way now > to do this correctly (other function or flags) ? > > Thanks in advance, > > J. > ------------------------------------------------------------------------------ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
