Read the number of frames in TIFF stack without loading?

Share icon

Hi,

I need to record the number of frames in each TIFF stack from a few hundred TIFFs in various locations over a network connection. My code loads each TIFF, records the dimsize into a numeric wave, filename into a textwave, killing each image before loading the next TIFF. It runs quite slowly and I'm wondering if there's a way to get the TIFF dimensions without actually loading, which would speed things up a lot.

Something like XLLoadWave/J=1 but for images?
Hi,

Try using the ImageLoad command with the /RTIO tag to read tags only. Try this initially with a few images to see if you can determine if there is a tag with the number of frames in the stack. Also this command creates a variable called V_numImages that may be what you need.

It's been quite a while since I've worked with tiff stacks, but there may not be a standard implementation for stacks; it may vary with the software creating the files. (A quick look at Adobe's spec for TIFFs seems to bear this out, but I'm sure someone will correct me if I mistype here.) If so, you will need to look to the software for specific details. However, with the /RTIO tag and files with a known format, you should be able to find and answer to your question.

Hope this helps.

Post an example file (as small a file as possible) if you need more assistance.

September 12, 2016 at 07:19 am - Permalink

Unfortunately there is no tag that specifies the number of frames in the stack because TIFF tags are usually on a per image basis. Some people may save this information in various other tags but the only way to figure out the number of images in a TIFF file is to actually read all the individual IFDs; you do not need to read/load the images but you need to read all the IFDs. This is a slow process when you have a very large file with many thousands of frames.

In some special cases, when all the images are saved with the same size (no compression), you can estimate the number of frames from the size of the file and the size of an image and IFD.

A.G.
WaveMetrics, Inc.

September 12, 2016 at 10:46 am - Permalink

Thank you for the replies. I will stick to load-read-kill for my code.

Just one observation in case it is helpful for anybody. Once loaded, the string variable S_info is populated with a \r separated list of values. This contains number of frames. Parsing that string is a possibility, but using dimsize is easier. This still requires loading the files.
Example of S_info
•Print S_info
  ImageJ=1.49e
images=16
frames=16
unit=micron
finterval=1.8536666631698608
loop=false
min=44.0
max=3616.0

September 13, 2016 at 05:54 am - Permalink

sjr51 wrote:
Just one observation in case it is helpful for anybody. Once loaded, the string variable S_info is populated with a \r separated list of values.


What operation or function are you using to load the TIFFs?

September 13, 2016 at 05:05 am - Permalink

@jtigor Very strange. I use ImageLoad/P=$pathName/T=TIFF/S=0/C=-1/LR3D/N=image fileName in my procedure to do the loading. I just ran it again and that command doesn't make the S_info string. I was getting this by dragging and dropping an image file onto Igor to load it rather than running my code.

September 13, 2016 at 05:55 am - Permalink

sjr51 wrote:
@jtigor Very strange. I use ImageLoad/P=$pathName/T=TIFF/S=0/C=-1/LR3D/N=image fileName in my procedure to do the loading. I just ran it again and that command doesn't make the S_info string. I was getting this by dragging and dropping an image file onto Igor to load it rather than running my code.


Yes -- odd.

I looked through several image loaders and didn't see one that created s_info. I also tried drag/drop onto IP6 & IP7, while this loaded my test image, s_info was not created. Maybe you initially used a package or example experiment?

September 13, 2016 at 06:41 am - Permalink

@jtigor Strange... drag and drop works for me in IP6 and IP7 (on a Mac). I think this info must be within the TIFF header. The files are generated in OME-TIFF format, but then they have then been cropped in ImageJ. I'm guessing ImageJ saves something in the header that Igor reads when it comes in. When I load these files with my code, Igor loads fine but spits out
TIFFReadDirectory: Unknown field with tag 50838 (0xc696) encountered
TIFFReadDirectory: Unknown field with tag 50839 (0xc697) encountered
twice for each file. I'm guessing this is the information stored in S_info, but it's a mystery why it loads OK by drag and drop.

September 13, 2016 at 08:02 am - Permalink

You might try loading using imageload with the /RAT flag to read all the tags. If ImageJ is adding a special tag with #planes you should be able to find it in the waves/variables that Igor saves to the data folder where the image wave is loaded. This would save you from loading the entire image.

September 13, 2016 at 10:40 am - Permalink

Here is the explanation for S_info:

When you use ImageLoad to read a TIFF image that contains Tag 270 (IMAGEDESCRIPTION), the contents of the Tag data are written to S_info. If you are reading multiple TIFF images from a stack then the contents of the very last Tag 270 will be in S_info. Using this to deduce the number of images assumes that the contents of the tag would (a) exist and (b) be accurate.

Using /RAT is a more reliable approach.

A.G.
WaveMetrics, Inc.

September 13, 2016 at 11:01 am - Permalink

For what it is worth, I wrote the following code many years ago to interrogate TIFF files. It opens the file for binary read, and reads in the Tag data. I cannot guarantee that it is bug-free and works in all cases, but it worked for the files I used it for. A modified version of this may do the job for you, and may be quicker than loading the all the images.
Hope this helps.
Kurt
TIFFTagReader.ipf (16.44 KB)

September 13, 2016 at 11:11 pm - Permalink

FWIW, the RAT tag in Igor Pro now does the equivalent to the TIFFTagReader code.

I believe that the TIFFTagReader code does not work properly for multi-page files. The issue seems to be with how the reader resets the file position to move to the next IDF position. I think instead of setting the next read position as the vdata value, the file position has to be moved by vdata times the byte count *from* the current position.

Anyway ... if you are still around, thank you Kurt. The reader helped me systematically deconstruct how a TIFF file is stored first hand beyond just reading a scattering of Webpages about the format itself.

June 13, 2019 at 04:52 pm - Permalink

jjweimer wrote:

Anyway ... if you are still around, thank you Kurt. The reader helped me systematically deconstruct how a TIFF file is stored first hand beyond just reading a scattering of Webpages about the format itself.

Hi Jeff,

I am still here, and you are very welcome.

I spent a great deal of time during my PhD days (early/mid 90's) writing code to read and extract data from many propriety and often opaque instrument specific file formats so that I could do my analysis etc in Igor. I wrote TIFF read/write code to use and store instrument specific configuration data in the private tags, but still have the main data in a standard, universal file format. The code I posted some years ago was adapted from that behemoth. That arm of the business was sold on many years ago now and sadly I have not touched this sort of thing since.

Cheers,

Kurt

June 13, 2019 at 11:43 pm - Permalink