Thread: [Lcms-user] Compositing Camera Pictures Query - Help Required
An ICC-based CMM for color management
Brought to you by:
mm2
From: Kevin G. <Ke...@tr...> - 2008-06-07 16:55:21
|
Hi. I need to composite several JPEG / TIFF digital camera pictures that use different profiles (Adobe RGB, Camera RGB Profile etc..) into a single bitmap. I would appreciate it if someone could help answer the following questions: 1. Should I just convert the images to a single profile such as sRGB? 2. The composited picture will eventually be printed to a digital press such as a Canon ImagePress C1 or an HP Indigo. Should I include the sRGB profile in my output JPEG or should I just save the image without a profile? All help would be appreciated. Best Regards, Kev. |
From: Bob F. <bfr...@si...> - 2008-06-07 17:31:23
|
On Sat, 7 Jun 2008, Kevin Gale wrote: > > I need to composite several JPEG / TIFF digital camera pictures that > use different profiles (Adobe RGB, Camera RGB Profile etc..) into a > single bitmap. I would appreciate it if someone could help answer > the following questions: > 1. Should I just convert the images to a single profile such as sRGB? Does sRGB support all the colors you are interested in? > 2. The composited picture will eventually be printed to a digital > press such as a Canon ImagePress C1 or an HP Indigo. Should I > include the sRGB profile in my output JPEG or should I just save the > image without a profile? In order to preserve as much of the original as possible in the final output, perhaps it makes sense to convert your images to a colorspace which is as close to what these devices support as possible prior to composition. This approach prioritizes the quality of the printed output and may reduce artifacts such as banding. Another alternative is to chose a larger colorspace which best represents the colors in your images so that there is minimum original color loss and then your composited image is in that colorspace (with attached profile). This second approach prioritizes the quality of the composited master image over the quality of the device-specific image. Best quality composition may have completely different requirements depending on the type of composition used. There are those (particularly those in the compositing business) who will express the opinion that composition should only be done in a linear-light space (gamma "correction" removed). Camera RAW images are usually in linear-light space since that is what the sensors detect whereas camera JPEG images are usually white-point adjusted and gamma encoded to minimize loss with 8 bit storage, and to be more similar to sRGB. Bob ====================================== Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Hal V. E. <hv...@as...> - 2008-06-07 18:41:04
|
On Saturday 07 June 2008 10:31:11 am Bob Friesenhahn wrote: > On Sat, 7 Jun 2008, Kevin Gale wrote: > > I need to composite several JPEG / TIFF digital camera pictures that > > use different profiles (Adobe RGB, Camera RGB Profile etc..) into a > > single bitmap. I would appreciate it if someone could help answer > > the following questions: > > 1. Should I just convert the images to a single profile such as sRGB? > > Does sRGB support all the colors you are interested in? I would avoid sRGB since is has a very limited gamut that is actually smaller then the gamuts of many modern printers. Your Camera RGB gamut could be almost twice as big as sRGB. There is a CM professional who has written books on the subject who sometime posts to this and other color related lists that likes to say "Friends don't let friends use sRGB". I agree with him sRGB is not a good color space to do anything other then final rendoring for the web. > > > 2. The composited picture will eventually be printed to a digital > > press such as a Canon ImagePress C1 or an HP Indigo. Should I > > include the sRGB profile in my output JPEG or should I just save the > > image without a profile? As to saving the image with the profile you will need to talk to whoever will be doing the printing. They should be able to tell you how to prepare the images for them. They may ask that these be converted to a specific color space or that you leave the profile embedded in the image. For example, a big box store here in the US, Costco, has the profiles for each stores printer available on line so that you can convert the images before bringing them in for printing. If your printing service does not know how to answer this question then you need to find another printing service. > > In order to preserve as much of the original as possible in the final > output, perhaps it makes sense to convert your images to a colorspace > which is as close to what these devices support as possible prior to > composition. This approach prioritizes the quality of the printed > output and may reduce artifacts such as banding. Another alternative > is to chose a larger colorspace which best represents the colors in > your images so that there is minimum original color loss and then your > composited image is in that colorspace (with attached profile). This > second approach prioritizes the quality of the composited master image > over the quality of the device-specific image. > > Best quality composition may have completely different requirements > depending on the type of composition used. There are those > (particularly those in the compositing business) who will express the > opinion that composition should only be done in a linear-light space > (gamma "correction" removed). Camera RAW images are usually in > linear-light space since that is what the sensors detect whereas > camera JPEG images are usually white-point adjusted and gamma encoded > to minimize loss with 8 bit storage, and to be more similar to sRGB. > > Bob > ====================================== > Bob Friesenhahn > bfr...@si..., http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Kevin G. <Ke...@tr...> - 2008-06-07 19:05:42
|
Hi Bob / Hal. Thanks for your replies - they are appreciated. The output devices I listed were just examples of what could be used but in reality our customers could be using any digital press. As Bob suggested I think our best approach might be to select the colour space that best represents the original images and convert them to that. The tricky thing is that we will also not have any control over the source images so in theory they could have any profile attached. I've been doing some tests with pictures from different cameras that I have access to and using the wide gamut rgb profile (obviously) seems to result in the least number of lost colours. Do you think that converting to this sort of profile and embedding it within the output file will be the best solution? Regards, Kevin. ________________________________________ From: Bob Friesenhahn [bfr...@si...] Sent: 07 June 2008 18:31 To: Kevin Gale Cc: lcm...@li... Subject: Re: [Lcms-user] Compositing Camera Pictures Query - Help Required On Sat, 7 Jun 2008, Kevin Gale wrote: > > I need to composite several JPEG / TIFF digital camera pictures that > use different profiles (Adobe RGB, Camera RGB Profile etc..) into a > single bitmap. I would appreciate it if someone could help answer > the following questions: > 1. Should I just convert the images to a single profile such as sRGB? Does sRGB support all the colors you are interested in? > 2. The composited picture will eventually be printed to a digital > press such as a Canon ImagePress C1 or an HP Indigo. Should I > include the sRGB profile in my output JPEG or should I just save the > image without a profile? In order to preserve as much of the original as possible in the final output, perhaps it makes sense to convert your images to a colorspace which is as close to what these devices support as possible prior to composition. This approach prioritizes the quality of the printed output and may reduce artifacts such as banding. Another alternative is to chose a larger colorspace which best represents the colors in your images so that there is minimum original color loss and then your composited image is in that colorspace (with attached profile). This second approach prioritizes the quality of the composited master image over the quality of the device-specific image. Best quality composition may have completely different requirements depending on the type of composition used. There are those (particularly those in the compositing business) who will express the opinion that composition should only be done in a linear-light space (gamma "correction" removed). Camera RAW images are usually in linear-light space since that is what the sensors detect whereas camera JPEG images are usually white-point adjusted and gamma encoded to minimize loss with 8 bit storage, and to be more similar to sRGB. Bob ====================================== Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Alastair M. R. <bla...@fa...> - 2008-06-07 19:17:03
|
Hi :) Kevin Gale wrote: > Do you think that converting to this sort of profile and embedding it within the output file will be the > best solution? This is a viable solution with two provisos: (a) you must be certain that the recipients' workflow will actually recognize and make use of the embedded profile. (b) you will need to save 16-bit data, which effectively means you'll have to save TIFF, not JPEG. 8-bit data isn't enough when using wide-gamut colourspaces - the steps between adjacent codes can be large enough to lead to visible contouring. All the best, -- Alastair M. Robinson |
From: Kevin G. <Ke...@tr...> - 2008-06-07 19:37:05
|
Hi Alastair. Thanks for your email. Just when I thought I had a solution you threw a spanner in the works (-: I don't think I will have to option to work with 16 bit data as the image processing framework I am using only supports 8 bit data. Would using sRGB be a better solution although I would get more colour loss? Regards, Kevin. ________________________________________ From: Alastair M. Robinson [bla...@fa...] Sent: 07 June 2008 20:16 To: Kevin Gale Cc: lcm...@li... Subject: Re: [Lcms-user] Compositing Camera Pictures Query - Help Required Hi :) Kevin Gale wrote: > Do you think that converting to this sort of profile and embedding it within the output file will be the > best solution? This is a viable solution with two provisos: (a) you must be certain that the recipients' workflow will actually recognize and make use of the embedded profile. (b) you will need to save 16-bit data, which effectively means you'll have to save TIFF, not JPEG. 8-bit data isn't enough when using wide-gamut colourspaces - the steps between adjacent codes can be large enough to lead to visible contouring. All the best, -- Alastair M. Robinson |
From: Bob F. <bfr...@si...> - 2008-06-07 21:23:49
|
On Sat, 7 Jun 2008, Kevin Gale wrote: > I don't think I will have to option to work with 16 bit data as the > image processing framework I am using only supports 8 bit data. > Would using sRGB be a better solution although I would get more > colour loss? That is unfortunate. Any CMS transformation involves some loss. Under these conditions it may make sense to use sRGB. Lots of software works well with sRGB. Bob ====================================== Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Alastair M. R. <bla...@fa...> - 2008-06-07 22:17:38
|
Hi :) Kevin Gale wrote: > Just when I thought I had a solution you threw a spanner in the works (-: LOL - my apologies! > I don't think I will have to option to work with 16 bit data as the image > processing framework I am using only supports 8 bit data. Would using > sRGB be a better solution although I would get more colour loss? Do you have to deal with alpha channels and overlaying items in your compositing? If no transparency is needed and you're just placing images side-by-side then you might be best off compositing directly in the colour space of the target device, if a profile is available. For cases where the profile isn't available, sRGB or even Adobe RGB would be reasonable choices. It's a tradeoff between gamut and the step size of 8-bit data - they increase in tandem. The contouring effects I spoke about can be hidden to a certain extent, too - a lot depends on your source data. The "cleaner" the image, the more likely you are to have problems - a noisy image may not show it at all. All the best, -- Alastair M. Robinson |
From: <jc...@gm...> - 2008-06-08 08:11:26
|
2008/6/7 Kevin Gale <Ke...@tr...>: > Just when I thought I had a solution you threw a spanner in the works (-: > > I don't think I will have to option to work with 16 bit data as the image processing framework I am using only supports 8 bit data. Would using sRGB be a better solution although I would get more colour loss? I do things like this by compositing in profile connection space. I import all my source images to float LAB, composite, then render a final image out again in the target colour space. Adobe98 would be good enough for print output, in my opinion. I'm a maintainer on a demand-driven image processing library that can do this efficiently, even for very large images. There's a Python binding so it's quite easy to use. Though I realise being told about an alternative image processing framework is not always very helpful :( http://www.vips.ecs.soton.ac.uk John |
From: Bob F. <bfr...@si...> - 2008-06-07 20:17:52
|
On Sat, 7 Jun 2008, Kevin Gale wrote: > > The output devices I listed were just examples of what could be used > but in reality our customers could be using any digital press. As > Bob suggested I think our best approach might be to select the > colour space that best represents the original images and convert > them to that. Make sure that you check out Bruce Lindbloom's site at http://www.brucelindbloom.com/. There is valuable information regarding RGB working spaces there, as well as information on a colorspace (with CMS profiles) called "Beta RGB" which optimally captures useful (film) colors and uses the typical 2.2 gamma. Lots of people seem to use Adobe RGB although it is clearly not the best. Bob ====================================== Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Kevin G. <Ke...@tr...> - 2008-06-07 21:24:34
|
Hi Bob. Thanks for your reply. I'll definitely check the site out. One last question. What I would like to avoid is converting the image if the source profile is the same as the destination profile. Do you know of a way to actually compare profiles to see if they are the same? Regards, Kevin. ________________________________________ From: Bob Friesenhahn [bfr...@si...] Sent: 07 June 2008 21:17 To: Kevin Gale Cc: hv...@as...; lcm...@li... Subject: RE: [Lcms-user] Compositing Camera Pictures Query - Help Required On Sat, 7 Jun 2008, Kevin Gale wrote: > > The output devices I listed were just examples of what could be used > but in reality our customers could be using any digital press. As > Bob suggested I think our best approach might be to select the > colour space that best represents the original images and convert > them to that. Make sure that you check out Bruce Lindbloom's site at http://www.brucelindbloom.com/. There is valuable information regarding RGB working spaces there, as well as information on a colorspace (with CMS profiles) called "Beta RGB" which optimally captures useful (film) colors and uses the typical 2.2 gamma. Lots of people seem to use Adobe RGB although it is clearly not the best. Bob ====================================== Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Kai-Uwe B. <ku...@gm...> - 2008-06-08 10:36:44
|
Am 07.06.08, 22:21 +0100 schrieb Kevin Gale: > I'll definitely check the site out. One last question. What I would like to avoid is converting the image if the source profile is the same as the destination profile. Do you know of a way to actually compare profiles to see if they are the same? Looking at the description tag is a typical option but can be faked. Checking the resulting transform for identity in each table- and curves entry might be an other option. The drawback is the computational cost to create the transformation in the first place. I would expect the device link curves to be linear[0,1] and each table output entry matching the table input value. More pragmatically one might run the colour conversion over a simple fine grained test image and look for differences above a reasonable threshold. The test image should cover a reasonable range of patches to match the DL table. An other option, in case only two profiles are involved, is to check for identical md5 check sums as described in the ICC profile specification. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org PS: something like this would be nice in Oyranos |
From: Kevin G. <Ke...@tr...> - 2008-06-08 10:50:52
|
Hi Kai. Thanks for your reply. Performing some sort of check on the data was what I had in mind. My original plan was to compare the names but performing a check across the entire profile data would probably be better. Thanks. Kev. ________________________________________ From: Kai-Uwe Behrmann [ku...@gm...] Sent: 08 June 2008 11:45 To: Kevin Gale Cc: lcm...@li... Subject: Re: [Lcms-user] Compositing Camera Pictures Query - Help Required Am 07.06.08, 22:21 +0100 schrieb Kevin Gale: > I'll definitely check the site out. One last question. What I would like to avoid is converting the image if the source profile is the same as the destination profile. Do you know of a way to actually compare profiles to see if they are the same? Looking at the description tag is a typical option but can be faked. Checking the resulting transform for identity in each table- and curves entry might be an other option. The drawback is the computational cost to create the transformation in the first place. I would expect the device link curves to be linear[0,1] and each table output entry matching the table input value. More pragmatically one might run the colour conversion over a simple fine grained test image and look for differences above a reasonable threshold. The test image should cover a reasonable range of patches to match the DL table. An other option, in case only two profiles are involved, is to check for identical md5 check sums as described in the ICC profile specification. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org PS: something like this would be nice in Oyranos |
From: Alastair M. R. <bla...@fa...> - 2008-06-08 11:19:38
|
Hi :) Kevin Gale wrote: > Performing some sort of check on the data was what I had in mind. My original plan was to compare the names but performing a check across the entire profile data would probably be better. When I asked something similar several years ago, the advice I received was that binary comparison or MD5 hash of the profile data is as good as any method, but it should skip the ICC header, because an embedded and on-disk version of the same profile can have differing flags, but be otherwise identical. Reference here: http://www.mail-archive.com/lcm...@li.../msg00889.html What I do in Photoprint's lcms wrapper is take an MD5 hash of all profiles, be they embedded, disk-based or generated on the fly, like this: md5=new MD5Digest(buffer+sizeof(icHeader),buflen-sizeof(icHeader)); The MD5s are useful for more than just comparing for equality - to avoid generating transforms unneccessarily, I use a transform cache, and tag each transform with the MD5 of the source and destination profile, along with the intent. All the best, -- Alastair M. Robinson |
From: Mike R. <gr...@cu...> - 2008-06-12 04:50:17
|
I would recommend converting everything to 8 bit sRGB and sending that to the printer as either tiff or high quality jpeg, whichever is convenient, with the sRGB profile embedded. There are fewer mistakes to be made when using an sRGB file, and the gamut size is more than adequate for printing photographs. Mike Russell - www.curvemeister.com |
From: Kevin G. <Ke...@tr...> - 2008-06-12 06:34:01
|
Mike. Thanks for your reply. I think from the replies i've had on this subject this is exactly the solution we will implement. Your suggestion has just re-enforced it even more. thanks. Regards, Kevin. ________________________________________ From: lcm...@li... [lcm...@li...] On Behalf Of Mike Russell [gr...@cu...] Sent: 12 June 2008 05:50 To: Lcms Liste Subject: Re: [Lcms-user] Compositing Camera Pictures Query - Help Required I would recommend converting everything to 8 bit sRGB and sending that to the printer as either tiff or high quality jpeg, whichever is convenient, with the sRGB profile embedded. There are fewer mistakes to be made when using an sRGB file, and the gamut size is more than adequate for printing photographs. Mike Russell - www.curvemeister.com ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Lcms-user mailing list Lcm...@li... https://lists.sourceforge.net/lists/listinfo/lcms-user |
From: Kai-Uwe B. <ku...@gm...> - 2008-06-12 20:47:42
|
Am 11.06.08, 21:50 -0700 schrieb Mike Russell: > I would recommend converting everything to 8 bit sRGB and sending that to > the printer as either tiff or high quality jpeg, whichever is convenient, > with the sRGB profile embedded. > > There are fewer mistakes to be made when using an sRGB file, and the gamut > size is more than adequate for printing photographs. > > Mike Russell - www.curvemeister.com Just for the record, Generally 8-bit sRGB can easily render a disadvantage for printing. The intersection of typical Cmyk prints, read desktop as well as mass printing, and sRGB is rather small. The two original mentioned devices are claimed higher quality. With the contraints of the original questioner, sRGB might fit his trade off. Normally rendering is done in a larger colour space (ECI RGB) in higher bit depth. And at the very end of colour manipulations, the final result can be converted to, what fits to end devices and bandwith. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |