Dear Lindsey,

From your snapshot it is a bit difficult to understand what kind of image is recorded and what you would expect: is it a color image or grey level? Do you know on how many bits the image is originally coded?

If the raw image is a grey level image, it looks like your image you posted is not using a grey level look up table, this is a simple thing to change.

By "The image quality is great when the TIFFs are recorded and saved" do you mean on the acquisition software everything looks fine, but when you open a TIFF file (with any software?) things go wrong? Just in case, you could check if there are saving options (different file types, coding...).

Could you provide one raw TIFF image file from your sequence?

Alternatively, ImageJ has a very active and helpful community that can be reached in the link below.

http://imagej.1557.x6.nabble.com

ImageJ typically defaults to open TIFFs in 8-bit mode no matter what the actual image bit depth is. Go to the Image menu, select Type, and make sure that ImageJ is set to the correct bit depth.

Dear Ron,

What you write is a bit surprising. Our group have been using ImageJ from different cameras with different bit depth (8 to 14, grey levels only), and depth was always well recognized (8 bits images from 8 bits cameras and 16 bits images from 10+ bits cameras). We never faced such a problem (it may be specific to the way this camera save images).

In my experience, changing image depth from the image menu can only scale down pixel values (min to max levels to 0-255 from xbits to 8bits for instance). If an image is seen as 8 bits, setting it to 16bits will not change pixel values. In other words, if there is an issue with the initial image, changing depth type is unlikely to solve the problem. You may a different experience though.

Thanks so much for your replies -- 

I did convert a stack to  every other format in ImageJ (16-bit, 32-bit, etc), with no change. I suspect it is an issue with the source program doing some kind of conversion as it saves the files. Because it's on a dedicated computer, it will be a while before i can check the original format. Also, it didn't seem to change when I tried to view it as black and white in ImageJ (the camera is greyscale only), so it shouldn't have the color that I'm seeing.

Another thing may be relevant: Because I am studying vertical locomotion, I did rotate the camera vertically (more pixels are available horizontally than vertically). Would this affect any conversions?

The camera should be fine in any position, so no worries on this side, it will not affect image quality or conversion.

Maybe NAC provides a software to read files generated with their cameras (on their website?)? TIFF should be readable with any software, but they may have done some modifications to the way it is saved.

I see on NAC website that their cameras usually have different "bit density" (= bit depth), 8 to 12 bits. You could try to save with different settings.

Ok, I've gotten back to the camera-coupled computer and realized it was compressing the files without my knowledge. However, saving the tiffs as uncompressed doesn't seem to do anything. I'll attach some screenshots of my save options (in order) because there seems to be a lot of them.... (the manual said nothing about this ...)

whoops - they are in reverse order, and somehow sideways... sorry! 

Here are a few frame samples to illustrate how different they look throughout the stack

It looks already much better. I don't know what kind of feature you would like to get from your images, but if you need to be quantitative about intensity, I would avoid compressing.

Does the top image is what you would like to have or is it still very different?

The fact that the image quality changes throughout the stack is... strange (at least I never experienced it). It looks like the contrast is changed from one image to another. Is there some more options on that side?

Did you try to check "mono 8-bit uncompressed" (last image of the windows screenshots - there is a "Print Scr." key on the keyboard that allows you to take Windows screenshots) instead of "uncompressed" from the list?

Did you try to open the TIFF stack on the Windows computer you use to save images? Unlikely to change things, but who knows...

hmm -- I'll try that. I'll also light it fully to see if that changes things... Thanks for your help!

The problem is with opening the file in the correct bit depth. If you open a 16-bit image as an 8-bit image, you will not get the same results as if you change a 16-bit image to an 8-bit image after it is opened. Likewise, if you open an 8-bit image as a 16-bit image, you will also not get the expected results. There are also signed and unsigned versions of some bit-bepths.

Compression is definitely problematic if you don't know which compression method is being applied. I'd tend to try to avoid compression using the MPEG CODEC since this will likely result in a loss of data because of the compression method used. MPEG uses motion prediction that makes some frames impossible to reconstruct without using data from other frames which will most likely not work well for your purposes.

Try saving the image as a raw TIFF stack if that option is available.

Ok - I managed to open the stacks in Preview (Mac -- usually hard to do without crashing when you have 3,000 frames) and they look fine. It must be something with ImageJ ...