Blog
Back to Blog
July 22, 2026

Converting 16-bit Western Blot Images to 8-bit Without Losing Quantification Data

Short answer: you can't convert a 16-bit western blot image to 8-bit without losing quantification data. You will lose it. The question is whether you lose enough to wreck your analysis or just enough that nobody notices in the figure panel. Those are two very different situations, and conflating them is where people get into trouble.

A 16-bit TIFF stores each pixel as a value between 0 and 65,535. An 8-bit image compresses that into 0–255. That's a 256-fold reduction in the number of intensity levels available. If your bands span a range from, say, 500 to 40,000 counts in the raw 16-bit image, you have ~39,500 distinguishable intensity steps to work with. After linear scaling to 8-bit, those same bands now occupy maybe 1 to 155 — roughly 154 steps. Fold-change differences that were clearly resolved at 16-bit can collapse into the same 8-bit value, especially in the low-signal range where your weakest bands live. For display in a figure? Often fine. For densitometry? Do your quantification on the original 16-bit data. Always.

What actually happens when you scale down bit depth

Most software (ImageJ/Fiji, Photoshop, Image Lab export) converts 16-bit to 8-bit by linearly mapping the minimum and maximum pixel values in the image to 0 and 255, respectively. This is a straight rescale. Here's the problem: that mapping depends entirely on what the min and max happen to be in your particular image, which means two images from the same experiment can get different scaling functions, silently distorting any cross-blot comparison.

But even within a single blot, the math is unforgiving. Suppose you have two bands: one at 5,000 counts and one at 10,000 counts in the 16-bit image (a genuine 2.0-fold difference). Your image's max pixel is 50,000. After linear scaling to 8-bit:

That's only a 2% error — tolerable. Now try it with weaker bands:

But shift Band A to 900 counts:

This rounding error is systematic at low intensities and unpredictable — it depends on exactly where your values fall relative to the bin edges. For bands near background, where the signal-to-noise ratio is already marginal, the additional quantization noise from 8-bit conversion can easily exceed your actual biological effect size.

When people hit this problem in practice

The most common scenario isn't someone deliberately choosing to quantify an 8-bit image. It's one of these:

  1. The imager exported JPEGs or 8-bit TIFFs by default. Some older ChemiDoc software versions, or Azure Biosystems with certain export settings, will save a "display" image alongside the raw data. If you grab the wrong file, you're quantifying the 8-bit display copy. Check your file: in ImageJ, go to Image → Type and confirm it says "16-bit" (or "32-bit"). If it says "8-bit" or "RGB Color," you're working with compressed data.

  2. Someone pasted the blot into PowerPoint or a Word doc and is now trying to quantify from there. Those applications convert everything to 8-bit (often JPEG-compressed) internally. The quantification ship has sailed. Go back to the raw file from the imager.

  3. Journal figure preparation. You need a smaller file, or the submission system chokes on 50 MB TIFFs. This is the one legitimate reason to convert — but you should only do it after all quantification is complete, and you should note in your methods that densitometry was performed on the original 16-bit acquisitions.

  4. ImageJ's "Brightness/Contrast → Apply" trap. In Fiji/ImageJ, if you adjust brightness and contrast for display and then hit "Apply" on a 16-bit image, it remaps the pixel values destructively. If you then save, your raw data is gone. This catches people constantly. The rule: never click Apply on your quantification image. Adjust B/C for display, take your screenshot or export for the figure, but leave the underlying data untouched.

The right workflow: quantify first, convert later

Here's what I recommend and what most imaging core facilities will tell you:

For quantification:

For figures:

For archiving:

Quantify from your original 16-bit images, in your browser. VoilaBlot reads 16-bit TIFFs directly — no conversion, no upload to a server, no data loss. Your image stays on your machine.

Try VoilaBlot free →

What about fluorescent vs. chemiluminescent acquisitions?

This matters more than people realize. Near-infrared fluorescent detection (LI-COR Odyssey, Azure Sapphire in NIR mode) typically produces images with a much wider usable dynamic range than ECL — often 4+ orders of magnitude versus ECL's ~2 orders on digital and a miserable ~4–8× on film (Gassmann et al., 2009). Because NIR fluorescence images tend to use more of the 16-bit range meaningfully, converting them to 8-bit causes proportionally more damage.

ECL images, especially short exposures where your bands occupy a narrow intensity window (say 2,000–15,000 counts out of 65,535), actually survive 8-bit conversion slightly better in terms of relative quantification accuracy — but only because you're using less of the dynamic range to begin with. This is not an argument for converting; it's an observation that your ECL data was already somewhat compressed in practice.

If you acquired on film and scanned the film, you're already dealing with a limited dynamic range regardless of the scanner's bit depth. Scanning film at 16-bit gives you more gray levels to describe the film's density, but the film itself was the bottleneck (Gassmann et al., 2009). Quantifying scanned film at 8-bit versus 16-bit makes less practical difference than quantifying a digital acquisition, because the film already compressed your signal.

Edge case: "I only have the 8-bit image"

Sometimes the raw 16-bit file is genuinely gone — the imager crashed, someone saved over it, the hard drive from 2019 is in a landfill. Can you still quantify the 8-bit image?

Yes, with caveats. If your bands are strong and well-separated (integrated density values comfortably above background, no saturation at 255), an 8-bit quantification can still give you directional results — protein X goes up with treatment, roughly 2–3 fold. What it can't give you is precise fold-change values or reliable statistics across low-abundance targets. The quantization error at 8-bit adds noise that inflates your CV, and if any pixel in your band is at 255, that band is saturated and unquantifiable regardless.

In practice, if the 8-bit image shows bands ranging from roughly 30 to 200 (no clipping at either end), and you're making within-blot comparisons with a properly behaving loading control, you can extract usable data. Report it honestly: note the bit depth in your methods, and understand that your error bars are wider than they would be with the original file.

The bottom line

Bit depth conversion is a one-way street. Every 16-bit-to-8-bit conversion destroys information — the only question is how much of that information you needed. For figure preparation, the loss is cosmetically invisible. For quantification, it introduces rounding errors that are worst exactly where you can least afford them: in your weakest bands and your most subtle fold changes. Quantify on the raw acquisition, convert for display, and never overwrite your originals.

References

Related Posts