Formats and bit depth · Output files

When a 16-bit TIFF makes sense, and why you can't make one from a web image

An online store needs 8 bits. Retouching, print and archiving sometimes need more. Here is the difference, what it costs in file size, and how a 16-bit TIFF is developed from RAW right on the studio computer.

The question we keep hearing

"Can you deliver RAW?" or "We need TIFF with LZW compression." Both requests usually come from the same need: an image with as much headroom as possible for further processing. A catalog studio, a print house or a retoucher doesn't want a finished web image. They want material they can keep working on.

Standard web output has no such headroom, and it doesn't need any. That is why it makes sense to get two outputs from a single shoot.

Bit depth is not color gamut

These two terms are often confused:

• Bit depth is how many tones can be told apart. 8 bits gives 256 levels per channel, 16 bits gives 65,536.
• Color gamut is how saturated the recorded colors can be. sRGB is the narrowest, Display P3 and Adobe RGB are wider.

On a finished image, 8 and 16 bits look the same to the eye. The difference appears the moment someone edits the image: lifting shadows, changing white balance or converting to a print profile breaks a smooth 8-bit gradient into visible bands.

16 bits after lifting the shadowssmooth gradient

8 bits after the same editbanding

What about the web?

The web works in 8 bits and sRGB, and that is enough to present a product. Higher bit depth only matters online for wide-gamut or HDR content, and that requires AVIF or JPEG XL. WebP is 8-bit only.

The formats side by side

How much space it takes

One image from a 45-megapixel camera such as the Canon EOS R5 Mark II (8192 × 5464 px), approximately:

Uncompressed sizes are exact (pixels × 3 channels × 1 or 2 bytes). The rest are typical values and depend on the subject; a product on a plain background compresses better.

For a 360° spin of 36 frames, that adds up to several gigabytes per product. This is the main reason 16-bit files don't belong in the cloud next to web outputs.

Why a 50 MB RAW becomes a 269 MB TIFF

The jump looks wrong at first: the TIFF is more than five times the size of the file it was made from. It is correct, and it does not mean the TIFF holds five times more information. Two things happen during development.

One value becomes three. A camera sensor does not record full color in each pixel. Every photosite sits behind a red, green or blue filter and measures one number. The two missing colors for that spot are calculated from its neighbors when the file is developed, a step called demosaicing. A RAW stores the single measured value; a TIFF stores the finished red, green and blue.

Going from 14 to 48 bits per pixel is a factor of 3.4 before compression enters the picture. Note that "16-bit TIFF" means 16 bits per color channel, not per pixel.

RAW is compressed, the plain TIFF is not. RAW does not mean uncompressed. Canon's standard RAW is losslessly compressed inside the camera, so the comparison is between a packed record of the measurements and an unpacked, fully calculated image.

Calculated values are pixels × bits per pixel ÷ 8, in millions of bytes, without metadata or previews. The RAW figure is from Canon's EOS R5 Mark II manual.

The extra values in the TIFF are not new measurements. They are the result of a calculation, one particular interpretation of the sensor data. That is why a big TIFF does not replace the RAW: the RAW is the source from which a different development can be made later, and the TIFF is one finished version of it.

LZW or ZIP?

Both are lossless, so neither affects quality. LZW is older and every program reads it. ZIP (Deflate) compresses a little better, especially on 16-bit data. With 16 bits it is important to enable the predictor option; without it, an LZW file can come out larger than an uncompressed one.

Why a TIFF can't be made from a web image

Technically, any image can be saved as a TIFF. But it will only contain what was in the source:

• An 8-bit JPEG or WebP gives an 8-bit TIFF. The missing tones can't be added back.
• Lossy compression has already discarded part of the information, including fine color detail. A large TIFF made from it is just a bigger container for the same data.
• Cameras no longer save TIFF. A true 16-bit TIFF always comes from developing a RAW file on a computer.

Anyone who wants 16 bits has to start from RAW.

Why the camera JPEG looks better than the RAW

Open a RAW file with neutral settings and the first reaction is usually disappointment. The image is flatter, darker and less sharp than the JPEG the camera saved at the same moment. Nothing is wrong with the file. A RAW is the sensor data before anyone has made decisions about it, and the JPEG is the same data after the camera made all of them.

One frame of a 360° spin, Canon EOS R8 with RF 24-105mm F4 L at 50 mm, f/16. Crop of the full 6000 × 4000 px image.

What the camera adds on the way to JPEG

• A tone curve. It brightens the midtones and rolls the highlights off toward white. This is most of the difference you see above, and it is why the background turns clean white.
• A color style. The manufacturer's picture style adds saturation and shifts some hues to taste.
• Sharpening and noise reduction. Both are permanent in a JPEG. A RAW has neither, so it looks softer and grainier at 100%.
• Lens corrections. Distortion and vignetting are corrected in the JPEG; the RAW only carries the data to do it.

So a RAW is ingredients, not a finished dish. A well-developed in-camera JPEG is a very good result, and for most product photography it is the right one. The RAW starts to pay off when someone takes over the decisions the camera made: a retoucher in Capture One or Lightroom can recover highlights, set the contrast per product and sharpen for a specific print size, and get further than the camera did. That takes skill and time per image.

For an automated studio the practical middle path is the third image: develop the RAW with the same tone curve the camera used, in 16 bits. The result matches the web image, so nobody is surprised by the look, and the retoucher gets the full tonal range underneath it.

The same frame in numbers

Measured on the frame shown above. A dark, finely textured object on a bright background; other subjects will compress differently.

Two outputs from one shoot

During capture the camera saves both JPEG and RAW. The JPEG takes the usual route to the cloud and the web. The RAW stays on the studio computer, and the 16-bit TIFF is developed there, with the same crop and mask as the web output.

Good to know up front

• The look follows the camera JPEG, with small differences. Brightness and contrast are matched to the JPEG. Sharpening and noise reduction are left to the retoucher, and the camera maker's color style is not copied exactly. For color-critical work, use a color target and a profile for the specific camera.
• Storage is on the studio side. 16-bit files stay on the local machine or the customer's network drive.
• TIFFs are generated on demand. Once the edits are approved, not on every capture.

Where to run it: studio computer or cloud

Developing RAW files is ordinary computing work and it gives the same result on macOS, Windows and Linux. What differs between running it next to the camera and running it on a server is how much data has to travel, how long it takes, and one detail about color profiles that is easy to miss.

How much data travels

For one 360° spin of 36 frames:

24 MP: average of our test frames (25 MB RAW, 66 MB TIFF). 45 MP: Canon's 47.6 MB per RAW, TIFF scaled by pixel count.

On a 100 Mbit/s line, 0.9 GB up and 2.4 GB down is about four and a half minutes of pure transfer for one product, and studio upload speeds are often lower than that. Developing locally sends nothing but the edit parameters.

A full shift in numbers

One product is manageable. A production line is a different matter. A robotic workstation can capture a 36-frame spin about once a minute, which in the ideal case is 480 products in an eight-hour shift, or 17,280 frames. At 24 megapixels that adds up to the following, for each robot:

480 spins per shift, 5 shifts per week, 21 per month, using the measured averages of 2.5 MB per JPEG, 25 MB per RAW and 66 MB per TIFF. A 45-megapixel camera roughly doubles the RAW and TIFF rows.

The step from 8 to 16 bits sounds like a few extra bits per pixel. In storage it is a factor of 26: the 16-bit masters of one month take as much space as more than two years of web images.

All of these figures are for a single robotic workstation. Studios usually run several robots side by side, and the numbers multiply accordingly: four workstations produce close to 100 TB of 16-bit TIFFs a month.

The network tells the same story. To keep pace with the robot, the connection has to move one spin every minute, continuously, for the whole shift:

Sustained throughput with no headroom. A line has to be rated well above these figures to deliver them all day, and every additional robot adds the same amount again.

Web images fit comfortably on an ordinary office line. RAW files need a dedicated fast uplink, and 16-bit TIFFs in both directions need more than most studios have. This is the reason the web output goes through the cloud and the 16-bit master is developed and kept next to the robot.

How long it takes

We measured the development of 24-megapixel frames to 16-bit Adobe RGB TIFF with LZW compression:

• Laptop with an 8-core Apple M2, four frames in parallel: 1.5 seconds per frame, so a 36-frame spin is done in under a minute.
• Small cloud machine with 2 cores, one frame at a time: about 5 seconds per frame, roughly three minutes per spin, before any transfer time.

About 40% of the time goes to decoding the RAW, the rest to applying the tone curve and writing the compressed file. The work parallelizes well, one frame per processor core, with about 1.5 GB of memory per frame in progress. A 45-megapixel camera roughly doubles all of these numbers.

The color profile has to travel with the file

A TIFF in Adobe RGB or ProPhoto is only correct if it carries the matching ICC profile inside it. Without the profile the pixel values are still right, but the program opening the file assumes sRGB and shows dull, shifted colors. This is the most common reason a wide-gamut file "looks wrong" at the receiving end.

Where the profile comes from depends on the system:

The safe approach is not to depend on the system at all: the tool that writes the TIFF carries its own profiles and embeds them every time. We check the result by converting the Adobe RGB file back to sRGB through its embedded profile and comparing it with a direct sRGB development of the same frame. The two should match to within rounding.

So which one?

• Local development fits a studio that shoots volume: no transfer, the fastest turnaround, and the large files stay where the retoucher works.
• Cloud development fits occasional requests, or teams whose retouchers are elsewhere and would download the TIFFs anyway. The RAW files then have to be uploaded first.

Which output for what

What to ask when someone wants "a TIFF"

• 8 or 16 bits?
• Which color profile (sRGB, Adobe RGB, other)?
• Transparent background, white background, or no mask?
• Which compression, and which program will open the files?
• What is it for: print, retouching or archive?

The answers often show that an 8-bit TIFF from the standard output is enough. Where it isn't, the route goes through RAW.

Where this is heading: 16-bit on demand

Everything described above works today as a standalone step: a tool on the studio computer that takes the stored RAW files and develops them to 16-bit TIFF. The direction we are working toward is to make it part of PhotoRobot Controls, so that nobody has to think about it as a separate process.

The idea is simple. Every product is shot once, the way it is now, and the RAW files stay on the studio computer. The web output is produced as usual. When a particular customer, or a particular order, needs 16-bit masters, the operator marks it in the software. The local machine then picks up the stored RAW files, takes the crop, mask and other edits already approved for the web images, and delivers the TIFFs. No reshoot and no manual export.

• Only where it is needed. Most products never need a 16-bit master. Developing on demand means the terabytes from the shift calculation above are produced for the few orders that ask for them, not for everything.
• Later is fine. As long as the RAW is kept, the decision can be made after the shoot, even weeks later.
• Consistent with the web. The same edits drive both outputs, so the master shows the product the way the customer already approved it.

This is a direction of development, not a feature you can switch on yet. If 16-bit output matters for your production, tell us what you need from it: bit depth, color profile, compression, and how the files should reach your retouchers. Those answers shape how we build it.