Extracting TIFF image data with 2 StripOffsets in a single IFD

16 Ansichten (letzte 30 Tage)
Allen Kelly
Allen Kelly am 13 Mär. 2012
Hi All. I'll get my excuses in before I start by saying im very much a novice so there's probably a very easy solution to this.
I'm trying to extract image data from a modified TIFF file (extension .lsm) associated with Zeiss confocal microscopes. The problem i'm having is that each file contains at least 2 images captured with different PMTs, but the images for each wavelength are stored in a single IFD with different byte offsets referring to the two images.
imfinfo shows a 2x1 struct, with the 2nd struct containing information for a thumbnail image which is displayed in the Zeiss image browsing software, the 1st struct has the information for the images i wish to extract:
Filename: 'C:\Temp\07.lsm'
FileModDate: '02-Mar-2012 16:07:12'
FileSize: 6444950
Format: 'tif'
FormatVersion: []
Width: 512
Height: 4000
BitDepth: 40
ColorType: 'truecolor'
FormatSignature: [73 73 42 0]
ByteOrder: 'little-endian'
NewSubFileType: 0
BitsPerSample: [16 16 8]
Compression: 'LZW'
PhotometricInterpretation: 'RGB'
StripOffsets: [77657;3298371]
SamplesPerPixel: 2
RowsPerStrip: 4.2950e+009
StripByteCounts: []
XResolution: []
YResolution: []
ResolutionUnit: 'None'
Colormap: []
PlanarConfiguration: 'Planar'
TileWidth: []
TileLength: []
TileOffsets: []
TileByteCounts: []
Orientation: 1
FillOrder: 1
GrayResponseUnit: 0.0100
MaxSampleValue: [65535 65535 255]
MinSampleValue: 0
Thresholding: 1
Offset: 8
Predictor: 'Horizontal differencing'
UnknownTags: [1x1 struct]
How should I access the image at the 2nd StripOffset? imread is unable to do it, and another script I found on the file exchange, Tiffread, which is designed specifically for .lsm files (among others) will read frame scan images generated by the microscope, but not line scans like the file above. I should also say that I have tried using the LibTIFF commands to access the individual strips, and it works for frame scan images (X*Y), but not line scan images (X*time) i.e:
t=Tiff(fname,'r');
im1 = t.readEncodedStrip(1);
im2 = t.readEncodedStrip(2);
will output 2 images but they are exactly identical, and I know that not to be the case, so it's either not reading the 2nd offset, or (more likely) im just not doing it right
Any suggestions for this would be really helpful
Thanks,
Allen K

Antworten (2)

John
John am 14 Mär. 2012
Hi Allen, both the Tiff class and IMREAD use libtiff under the hood, but libtiff does not support multiple values for the BitsPerSample tag, so unfortunately neither of these will be of help to you.

Allen Kelly
Allen Kelly am 16 Mär. 2012
Ah I see, thanks John.
I've been trying to use fread to read the data out of the file using the byte offsets specified in the StripOffsets tag, but i'm not sure I understand how the 2 images are arranged
According to the Tiff specification, with the PlanarConfiguration tag set to 2 (i.e. 'Planar') "the values in StripOffsets and StripByteCounts are arranged as a 2D array, with SamplesPerPixel rows and Strips per image columns. All of the columns for row 0 are stored first, followed by columns for row 1 etc..."
This seems to be all the information I should need to actually 'read' the data from the file but i'm not sure I understand this arrangement
Any help at all with this would be great
Thanks in advance
Allen K
  1 Kommentar
John
John am 16 Mär. 2012
Ah, I did not see that the planar configuration was set to planar. That would, however, only set you up for the next problem waiting in line :-)
When TIFFs become problematic, a last-resort option can be to use FOPEN, FSEEK, and FREAD along with the values of the StripByteCount and StripOffsets tags. However, as I look more closely at the output of your info struct, I see that the photometric interpretation is RGB. If that really is the case, then RGB with a planar configuration means you need at least 3 strips to store each of the R, G, and B planes, and you've only got two. You may be able to read the raw data using FREAD, but I don't know how it could be interpreted under these circumstances.
Plus the data would be LZW-compressed, which you'd have to somehow handle.

Melden Sie sich an, um zu kommentieren.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by