While FilmType SubType, and FilmGamma were originally conceived as calibration tools — meant to be applied per roll, or even per film type under a given set of development conditions — with FlexColor’s 3F scans they end up serving in practice as per-image salvage tools. I know this all too well from having done commissioned work on an artist’s 3F scans where the originals were no longer accessible. I can’t go into specifics because of an NDA, but the general picture is clear enough. Some images could, with a great deal of care, be coaxed into behaving acceptably. Others were a complete loss in terms of color fidelity.
During that work I often wished I could simply have scanned the 120 film on my LS-9000 and been done with it. But of course I had to work with what was possible at the time. For that reason, I cannot recommend the Imacon or Hasselblad scanners to anyone scanning negatives. There are multiple reasons behind this, which we can certainly go into, but the immediate purpose here was to dig out some of my earlier research on their color behavior and put it into the forum’s new On Scanners section.
Our scanning tips predate the work below. A warning was added, but in fact this never got wrapped up. A key takeaway is that Flextight scans are never linear — ColorNeg’s default of L on the G/L button does not apply. The GammaC In/Out option will help; read that warning. There is a trick on the old macOS software only that is supposed to turn off the scanner’s gamma. I can document that below; I don’t think I ever did elsewhere.
----------
Looking through all material we have gathered in the test scans we ran over time, we have learned a few things but must conclude that even with the NoScannerGamma trick the scans are not linear. There are just too many factors involved to say anything definitive beyond that the output FlexColor produces is messed up somehow.
Even in the comparisons I'll show below, there is a basic problem:
Contrary to what Hasselblad said, it is quite valid to compare supposed linear scans of the same color negative or slide from two different scanners. This is because, unlike when forming the image of a real-world scene, only a small number of specific dyes (filters) in the color negative/slide are involved — as opposed to the multitude of materials in a real-world scene. Differences in the filters, lighting, lenses, etc. of two scanners will result only in different channel multipliers, because the image really is just composed of a few filters of varying density. However, when comparing two images that are not composed of the same dyes (like the color negative and the IT-8 slide I use below) things get more complicated.
So all of the below could be evidence of the problem being caused by a non-uniform image adjustment, but it is not solid proof of the problem’s nature. It would be nice to be able to figure out the exact nature of the problem, but we are not well-equipped to do so without the manufacturer's cooperation. We can only show that FlexColor does not produce anything close to linear and that the scans produced also cannot be repaired by any means we tried.
We'll start from this FlexColor scan:
-
- flex_2in1.jpg (63.13 KiB) Viewed 226 times
- [Full image link - opens in new tab]
For each of the above scan's elements we created a known linear reference scan to compare the FlexColor result to. I took two more or less identical crops — one from the linear scan and one from the FlexColor scan (which had the NoScannerGamma trick applied). I expanded the color channels of either by using a single multiplier per channel. Then I took screenshots of the resulting histograms. I converted the linear scan's histogram to grayscale, copied the FlexColor one on top, and set it to 50% opacity. So there are two histograms overlaid in each graph below: one from a known linear scan (gray in the background) and the FlexColor one in RGB.
For the color negative portion of the scan:
-
- flex_hist_cn.jpg (28.35 KiB) Viewed 226 times
- [Full image link - opens in new tab]
Of course, if the NoScannerGamma trick really produces a linear scan, that cannot require a gamma adjustment to make it match a reference linear scan. The only reason we tried this was the assumption that the NoScannerGamma trick might in fact not lead to linear scans after all. The black and white test below shows this might be the case...
Looking at the IT-8 (from the same scan) histograms in comparison:
-
- flex_hist_it8.jpg (35.73 KiB) Viewed 226 times
- [Full image link - opens in new tab]
What we may be showing here (but not, we think, really proving) is significant channel crosstalk.
This could be from a color lookup table sort of adjustment, but it just as easily could be from a hardware circuit that reacts to and adjusts the difference between channels, from software that does something like combining the three channels, increasing or decreasing the saturation, and returning to RGB.
If we emphasized either theory, then Hasselblad would regard not finding whatever we suspect as proof that we're wrong. So the only safe assumption at this point is there definitely is something going on before the data is stored in the 3F file, but that we do not know for sure what it is. In any event, if that treatment of the data — be it by hard- or software — can't be disabled, FlexColor's output will remain useless for color negatives.
Without Hasselblad's cooperation I think we have reached a dead end here. As much as I had hoped to figure out what's actually happening, it didn't work out with the tests we ran thus far. Sorry.
Since I did not comment on it yet, on to the B&W negative scan...
Looking at a black and white sample scan in the same way as above, we find that all color channels are off differently again — but equally so across channels this time.
-
- flex_hist_bw.jpg (31.64 KiB) Viewed 226 times
- [Full image link - opens in new tab]
the difference becomes so small that the B&W negative can be inverted in a way that's similar to inverting a true linear scan.
There is no color to screw up here, so this is far less delicate...
-
- flex_hist_bw_gamma24.jpg (26.65 KiB) Viewed 226 times
- [Full image link - opens in new tab]