Thread: [Lcms-user] What's in a profile embedded in an image?
An ICC-based CMM for color management
Brought to you by:
mm2
From: Joris <jor...@sk...> - 2005-05-26 11:43:12
|
All, I'm new to this list, and I don't know if profile questions (as opposed to strict lcms questions) are regarded off topic. If they are, please ignore and forgive me. The reason for my area of interest is that I'm trying to learn color management basics, profile structure and theory, and such, and the user friendly lcms at this point is bound to only protect me from all that nitty gritty detail. I'm trying to completely correctly decode images with an embedded profile as a first step. Below is an example of a TIFF with such a profile: File "DeltaE_16bit_gamma1.0.tif" Byte order: Motorola Format: Classic TIFF IFD Tree Single page at offset 8 Single page Offset: 8 Next IFD: 0 NewSubfileType (1 LONG): - ImageWidth (1 LONG): 3072 ImageLength (1 LONG): 2048 BitsPerSample (3 SHORT): 16, 16, 16 Compression (1 SHORT): No compression PhotometricInterpretation (1 SHORT): RGB StripOffsets (2048 LONG): 17228, 35660, 54092, 72524,... SamplesPerPixel (1 SHORT): 3 RowsPerStrip (1 LONG): 1 StripByteCounts (2048 LONG): 18432, 18432, 18432, 18432,... XResolution (1 RATIONAL): 72 YResolution (1 RATIONAL): 72 PlanarConfiguration (1 SHORT): Chunky format ResolutionUnit (1 SHORT): Inch ICC Profile (628 UNDEFINED): 0, 0, 2, 116, 97, 112, 112,... The header of the embedded profile looks like this: Profile size: 0.61 Kb Preferred CMM type: appl Profile version number: 2.1.0.0 Class: Display Device profile Input space: rgbData Output space: XYZData Profile creation date: 2001.09.07 15:39:29 Primary platform: Apple Computer, Inc. Flags: - Device manufacturer: Device model: Device attributes: Reflective; Glossy; Positive media polarity; Colour media Rendering intent: Media-relative colorimetric PCS illuminant: X=0,9642; Y=1,0000; Z=0,8249 Profile creator: Profile ID: 00000000000000000000000000000000 And finally here are the profile tags: ProfileDescription (Description): ... Copyright (Text): ... RedMatrixColumn (XYZ): X=0,4360; Y=0,2224; Z=0,0139 GreenMatrixColumn (XYZ): X=0,3852; Y=0,7170; Z=0,0971 BlueMatrixColumn (XYZ): X=0,1430; Y=0,0606; Z=0,7139 RedTRC (Curve): Gamme curve, gamma=1,0000 (is identity curve) GreenTRC (Curve): Gamme curve, gamma=1,0000 (is identity curve) BlueTRC (Curve): Gamme curve, gamma=1,0000 (is identity curve) MediaWhitePoint (XYZ): X=0,9505; Y=1,0000; Z=1,0891 I am able to 'decode' the profile (the above dumps are build by my own code), but apart from that, everything is hazy at best... 1) Is this kind of profile typical for profiles embedded in images? Are there any other kinds used for this purpose? I.e., when I'll be able to apply this type of profile, is my job decoding images properly done? 2) It is clear to me that this is the TRC/Matrix type of profile, but it is not clear how exactly my code should come to that conclusion. Should my code treat profiles as belonging to this type on the basis of the presence of certain tag (XxxMatrixColumn and XxxTRC tags), or should it also double-check the profile class is 'Display Device profile', or something else/additional still? As a general rule, how are the different (application-centered) types of profile recognized? 3) Is my understanding correct that, as far as application of this profile is concerned, I can safely ignore the MediaWhitePoint tag? 4) My current profile application code converts the RGB flavor in the file to D50-based XYZ by applying the (TRC convertion which is optimized away in this case and the) matrix convertion. Problem is though, the rest of my library thinks 'along' the D65/sRGB/Lab 'axis'. As a temporary measure, my code simply ignores the fact that the resulting XYZ is D50 based, and converts it to sRGB as if it were D65-based XYZ instead. Naturally, the results are *almost* fine. In my search for the missing link, I keep stumbling upon such magic formulae like 'chromatic adaptation' and 'bradford'. But both the maths and the theory are totally beyond me, sofar, and I'm not even real sure that I'm looking in the right places... I realize it may be a lot to ask, but could anyone provide (a pointer to) a clear, step by step insight in the process? These are all probably stupid questions... Please forgive me, I am a totally new to this stuff. Many thanks for any insights anyone can provide!! Joris Van Damme in...@aw... http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html |
From: <ma...@li...> - 2005-05-26 13:13:08
|
Hi Joris, Glad to meet you again :-) Regarding your question, the embedded profile is just the ICC file, embedded "as is". There is a bit on the header that may vary, but the whole block contains just an image of the ICC file. At that point, understanding and using the contents of the profile is the goal of lcms. I assume you already know that's not trivial at all. So, quite probably, if you want to use such embedded profiles, you could use lcms to do the task. You have a sample on tifficc on how to do that. Basically, is just a matter of: TIFFGetField(in, TIFFTAG_ICCPROFILE, &EmbedLen, &EmbedBuffer); hProfile = cmsOpenProfileFromMem(EmbedBuffer, EmbedLen); Then, creating a trasform from this hProfile to whatever output space you want, and apply the transform to raster data. That's what tifficc does. If done properly, you got the ability to convert CMYK tiff too. If you want to not use lcms at all, well, then the matrix-shaper profile you are describing is just one flavor of the many implementations. RGB embedded profiles are usually using such way, but CMYK are not. The ICC spec lives here: http://www.color.org Regards, Marti Maria. |
From: Joris <jor...@sk...> - 2005-05-26 13:32:05
|
Marti, > Glad to meet you again :-) Likewise, Marti, I hope you're doing swell! > I assume you already know that's not trivial at all. I'm in the process of realizing that... > So, quite probably, if you want to use such embedded profiles, you could > use lcms to do the task. You have a sample on tifficc on how to do that. > Basically, is just a matter of: > > TIFFGetField(in, TIFFTAG_ICCPROFILE, &EmbedLen, &EmbedBuffer); > hProfile = cmsOpenProfileFromMem(EmbedBuffer, EmbedLen); > > Then, creating a trasform from this hProfile to whatever output space > you want, and apply the transform to raster data. That's what tifficc does. > If done properly, you got the ability to convert CMYK tiff too. > > If you want to not use lcms at all, well, then the matrix-shaper profile > you are describing is just one flavor of the many implementations. > RGB embedded profiles are usually using such way, but CMYK are not. > The ICC spec lives here: http://www.color.org I am indeed attempting to do all without any library at all (excluding LibTiff as well as Lcms). It strikes ignorant me as odd, that there are many possible implementations and 'degrees of correctness', since, if I understand correctly, the goal of ICC profiles is to actually communicate color in a way that is totally unambigious. This tower of Bable is not at all what I expected, and it is a first thing I've learned that I would probably not realize if I were to simply use your Lcms (that I do trust completely, and for good reason, but trust is not the issue since all I really want to learn the hard way). I have consulted the specs, of course, but it seems I'm missing the necessary background to make sense of them beyond the simple decoding of the ICC profile data format. I'm starting to realize my questions probably were beyond the scope of a single mail... Possibly, the best course of action is digging into the Lcms code, and trying to build some more insight from that... Could you nevertheless just confirm that the D50/D65 issue raised in my question 4 is indeed the gap I have to close next, and that 'chromatic adaptation' and 'bradford' are indeed the relevant concepts I should try and dig into? Joris Van Damme in...@aw... http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html |
From: <ma...@li...> - 2005-05-26 13:59:35
|
Hi Joris, Ok, here we go. > 1) Is this kind of profile typical for profiles > embedded in images? Yes. Typical on RGB, but not the only one. As said on other spaces, profiles are different. > Are there any other kinds used for this purpose? I.e., when I'll > be able to apply this type of profile, is my job decoding images > properly done? There are many others, CLUT-based on both v2 and v4 flavors. And each one in 8 or 16 bits. v4 profiles may have a very complex pipeline. > 2) It is clear to me that this is the TRC/Matrix type of profile, > but it is not clear how exactly my code should come to that conclusion. Real world is even worse, since some profiles may contain both, CLUT based AND matrix-shaper. On such profiles, CLUT tags takes precedence. In general, on gray and RGB, you have to check if an AtoBxx tag is present, if so it takes precendence. Else, the profile is matrix-shaper if it is not a named color one. Sorry for sounding such arcane, but that is how it works. > Should my code treat profiles as belonging to this type on the basis of > the presence of certain tag (XxxMatrixColumn and XxxTRC tags), or should > it also double-check the profile class is 'Display Device profile', or > something else/additional still? As a general rule, how are the different > (application-centered) types of profile recognized? As said, a profile may hold xxxMatrixColumn and be not a "true" matrix shaper. Some profiles uses matrix only on reverse direction. The profile class may help, but in this specific usage is not such important. Any embedded profile may be input, display, colorspace or output. I have even seen named color profiles embedded in specific TIFFs with additional Pantone planes. > 3) Is my understanding correct that, as far as application of this > profile is concerned, I can safely ignore the MediaWhitePoint tag? The media white point should be only used in the absolute colorimetric intent... and this introduces another variable into the equation, the rendering intent. So, the question would be what kind of color reproduction do you want on the output? If perceptual, the media white point is not of your interest. > 4) My current profile application code converts the RGB flavor in > the file to D50-based XYZ by applying the (TRC convertion which is > optimized away in this case and the) matrix convertion. Problem is > though, the rest of my library thinks 'along' the D65/sRGB/Lab > 'axis'. As a temporary measure, my code simply ignores the fact that > the resulting XYZ is D50 based, and converts it to sRGB as if it were > D65-based XYZ instead. Naturally, the results are *almost* fine. In > my search for the missing link, I keep stumbling upon such magic > formulae like 'chromatic adaptation' and 'bradford'. But both the > maths and the theory are totally beyond me, sofar, and I'm not even > real sure that I'm looking in the right places... I realize it may > be a lot to ask, but could anyone provide > (a pointer to) a clear, step by step insight in the process? Yep, many time ago I wrote this page, maybe would be useful to you: http://www.littlecms.com/bradford.htm But the profile has the chromatic adaptation already embedded on the profile. And since you have to actually apply *two* profiles, one for input and another for output, the chromatic adaptation is already done for you by the profile. But this only applies to certain profiles. Regards, Marti. |
From: Joris <jor...@sk...> - 2005-05-26 16:08:57
|
Marti, > Ok, here we go. Thank you, Marti, this should advance my attempt considerably...! Joris Van Damme in...@aw... http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html |