BragIt
Image Fidelity

IT8.7 Profiling Tests — Continued

This is a continuation of the "IT8.7 Profiling Tests" article — click here to go to the start of the article, which describes details of the setup and how the profiles were made.
You may also need to read about profiles and relative/absolute rendering intents of white points.

[Stockholm December 2004]

Comparisons of results for a problematic image

The problematic image

The problematic image I will show as an example, is a somewhat under-exposed Fuji Sensia 100 slide, scanned at 4000 ppi with SilverFast Ai version 6.2.3r6, so the total size is about 5700x3700 pixels. At 48 bits per pixel, the tiff image is about 130 MB — too much to show here, and we do not need to scrutinize the whole image. We will concentrate on a shadow part of the image, whose size is about 1400x1000 pixels (6.6% of the total area). There is no sharpening whatsoever involved in the chain.

This image is chosen because it needs to be lightened up quite a bit, which will amplify any imperfections in the color management work flow. Also, this image has subtle shades of colors you know well, such as white or various shades of grey, plus a reddish tiled roof.

Settings

The setting in SilverFast called '48 Bit Color' is used when you want SilverFast to handle color management, and, if you like, other manipulations. The setting in SilverFast called '48 Bit HDR Color' is the setting used when you want as "raw" unmanipulated results as possible, usually at gamma 1.0 and usually with no embedded color profile.

Comparison methods

All these images have had Curves applied to them, so that input value 26 is mapped to output value 51. As it turns out, it is this application of curves to lighten up the shadows that is the very important issue; raising curves can really make bad profiles perform like a pig! So, the more you need to tweak your images, the better profile you need! Also, as will be shown below, the order in which you convert to a color space and do the curve tweaking is important!

First of all: turn bright lights off in your room! You may absolutely not have any lights that illuminate your screen directly, since this image is a bit dark. You will need to look at it for a while to get adapted.

Web adaptation

Just prior to saving these images in a web friendly format, all of them have been converted to the sRGB profile, using relative colorimetric rendering intent, and the profile is embedded in the images. The conversion engine is Adobe (ACE), but tests confirm that the difference between this engine and e.g Apple CMM is very small. Then they are converted to 8 bits/channel and jpg-compressed with quality setting 'High' (8) in Photoshop. Downsampling to small thumbnail versions is done in 16 bit mode.

The fact that they are in 8 bits/channel sRGB and jpg-compressed might have you suspicious, but I can assure you that the difference in visual appearance these conversions cause, as seen on a really good monitor, is actually very small. However, your browser may or may not understand the sRGB profile that is embedded in the images, so to be on the really safe side, you need to download the images to disk and view them in your icc-aware image application. Tests on a Mac OS X system shows, however, that the appearance of these images in Safari (1.2.4) is precisely the same as the appearance in Adobe Photoshop!


An overview of the problematic image
problematic photo
Click to see a larger version in a separate browser window (184 kB).
The problematic example image: a somewhat under-exposed Fuji Sensia 100 slide, scanned at 4000 ppi. In the following examples, I will concentrate on the shadow part of this image, shown in the red rectangle, whose size is about 1400x1000 pixels (6.6% of the total area).

Although the slide is somewhat under-exposed, there are spots of this image that are really bright, so it would absolutely not be a conceivable solution to just crank up the lamp intensity to compensate for the under-exposure, since that would completely wipe out the highlights.

This particular version of the image is just to show you what kind of test image I used, so the profiling details are not important, but for the record: It is scanned and profiled exactly as the first inCamera version shown below, i.e gamma 1.0 plus the inCamera profile plus Curves applied 26 -> 51.

The real slide, when viewed on my light table, looks pretty OK. My light table has two sets of light tubes; even with just one of the sets turned on, it is not difficult at all to see some details inside the red rectangle. With both sets turned on, one can even see windows and some structure on the house in the center of the red rectangle, which in this image looks almost black! So subjectively, the applied curves makes the appearance of the image closer to the appearance of the real slide. (Curious to know where the picture is taken? It is shot from the Galata Tower in Istanbul 2003.)


SilverFast Ai 6 managed
problematic photo
Click to see a larger version in a separate browser window (148 kB).
This image is scanned in SilverFast Ai at gamma 2.0 with the setting '48 Bit Color', and it is color managed by SilverFast using a profile created by SilverFast, which converts the image to the standard working space Adobe RGB (1998). As all the other images here, Photoshop Curves was applied 26 -> 51.

As you can see in the large image, it is dark and noisy, but there are details there, or at least should be details! And for many of the details you know that they are white or various shades of grey, plus the reddish tiled roof.

But not only is it extremely noisy — some reddish ugly noise, these colors really don't look quite right: There is some terrible greenish cast over many of the white or bright grey structures in the deep shadows, and the color of the red tiles looks artificial.
SilverFast Ai 6 managed, Curves twice
problematic photo
Click to see a larger version in a separate browser window (236 kB).
This is the same image as above, but with Photoshop Curves 26 -> 51 applied ones again to more easily see the contents and effects. It is obviously disgusting, but clearly emphasizes the problems. It's just outright appalling!

inCamera 3.1
problematic photo
Click to see a larger version in a separate browser window (128 kB).
This image is scanned in SilverFast at gamma 1.0 with the setting '48 Bit HDR Color', assigned a profile produced by inCamera 3.1, and as all the other images here, Photoshop Curves was applied 26 -> 51.

I claim this is pretty close to the appearance of the real slide on the light table — at least concerning colors and contrast. However, the real slide has more details in the deep shadows if viewed with sufficiently much light.

The noise is caused by the CCD element in the scanner, despite this scanner is supposed to be one of the best you can get in this respect (apart from drum scanners of course)! Nevertheless, you can also see film grain in the shadows.

inCamera 3.1, Curves twice
problematic photo
Click to see a larger version in a separate browser window (136 kB).
This is the same image as above, but with Photoshop Curves 26 -> 51 applied ones again to more easily see the contents.

Note the extreme difference between this one and the corresponding SilverFast managed version!

As it turns out, it is actually very important which order you do color space conversion and apply Curves: In this image, both of the Curves applications were done before sRGB conversion, i.e while still in the input color space defined by the inCamera profile. Let's see what happens if the second Curve application is done after sRGB conversion:

inCamera 3.1, Curves > sRGB > Curves
problematic photo
Click to see a larger version in a separate browser window (240 kB).
Note the big difference between this image and the previous one! It's hard to say which is best or most accurate, but they are clearly different, and it's a striking difference!

The reason for the difference is partly that the gamma is different when Curves is applied the second time, partly because we have left the input space.

(The inCamera profile is assigned to an image that has a gamma of 1.0, and since profile assignments do not change any RGB values, the first application of Curves operated in a gamma 1.0 enviromnent, whereas after the sRGB conversion, we operate in a gamma 2.2 environment! But as mentioned, it only explains part of the difference.)

I have made exactly the same experiments as this one, but using Adobe RGB (1998) or Wide Gamut RGB as the working space before the final application of Curves, and the visual result is exactly the same as using sRGB! With or without Black Point Compensation. That shows that it is not a matter of gamut size. I have also made tests with inCamera profiles made for gamma 2.2 scans, with almost the same principal result. That shows it is not only a gamma issue — the input space has special behaviors, and right now I can unfortunately not explain the mechanism.

Overall, I think this image version is pretty close to the real slide if the slide is looked at using a strong light and a good loupe, except for the fact that there is some added scanner noise here. In the lower left area of the image, there is a tree, which is supposed to have green leaves. However, not even the real slide is able to reveal that — it is mainly just murky there, although I can understand that it is a tree, and there are some vague hints of foliage. So the scanner noise seems to add just slightly to the murkiness of the grainy film base.

Comparing this image with the SilverFast version where we applied Curves twice, it becomes just very apparent that SilverFast is a disaster in this respect!

We need to do one more experiment: What happens if we convert to a working space before any application of Curves? See next image:

inCamera 3.1, Adobe RGB > Curves
problematic photo
Click to see a a larger version in a separate browser window (156 kB).
Compare this image with the first inCamera version shown above. The difference is that this one has been converted to Adobe RGB (1998) right after the inCamera profile was assigned to the image, so that the application of Curves therefore is done in the Adobe RGB (1998) color space (which has a gamma of 2.2).

Note the striking difference between the two images! The latter one (i.e this image) is not at all good — there is some nasty violet cast all-over, and the the grains in the transition zone has become blotchy, and the darkest shadows are blocked! The sheer magnitude of the difference is astonishing!

As explained in the previous example, the reason for the difference is partly that the gamma is different in this example, partly because we have left the input space.

(The inCamera profile is assigned to an image that has a gamma of 1.0, and since profile assignments do not change any RGB values, the first inCamera version applied Curves while still operating in a gamma 1.0 enviromnent. In this image, however, we have converted to the Adobe RGB (1998) color space, which has a gamma of 2.2, so now the Curve is applied on a gamma 2.2 image! However, as mentioned above, it only explains part of the difference.)

In theory, one might think that one could simply modify the Curves, so that the result of applying it on a gamma 2.2 image was the same as the "standard" Curves application on a gamma 1.0 image. However, this is not possible! As an experiment, I tried to create a composite RGB curve that mimicked the first inCamera version as much as possible. After a fair amout of tricky tweaking, I could get close to the overall contrast, but colors were still quite off — for instance, the red tiled roof lost most of its color. Also, the blotchiness could not be completely avoided.

Also, I have made tests with inCamera profiles made for gamma 2.2 scans, with almost the same principal result. That shows it is not only a gamma issue — the input space has special behaviors, and right now I can unfortunately not explain the mechanism. If you want to experiment yourself, download this raw gamma 1.0 PNG image (4.9 MB), which has no profile and is totally unmodified. Then assign this gamma 1.0 inCamera profile (448 kB zip archive).

You can also compare the shown image with the first SilverFast version, since both applied Curves in the Adobe RGB (1998) color space. It is just very apparent how much the SilverFast profile lost and destroyed!

A conclusion to draw from this experiment is that: if one needs to apply significant (massive) amounts of Curves, to avoid getting nasty artifacts, it should be done before any conversions to (high-gamma) working spaces! This contradicts most work flow schemes, but it seems inevitable!


Scarse 0.3
problematic photo
Click to see a a larger version in a separate browser window (148 kB).
This image should be compared with the first inCamera version shown above. It is treated the same, but using the Scarse profile instead.

Overall, the two images are very similar — if not to say, extremely similar! However, there is a small advantage to inCamera. The comparison comes with a certain reservation, however, since the Scarse profile was generated a year ago from a different file than is used for inCamera. This is discussed in more detail in Comparisons using the IT8.7 target, where the conclusion is that a comparison is a valid one.

It is important to realize, that even though the differences may seem small, any differences will be amplified by any further manipulation of the image. To illustrate that, I applied Curves again (after the sRGB conversion) just as I did with the inCamera version, see next image:
Scarse 0.3, Curves > sRGB > Curves
problematic photo
Click to see a a larger version in a separate browser window (308 kB).
This image should be compared with the corresponding inCamera version: inCamera 3.1, Curves > sRGB > Curves. It is treated the same, but using the Scarse profile instead.

Although still very similar, the difference has increased, and it is not difficult to see that the inCamera version is slightly better.

In the original 2003 ariticle, I made a claim that the Scarse profile caused a blotchiness in the deep shadows. I revoke that claim now. It was caused by a combination of grain and scanner noise. I also made a claim about blotchiness when Curves are applied; but, as demonstrated above for the inCamera profile, it was caused by converting the image to a working space before applying Curves.


CONCLUSION
Pictographics InCamera delivers the best result, as seen and measured on a troublesome image with deep shadows — especially when those shadows need to be lightened up a bit.

The Scarse profile did very well, but not quite as good as inCamera. It is worth a closer inspection, and it does certainly have potential.

The SilverFast profile is not recommended at all. As long as it is based on the preview of the scan, it does not have any potential. The HDR version of SilverFast, however, may have potential, since it works very differently.

The application of Curves to lighten up shadows can grossly amplify any imperfections in a profile — this can really make bad profiles destroy an image. The more you need to tweak your images, the better profile you need!

Perhaps somewhat surprising is the fact that the order in which you convert to a color space and apply Curves is very important! For strong lifting of shadows, it may be better to apply Curves (or similar tools) before any conversions to working spaces, such as Adobe RGB (1998), i.e while still in the input color space. For color balancing, however, it may be better to do that after you have converted to a working space, as was exemplified in a portrait.

Back to the beginning of the article.

Harald E Brandt
Hägersten, Stockholm
Sweden
Photo: http://photo.bragit.com
BragIt: http://bragit.com
Email:
Last updated: 2011-10-27 at 15:07:10 +0200