on.raw.photography

So I made the accidental discovery that MakeTiff can read and convert Pakon RAW files to linear tiff.

Christoph asked me to make a thread about it here so he could elaborate on it, as it is an undocumented feature.
Anyway this was a great surprise! It seems to work without a hitch and can even calculate the correct size if the image has been cropped (last picture on the roll scenario).
I would love to know more about the this, especially the different expand options available and how to use them.

For those who don't know what a Pakon is in the first place, it's a small lab scanner made by Kodak that will scan a whole roll of 35mm film in about 5 minutes with ICE. They are old and production stopped in 2006 or so I believe.

Using MakeTiff With Pakon RAW Files in Linear Scan Mode

As you have discovered, MakeTiff has a dedicated mode for processing linear scans which can also handle Pakon RAW files. This currently is an undocumented feature, but it is fully implemented on both Windows and macOS.

What MakeTiff Does With Pakon RAW

When MakeTiff is run in its mode for processing linear scans and is given a file with the extension .RAW from a Pakon scanner, it does not treat it as a generic binary blob. Instead it evaluates the file size and reconstructs width and height from that:

• For known Pakon sizes the dimensions are recognized directly (3000×2000, 2250×1500, 1500×1000, with or without the small 16-byte header).
• For the top Pakon resolution, MakeTiff can also handle “free width” RAW data: cropped last frames, multi-frame strips exported from TLX Client, or panoramic 35mm formats. In that case, the height is assumed from the scanner, the optional 16-byte header is taken into account, and the width is computed from the remaining byte count as RGB 16-bit data.

Once width and height have been determined, the Pakon RAW stream is passed through MakeTiff’s pipeline and written out as a linear, uncompanded 16-bit per channel RGB TIFF. It is meant as a technical intermediate for further processing with ColorPerfect rather than as a final image.

Expansion Modes and Why RGB +1 EV Matters

MakeTiff offers several “expansion” modes for the linear data. For Pakon RAW, the only one that is really relevant is the RGB expansion by one exposure value (+1 EV). The reason is not the Pakon itself but the way Photoshop represents 16-bit data internally.

A TIFF file can store 2¹⁶ possible values per channel, i.e. 0 … 65535. Photoshop, however, historically uses a 15-bit internal range plus one extra value, effectively reducing this to 2¹⁵ steps (0 … 32768). When you open a true 16-bit TIFF, Photoshop remaps the full 0–65535 range into its narrower internal representation.

Pakon RAW files typically do not populate more than about half of the available 16-bit histogram bins to begin with. If you convert such a file to a linear 16-bit TIFF and open it in Photoshop without expansion, Photoshop’s internal remapping collapses many of the Pakon’s distinct ADC steps onto the same internal value. In practice you lose roughly one bit of effective scanner precision.

The RGB +1 EV expansion in MakeTiff was designed to avoid exactly this:

• The RGB data are multiplied by 2 (one EV).
• This creates a “comb” in the histogram: one unused bin between each populated bin, but no clipping, because the Pakon data never filled the entire range.
• When Photoshop then compresses the 16-bit TIFF range into its internal 15-bit space, those comb gaps are pushed back together and all original Pakon steps are preserved.

So for Pakon RAW, using RGB +1 EV expansion allows you to retain the full tonal resolution delivered by the scanner inside Photoshop, instead of silently throwing away one bit of ADC fidelity.

Relevance for ColorPerfect and Other Hosts than PS

ColorPerfect is implemented as a Photoshop-format plug-in. Even if a host application like PhotoLine uses true 16-bit internally, it still has to present pixel data to the plug-in in Photoshop’s reduced 15-bit range. Therefore, the same considerations apply: if you want to preserve the Pakon RAW sensor precision when working through a plug-in interface, you should use the RGB +1 EV expansion in MakeTiff before bringing the data into the host.

Thank you Christoph. That was enlightening. I have some further questions.

First something I have always wondered about:

Why are the Pakon raw files so dark compared to linear tiffs from other scanners?
I thought the histogram represented all of the total values in a file, but something else seems to be going on. The files from the most common Pakon scanner, F135(+) is supposed to be 14bit I believe. But if you don't use the expand option they fill only a tiny amount on the left side of histogram. If I scan a linear tiff with my 14bit Coolscan V the resulting file and histogram looks much brighter and fills a lot more of the histogram.

Is the RGB +1 EV setting useful for files from other scanners as well?
Should it always be used when using tiffs with Colorperfect?

And finally, what does the Auto Colorneg and Auto Colorpos settings do, and when to use them?

Why Pakon RAW Files Are So Dark

The Pakon scanners store their planar RAW data essentially as the direct numerical output of the scanner’s analog-digital converter. For the F235, a 14-bit ADC is explicitly documented. For the F135, F135 Plus and F335 models, various specification sheets mention 16-bit conversion, but in practical use the effective numerical range of the RAW data seems to correspond to what we would expect from a 14-bit capture pipeline.

If we assume a 14-bit ADC, the technically possible range of values is

0 … (2¹⁴ – 1) ≈ 0 … 16383.

When these 14-bit values are written into a 16-bit TIFF container without any scaling, they can at most populate roughly one quarter of the 16-bit histogram. Even for black-and-white film, where the film base is comparatively bright, the numerically populated portion of the histogram would remain confined to that lower quarter.

For colour negative film the effect can be more pronounced. If the scanner’s exposure is set in such a way that unfiltered lamp light barely reaches a differentiable density level, then adding the orange mask has the predictable consequence that the red channel becomes somewhat darker, the green channel significantly darker, and the blue channel darker still. Under these circumstances the RAW data may occupy significantly less than 25% of the available 16-bit range. The result is a numerically “dark” but correctly linear file.

Is RGB +1 EV Useful for Other Scanners?

The RGB +1 EV expansion in MakeTiff is specifically useful whenever the scanner’s linear output does not fill the 16-bit container. In the Pakon case this is exactly what happens: the captured values sit in the lower portion of the container, and expanding them by one EV will not clip anything.

This must not be generalised to all scanners. NikonScan, for example, expands 14-bit acquisitions to the full 16-bit container range. When Photoshop subsequently reduces the data to its internal 15-bit plus one range, no precision is lost because NikonScan has already scaled the data appropriately.

For scanners with less than 16 bit ADCs that already populate the 16-bit container or most of it, expanding again by MakeTiff is neither necessary nor desirable. It should only be done when it is clear that the scanner’s linear output leaves substantial headroom and that no channel will be driven into saturation.

Should RGB +1 EV Always Be Used with ColorPerfect?

No. It is safe to use +1 EV when this does not risk clipping any channel and when the scanner’s output underutilises the 16-bit range. This is the case with Pakon RAW.

Auto ColorNeg and Auto ColorPos in MakeTiff

MakeTiff provides two automatic expansion modes for linear scans.

• Auto ColorNeg analyses the per-channel brightnesses of a negative scan and expands all channels individually by the maximum amount that is safe for each channel. This is suitable for treating each frame on its own but is not appropriate when multiple frames must share identical numerical settings. This is relevant whenever one intends to stitch several scans to form a wider original, or whenever exact carry-over of settings is required.
• Auto ColorPos also analyses channel brightnesses but expands the RGB channels uniformly by the amount permitted by the channel with the least headroom. This maintains the channel relationships of the scan and is therefore suitable for slides and for colour negatives treated individually. For digital-camera-based images it is the only automatic expansion mode that is safe in principle, although digital-camera images ordinarily should not be processed via MakeTiff’s linear-scan mode.

In summary, the automatic expansion modes are appropriate when each frame is considered individually and when no clipping occurs. They should not be combined with workflows that require identical settings across frames. For digital camera data, only uniform expansions such as Auto ColorPos are theoretically safe, but the linear scan mode of MakeTiff is not meant for such data in the first place. ColorNeg DC and PerfectRAW depend on the original per-channel relationships of digital camera files being preserved, and any per-channel expansion would invalidate those relationships.

Final Remark

None of the expansions discussed here are strictly required for using MakeTiff or ColorPerfect successfully. As we have outlined at some length, however, there are specific use cases where such measures are beneficial, and it was for those situations that I implemented them. Returning to the Pakon scanners, I have long intended to investigate whether their numerical range could be expanded in a controlled manner. On 14-bit devices this can make a tangible difference, as is evident from the use of analog gain strategies in NikonScan with the LS-8000, whose 14-bit ADC can be made to yield more usable information for ColorPerfect’s ColorNeg.

Thank you. That cleared up a lot of things for me.

Yes, there seems to be some confusion around the ADC in the F135(+) model.
I have seen sales brochures stating 16bit and in the Pakon user groups many seem to believe it uses a 12bit ADC.
However, I have the service manual for the F135(+) which clearly states that it uses a 14bit ADC so I consider that to be the most reliable source.
I have the service manual for the F335 as well, but it does not specify what bit depth the ADC uses.

C.Oldendorf wrote: Sun Nov 23, 2025 7:12 pm Returning to the Pakon scanners, I have long intended to investigate whether their numerical range could be expanded in a controlled manner. On 14-bit devices this can make a tangible difference, as is evident from the use of analog gain strategies in NikonScan with the LS-8000, whose 14-bit ADC can be made to yield more usable information for ColorPerfect’s ColorNeg.

This is interesting. Do I understand you correctly in that you want to investigate whether it would be possible to adjust exposure on the Pakon?
I have also been wondering how the Pakon scanners deal with exposure. On scanners like the LS-8000 you mentioned an increase in exposure will always lead to longer scan times, but the Pakon scanner I have (F135+) seems to to scan a roll of film with more or less the same speed whether the negatives are thin or dense. Still it seems to deal with both without problems. I have scanned very dense negatives on my Pakon were other scanners have struggled and the results have always been good. The other variables would be to increase the intensity of light or sensor gain. A third option I guess is that it scans with a fixed exposure but I don't see how that would be possible without clipping. Peaking inside when doing its calibration routines it does seem to be able to adjust the intensity of the light. So that might be the most plausible explanation. Still I don't know how it be would be able to set the correct exposure without any form of prescan, which the Pakon does not do.