Yes, while that is true, the problem is that often in our art, we are only using a small sub-set of colours and often with a gradient, this is where you will notice the limitations the most.Īs you can see in the image below, the gradient in the sky becomes heavily degraded when we use 8bit. If you're interested in understanding more about the above, check out the Wikipedia page on colour depth. Let's first outline 2 facts: 8 Bit colour has 256 shades of Red, Green and Blue for a total of 16,777,216 colours (256x256x256) 16 bit colour has a whopping 65,536 per channel! That means a total of… a lot. If you have a little understanding of bit depth you might think that, since a jpg file is only 8 bit, there's no benefit to working in 16 bit if you're saving your image as a jpg. Instead, I want to show you the benefits of working in 16bit. I don't want to get too technical in this article as you'll find plenty of information online about it. (losslessly-converted) pixels, or you could explicitly set theĭisplay range back to 0–255 after the conversion.Bit depth refers to the number of variations of a single colour (Red/Green/Blue) which can exist in your image.

Ignore the way the displayed image looks, and work with the Lossless (as is its 8-bit ->32-bit conversion), but automaticallyĭepending on your particular use case, you could either just I believe that ImageJ’s 8-bit -> 16-bit conversion is, in fact, Now the image displays in its original, washed-out form. So that you can see that it is still washed out: Image > Adjust > Brightness/Contrast. You can display the 16-bit image with a display range of 0–255 You still have the original pixel values. Status bar pixel values running from 64 to 192, verifying that Over the ramp image (from darker to lighter) you will see in the So if you move the cursor from left to right If you hover the cursor over a pixel in the image, Fiji’s status bar ImageJ did set this display range automatically,īut it didn’t actually modify the pixel values. Range of 64–192, the minimum and maximum of the pixel values The displayed image no longer appears washed out. Now convert to 16-bit: Image > Type > 16-bit Image info, and note that the display range is 0–255. Now the image is somewhat washed out, with a range of pixel This gives you a full-range, 0–255, 8-bit, grayscale image. (Size can be whatever – 512x512, if you will.) I will work (in Fiji) with a locally-created image, rather than your Itself – that is, the values of the image pixels – but, rather, I do not believe that ImageJ is actually modifying the image

To the best of my understanding (which may not even be remotely close to acceptable), this isn’t something that naturally happens during this type of conversion (taking the 8-bit image, then going 32-bit and then back to 16-bit will effectually convert it to 16-bit), because I can do more or less the same thing in Photoshop losslessly, which’s a technical requirement in my case.Ĭan anything be done to rectify this behavior in ImageJ?īest regards and sorry for the inconveniences. Load it into ImageJ, go to Image/Type and select either 16-bit or 32-bit the original values are immediately lost and the image will be displayed with a modified contrast. To better explain where I’m going, please take this deliberately washed out 512x512 raw 8-bit grayscale image. Turns out I need ImageJ to losslessly process an unsigned 16-bit grayscale image, but whether the image has beforehand been converted to this format and loaded as such or not (thus leaving conversion to ImageJ itself), it makes no matter ImageJ will automatically modify it in a way that would appear as if it were being corrected for better contrast, but this is NOT the desired behavior. First of all, a big thank you to the ImageJ developers this application has truly simplified a lot of things for me.

Photoshop convert to 8 bit