color .tiff loads as all zeros

Simple question - I'm trying to load multiple color .tiff files that definitely have rgb data in them. They're very pretty in Windows Photo Viewer. When they load in as 3D waves, every value is zero. No data gets loaded whatsoever, but the waves are the correct dimensions for the image that was loaded.

I've loaded monochrome .tiffs no problem. My current workaround is to re-process the color .tiffs in the tomography software to make monochrome images, but that takes a loooooong time for all the images I need to analyze. Any help would be appreciated. The command that I use to load an image looks like this:

ImageLoad/P=AllSlices/T=tiff/Q/N=raw_30 "raw_30.tif"

Again, this works for monochrome .tiffs. Just not color. Also, there's no difference in .tiff or .tif, as there shouldn't be. Sample image attached.

sample rgb .tiff image

I get this error:

  TIFFReadDirectory: Unknown field with tag 347 (0x15b) encountered
  raw_4.tif: JPEG compression support is not configured

If I use other software to save the tiff without compression I can load in Igor. The uncompressed file is 38.6 MB.

First note that the syntax you used (as generated by the dialog) includes the /Q flag.  This option turns off the printing of diagnostic information to the history.  If you remove the /Q you get the errors that Tony reports.

There are various forms of compression supported under the TIFF standard.  Igor does not support JPEG compression in TIFF although normal JPEG files are supported.  TIFF Tag 347 contains the JPEG quantization information for this compression.

I'm curious what arguments led to the creation of this file.  Normally one would use TIFF in order to pack scientific data in non-lossy format.

In reply to by Igor

Thanks for the reply (and from Tony as well). I'm curious about how the .tiff files were generated to begin with as well, since they could have easily just been any other format, especially since these were reduced in dimension from the raw data used to create them.

If you look into LibTiff (https://libtiff.gitlab.io/libtiff/) you can find a large set of utilities that can be used to create some really strange TIFF combinations.  Over all, my primary concern is that JPEG implies lossy compression.  The loss of data may be an acceptable consideration in some applications but one must use caution in selecting this option.  I suspect that whoever made that choice wanted to combine multiple images into a single file and apply high compression algorithm at the same time.  This is accomplished in this case but unfortunately, it is not a file format that we support.