Tapio
Tapio

Reputation: 1642

Hidden Matlab TIFF brand?

I'm doing image processing on computed tomography projection images. The original image is a .tiff output by the CT-machine. I import it to Matlab, where I process it and save the output image using imwrite().

The software I'm using to reconstruct the CT-images afterwards is proprietary but supports reconstruction from any .tiff images as long as they follow a certain standard. Apparently Matlab does not follow this standard, as it seems to brand all the .tiff images it saves in some way. I can work around it by loading all the images with a third software and saving them again, which seems to erase the tag and allows reconstruction. This is tedious and time consuming as I would have to do it multiple times a day.

I tried loading both a 'normal' and a 'scrubbed' .tiff by using the Matlab Tiff -class. I went through all the fields in the struct manually and could not find any difference, although the other one will not load into the CT-program and the other is fine.

Is there a hidden way that Matlab somehow brands these images? Is it possible to scrub these images inside Matlab?

Upvotes: 2

Views: 217

Answers (1)

Rotem
Rotem

Reputation: 32084

I can't be absolutely sure, but it's very unlikely that Matlab adds a hidden brand.

According to tiff format standard, adding a hidden brand, to tif file, will not cause a tiff reader software to fail.

Refer to Private tags section:

Developers can apply for a block of "private tags" to enable them to include their own proprietary information inside a TIFF file without causing problems for file interchange. TIFF readers are required to ignore tags that they do not recognize, and a registered developer's private tags are guaranteed not to clash with anyone else's tags or with the standard set of tags defined in the specification...

It looks like the CT-images software you are using is not conform with the tiff standard.

It could be (but unlikely) that the software complies with an older revision of tiff (revision 5.0 instead of revision 6.0).

One reason for the failure might be, that Matalb creates very large strips, and doesn't follow the recommendation of 8K bytes.
Refer to https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf:

Use of a single strip is not recommended. Choose RowsPerStrip such that each strip is about 8K bytes, even if the data is not compressed, since it makes buffering simpler for readers. The “8K” value is fairly arbitrary, but seems to work well.

Check the following code (I have posted here):

%Simulate large image (to be saved as tiff later)
I = imread('peppers.png');
I = repmat(I, [4, 4]);

t = Tiff('I.tif', 'w');

width = size(I, 2);
height = size(I, 1);
rows_per_strip = 1; %Select 1 row per strip (assume image row is less then 8K bytes).

setTag(t, 'ImageLength', height)
setTag(t, 'ImageWidth', width)
setTag(t, 'Photometric', Tiff.Photometric.RGB)
setTag(t, 'BitsPerSample', 8)
setTag(t, 'SamplesPerPixel', 3)
setTag(t, 'RowsPerStrip', rows_per_strip)
setTag(t, 'PlanarConfiguration', Tiff.PlanarConfiguration.Chunky)
%setTag(t, 'Compression', Tiff.Compression.LZW)
setTag(t, 'Compression', Tiff.Compression.None) %Try without compression

n_strips = ceil(height / rows_per_strip); %Total number of strips.

h = waitbar(0, 'In process');

%Write the tiff image strip by strip (and advance the waitbar).
for i = 1:n_strips
    y0 = (i-1)*rows_per_strip + 1; %First row of current strip.
    y1 = min(y0 + rows_per_strip - 1, height); %Last row of current strip.
    writeEncodedStrip(t, i, I(y0:y1, :, :)) %Write strip rows y0 to y1.
    waitbar(i/n_strips, h); %Update waitbar.
    drawnow %Force GUI refresh.
end

close(t)
close(h)

There could be many other reasons for the failure, because tiff format is very complicated (especially from the reader side).

Upvotes: 3

Related Questions