Re: pictogram's Incamera
Re: pictogram's Incamera
- Subject: Re: pictogram's Incamera
- From: Marco Ugolini <email@hidden>
- Date: Mon, 29 Aug 2005 00:41:41 -0700
Title: Re: pictogram's Incamera
In a message dated Mon, 29 Aug 2005 00:15:15, Eugene Appert wrote:
I am confused about how Pictograms Incamera profiler works. Until encountering this plug-in I thought I had a handle on how profiles function.
It was my understanding a profile described device behaviour without actually correcting it.
When attached to an image, a profile describes the color space, or environment, in which the image was generated. This description then allows it to be viewed correctly on a profiled monitor, or printed correctly on a linearized and profiled printer. The profile attached to an image file doesn't change the number values of its pixels, only their appearance. It is like a user's guide accompanying an image file, describing the conditions under which it can be viewed accurately (assuming that the user has a profiled monitor, and that he/she is using a color-management-savvy application like Photoshop that is able to read and interpret the profile attached to the image file).
I thought by sampling patches for which values were known it was able to compile a table of control signals and their corresponding colour.
Creating a profile involves reading sample colors on a chart (printed or photographed or scanned), after which their actual values (as read by a spectrophotometer or a scanner or a camera) are compared to the expected known values of each color (usually defined in CIELAB). The profile resolves the differences between the values as read and the expected ones, so that the colors present in the image file created using that specific device (printer, scanner, camera) match as closely as possible the expected colors as defined in the device-independent CIELAB space. The profile basically says: "This color should ideally look like "B," but in this file it actually looks like "A"; so every instance of this color "A" in this file will be described as looking like "B."" If the expected color exists within that device, the match is exact; if not, it's as close as possible. There is much more to profiling, but these are the bare bones of it.
>From that table I assumed a much larger architecture was derived by using math to plot a model, eventually predicting the control signals that would produce the colours of the chart.
A profile establishes a finite number of matches for specific colors on a specific device (as many as the samples used, plus different levels of interpolation for intermediate values). It is a model, if you wish to call it that, or something similar to a translation mechanism between languages (positing each device as being like a separate language), so that the meaning is preserved throughout the whole process, and remains as close as possible to what it is intended to be. A properly-built profile has predictive value, since it facilitates the creation of accurate color, that is to say, color whose colorimetric characteristics essentially do not change throughout the production process.
Yet, after using Incamera on a digital file of a Colorchecker, it snapped into perfect form with all the right lab values in all the right places, as if the right colours had actually replaced the colours the device naturally produced. This appears to be more like colour correction than characterization.
Profiles applied to a file do not change the number values of its pixels. So, it's not "color correction," strictly speaking, because pixels are not modified. It's more like "color interpretation," whereby a given set of color numbers (e.g., RGB or CMYK) will produce different color results by applying different profiles, or contexts, for those colors. The profile defines this context for the file, and makes explicit and precise the conditions under which to view and use it accurately.
How do you make a profile without a spectrophotometer?
To make a profile for a camera you don't really need a spectrophotometer. You light the color chart in conditions that are repeatable (for example in a photo studio with artificial lights), capture it with the digital camera using a certain combination of aperture and shutter speed, then you use your profiling software to create a profile from the captured digital image. (Things are more complex than that when using RAW)
Are you asking this question because it appears to you that Incamera generated a profile without any need to read sample colors? Perhaps all that happened in your case was that the default profile was applied to your capture by the software, and, serendipitously, it happened to give you correct values for the photo capture you made. It may just be a lucky coincidence.
It doesn't necessarily mean that the same profile will give you accurate results with other images under those same lighting conditions, though.
--------------
Marco Ugolini
Mill Valley, CA
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden