Labview libtiff implementation

[nathand]

Here's my VI saved for LabVIEW 2011, converted to read from a file instead of a TCP stream, and with some bits stubbed out since your file format doesn't match the one I was using (and I took some shortcuts for the file I was using since I knew they would always have the same structure). My files were always black-and-white, with all the actual data grouped together, so I didn't bother reading individual stripes, I just read it as a chunk. I haven't checked if that's possible with your file too, but the IFD (Image File Directory - the metadata) is in a different position in your file relative to mine so my code doesn't actually return the data from your image. It does, however, correctly parse the metadata, at least the pieces of it that I needed. If you're willing to take some time to work through it, I don't think you'll need major changes in order to read your file, and I'll try to help. You'll want to refer to the complete TIFF specification at http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf.

[stranIO]

Hi Nathand, Peter,

You were right about this back and forth in between Labview and .Net.

I have put the whole loop in a .dll and it now executes in <200ms including byte swapping.

If I'll have time I might do this for the writer part as well.

Cheers,

Dan

[nathand]

Here's an update. This code comes close to doing the right thing with your image, in pure LabVIEW. Saved for 2011.

[pbuerki]

Hello Nathan and stran,

Thank you so much both of you for your time and efforts to help me. I tried out both solutions with the following results:

• Parse TIFF.vi + Convert to Values.vi: The example tiff file I uploaded to dropbox earlier was created in LabVIEW/IMAQ. Unfortunately, I do not know how to modify the Parse TIFF VI so that it can read Tiff files created by IMAQ.
• Read Tiff File (bitmiracle libtiff.net).vi: I can load and display my Tiff file. The total load time for the dropbox image including decimating the 1D array and joining numbers is a little over 400 ms. This is a already big improvement, but still a factor of three slower than the 32 bit libtiff library.

In my search for a fast Tiff Reader that does not require IMAQ, I came across a discussion on LAVA.org (https://lavag.org/topic/7170-tiff-reader/) that provided a link to a little know LAVA Code Repository (http://code.google.com/p/lavacr/source/browse/#svn/trunk/8.5.x/Machine%20Vision%20and%20Imaging/TIFF...).

This repository includes a TIFF reader written by Gavin Burnell and Herbert Looser that apparently does not use the libtiff or any of its successors.

After some minor modifications to their Load Flattened Image from Tiff.vi (see TIFF File Reader (LAVA.org).vi), I can now read my dropbox Tiff file in 74 ms. (My application loads up to several hundred large Tiff files for interactive viewing.)

I attach the updated library hoping that it will be useful to you guys and future readers of this discussion.

Thank you again so much for your help and wisdom.

Best regards,

Peter

[nathand]

Glad you got it working, and thanks for the link to the code.

I used as a test image for my code, the image you uploaded. It didn't occur to me to use an intensity graph for display though, as the code you uploaded does. When I drop an intensity graph on the front panel of my VI, and connect the image data to it, I get the image below. Just out of curiosity, is it correct (if perhaps rotated or upside down)? If so, my code does what you need. The code you posted is more comprehensive, although rather dated in the way it's written.

[pbuerki]

Hi nathand,

Glad you got it working. My image is grayscale, and it is rotated 90degrees counterclockwise compared to the image you posted. I paste the image in its required orientation:

 

I already have the rotation of the array implemented albeit slow. Did you benchmark your load time or can you send me your code, please so that I can test it here? Thank you so much.

Peter

[nathand]

It's exactly there code I already posted. You just need to select the file on the front panel path control before you run it. The only change is I added an intensity graph. I'm sure there's room for optimization, I didn't try.

[pbuerki]

Sorry I don't get it. On the risk of appearing stupid when I run your VIs I get an empty string out of the Parse TIFF.vi followed by an empty array out of the Convert to Values.vi. See attached. What am I doing wrong??

[nathand]

Convert to Values is a subVI used inside Parse TIFF; there's no reason to ever run it on its own.

Parse TIFF, as I uploaded it, isn't set up to be a subVI - none of the front panel terminals are connected. That's easy to fix, of course. However, in the zip you uploaded, those terminals still aren't connected, so the wires are broken. As a result, I'm not quite sure what you're doing, because I assume you have at least runnable code.

It sounds like maybe your test code is still referencing the earlier, incomplete version I uploaded? The correct version doesn't have any string output.

There's definitely room for optimization in my VI. It does more or less the same thing as the one you downloaded from LAVA, but only handles 16-bit grayscale images since that's what you uploaded as a sample. Also the LAVA code loads the entire file from memory and works from there, where mine loads from disk only the needed portions. I suspect that loading the entire file is slightly faster, it would be easy to make that change. I think my code could also be easily modified to handle the rotation, by swapping rows and columns and possibly by reversing each strip as it's read from disk, before it's inserted in the overall array.

[pbuerki]

Now we are in business. It was not clear to me that the second Parse TIFF.vi was different from the first one and that the Convert to Values.vi is a SubVI of Parse TIFF.vi.

(I had modified the first Parse TIFF.vi and had a running version of my test VI. I mistakenly zipped the original Parse TIFF.vi)

Now I can display the image in 58 ms. Thank you so much.

Peter