[#300181] Color management + calibration

View Trackers | Bugs | Export CSV

2003-09-11 15:30
Submitted by:
Henning Geinitz (hmg-guest)
Assigned to:
Nobody (None)
Color management + calibration

Detailed description
Think about color management, calibration with reference targets and
the usage of .icm files. Do we need backend support for that or can it
be done in the frontends completely? See:

Followups: Sort comments antichronologically

Date: 2005-05-24 20:34
Sender: Nobody

Logged In: NO I am an active member of both the lcms and OpenICC lists. So I thought that I would add a comment here.

1. IMO color management belongs in the front end software. Examples of commercial software for scanners were CM is implemented include SilverFast IA and VueScan Professional. In both cases the CM implementation is a front end fuction.

2. The software to create the profiles does not have to be part of either the front end or the back end. It is common in commerical scanner front ends to include this fuctionality. But there is currently GPL software availble to do this. It is a little hard to find but it exists. I think all that is needed is to have a way for users to configure the front end to call some other software to create profiles.

3. I am not sure what you mean by calibration. Perhaps you are refering to the process of creating profiles or perhaps setting the scanners internal gamma tables.

4. There is a lot of work going on in the open source community in the color managment area. The OpenICC list is where this is being worked at the system level. I would encourage someone from the SANE project to join the OpenICC list if for no other reason than to stay abrest of what is happening there. Currently the OpenICC list has representitives from a fairly broad array of open source application but one area that has no representation is in the area of scanners.

There were some questions asked in the email exchange that the above url pointed to. I don't know if these were later clairified but just in case I will take a stab at it.

"> > If I understand the method correctly, the frontends then use the .icm
> > files to adjust the gamma tables. What I don't really understand is
> could be. I do not know what gamma correction really does. But does the
> gamma correction compensate for when only a single color is affected
> (say if the scanner bulp is missing some red)? The .icm would do that.
> I thought gamma applies a transfer function whereas the .icm file is
> more or less a look-up table for color transformation.

In SANE terms, gamma tables are look-up tables. For color mode, there
could be one table (total), three tables (RGB) or four tables (RGB +
total). If the scanner provides a mean to set gamma tables in
hardware, the backends usually provide these tables and send them to
the scanner. Otherwise the correction is done in the frontend."

I would think that setting the hardware gamma tables is a type of calibration that would be done before the scanner is profiled and before scans are done in general.

ICC profiles are used to characterize the devices output not to change that output. Actualy it characterizes the whole processing chain up to the point of the output (more on this below). Once the output is characterized by creating a profile that profile will be embedded into the image file and used down the processing chain to make sure the colors and contrast are correctly converted to be used with other devices like displays and printers.

"> > how that corresponds to the other scanner settings like exposure,
> > gain and offset which have influence on the brightness/gamma of the
> > image, too. So the .icm profile is only valid for one scanner with
> > one setting of these values?
> correct, the .icm file compensates for the color in raw (no other
> correction) mode. Other methods like histogram and gamma should be
> applied afterwards."

I am not sure that it only is used in raw mode but this is one way to make sure that you are allways using the same setting (by using no settings). I do not normaly use profiles with raw output. What is true is that a profile is only good for one specific set of device settings. It may however actualy be close enough to be OK for a broader range of settings but you can not count on this. Also the profile most charaterize the device and ALL corrections that have been applied to the image by the device and the front end software. Applying any corrections to the image that were not used when capturing the profiling target make the profile invalid.

To give you an idea of how specific a profile can be I will give you an example of how I use them for my scanned film input. By the way I only know of one other person who does this same basic thing but with a digital camera so it may be a little "over the top". I still shoot film and then use a film scanner. As a normal practice for important shoots or when I have unknown ligting conditions I will shoot an image of an IT8.7 target along with a gray card at each location or perhaps even more than one if lighting conditions are changing. I will use the gray card image to set the color balance of the scans and then set the overall exposure for the series of scans by using previews of various images in the series and then lock all scanner setting other than focus (color balance, film base color, exposure...). I will then scan the IT8.7 target frame and create a shoot specific custom profile. I will then scan the series and embedd the custom profile in each image. This results in images that are characterized for the entire processing chain (lighting, film, film processing, camera, lens, scanner) and will be correctly displayed when used with CM aware software for whatever devices are used later in the processing chain.

Attached Files:


No Changes Have Been Made to This Item

Powered By FusionForge