Over the last week I wrote about image structures, bit depth, and some of the difficulties of how images are viewed on our display systems. Today I’ll wrap everything up, and answer one of the most common questions I hear, “Why does this image look so good now, but when I open it in Photoshop it’s dim/ black/ the wrong color?”
I also asked a question on how the difference between photography applications and analysis applications would have an impact on this display-in-Photoshop problem.
- Image scaled in NIS Elements
The Headache of Lost Scaling
When scaling values are adjusted in Photoshop, the numerical data values in the image (counts) are re-mapped into the image itself. So, if the image is dim (Say the image has an average intensity of 55 counts), and I use “adjust levels” in Photoshop, the image data will alter, and read out a higher average value, (say 200 counts). When I save the image, the new (scaled) pixel values are saved, and the original values are lost. Fortunately, this is not the case when using analysis software. Any package used for image analysis will offer (or should offer) scaling tools for display control only. So, when adjusting these levels, all we are doing is altering how an image appears on screen, but the number values contained in the image file do not change. This means I can adjust an image to make it look beautiful in a program like Elements, and I can save the image, I’ll even save it as a nice color TIFF file, and viola, I open it up in any viewing program and the image has lost all of the scaling adjustments I just made!
- Same image from above, but saved as TIFF and opened in default windows viewer
This is because the analysis software is doing what it should do. It’s not altering data arbitrarily. Consider that an image viewed inside of an analysis package is layered. You are looking at the image data, plus the scaling controls, so data+scaling = my screen. When you save the image, the scaling adjustments are not saved (Or rather there is not a common filetype-defined place where scaling values are supposed to go), so now when the TIFF file is opened, we see data+no adjustments = my screen. The same thing occurs when you open an image in Photoshop – alas the question is answered! But wait – It gets more interesting…
TIFF vs. the 12 Bit camera
Not only is scaling lost in the image, but we start to open up an entire side can of worms related to file structures. Files are basically containers, which can be thought of as plastic bins, or shoe boxes, or any other physical object in the tactile world. A file type will define what the file is supposed to hold (i.e. an image, a movie, text or compiled code) as well as define dimensional limitations on the file. Dimension limits might include display sizes, bit depths, or character restrictions. I wouldn’t store food in my rolling toolcart in the garage, and the toolcart wouldn’t fit lettuce really well, as it’s designed to hold heavy flat tools, and not bulbous heads of wet lettuce! File structures are similarly use-designed. The most widely used filetype in imaging is the TIFF file. The TIFF structure (Owned by Adobe) has a lot going for it as a generic image file structure. It can hold custom lines of text, which can be used by imaging applications like MM or NISE to set metadata. It handles both monochrome and color image types, and supports non-compressed saving. The drawbacks to the TIFF format come into play when we consider the file types and our cameras, and our specific needs. TIFF supports either monochrome images in 8, or 16 bit formats, or color images in 24 Bits(8 Bits each for Red, Green and Blue) and 48 Bits (16 Bits each for R,G,B). Now our cameras usually output in 12 or 14 bit. So what filetype should we use? Because we don’t want to down sample(divide) the image and lose data fidelity, we are forced to use the 16 bit monochrome, or 48 bit color, TIFF file. In doing so we are creating a container (say for this example a monochrome image) that will never be filled to capacity (i.e. if the camera is 12 bit, you’ll never get a higher number than 4095 – but at the same time, the maximum value in the 16 bit image is 65,535!). These and other TIFF inadequacies are what led to the relatively development of manufacturer specific “RAW” filetypes, like the Canon CRW and Nikon NEF In the professional and pro-sumer photographic markets. Both Canon and Nikon cameras are 12-Bit per channel. Instead of wasting precious SD-Card storage space with empty bit values in a 48 Bit Color TIFF, both manufacturers end-ran the issue by creating a filetype from the ground up to support the 12-Bit range. This also offered both manufacturers the option of adding custom metadata tags and Exif data, making it easier for a photographer to work with the files and take better photographs. The microscopy community does have a boutique format, and over time it may become the new standard in research imaging. Right now there is an ongoing initiative through the Open microscopy Environment project to offer similar supported file structures to our community, and continues to push forward in capability and acceptance. For now – it seems the status quo continues to be the TIFF. I’m keeping my fingers crossed that the software companies will adopt the OME format (or some other community standardized format) so that we can avoid all of these issues in the near future…
Color vs. Color
So far we’ve concentrated on monochrome images. We can add to the fun by covering the problems of color. In my humble opinion, good microscopy software shouldn’t work in “color” modes per se. The reason for this is that a monochrome camera never collects “colors” of light as referenced to a color wheel. It collects images that represent a specific nanometer wavelength and bandwidth of light. We then color-code the monochrome data so we can interpret it on-screen. Furthermore, when comparing a microscopy image to a typical color image we run into issues with channel numbers. For example if I acquire a DAPI, FITC, TRITC and Cy5 multi-channel image, how do I save this into a Red Green and Blue TIFF image container? On top if this problem we have that of color mixing, which I posted on a while back. This stems from the fact that FITC isn’t primary green, it’s more blueish-green, so when saving to a TIFF do I save 10% of the FITC channel into the blue channel of the TIFF, in order to preserve the hue? Or do i save 100% of the FITC channel as “green”, lose the hue, and preserve the spectral separation? Finally, how should the software handle non-primary channels and assignment to a multicolor tiff? I.e. TRITC is orange-ish. So what if I acquire DAPI and TRITC, do I save the TRITC into the Green TIFF channel, the Red TIFF channel, or both? These limitations of the TIFF file will cause you to get images in Photoshop that have mixed color, incorrect channel assignments and dim images. As we’ve seen above, all of these issues are related to the filetype limitations.
Save as Displayed
If what you want is simply a representative image, and you will NEVER MEASURE BRIGHTNESS on the representative image, then there is a simple solution I’ve outlined before on making an elegant screenshot in Elements. Other packages like Meta will allow you to save the image “as displayed”, which is essentially a screen capture. Just make sure that this file is named as a display image (“image***_display.tif” works well) so that you don’t later try to pull measurements from it when it’s crunch time to get your paper in. Because hard drive space is cheap, I recommend saving your files in a native format like ND2 (for Elements) or STK (Meta) or one of the other manufacturer specific file types. Keep these images as “archive files” that you know are un-manipulated raw files. On the side, I make an “export” folder where i save display files that can be used to show off to colleagues.If you need to acquire images in one package, and analyze them in another, you can find file importers like those available for ImageJ, or as a last resort, export each image as a monochrome TIFF.
So, now you know more than you ever wanted to about file formats, and why images don’t look good in Photoshop. Hopefully this knowledge of file structures will help produce better microscopists, and most importantly, more accurate data!
-Austin