TiffImageIO z spacing

[zivy]

When writing a 3D image to file using TiffImageIO, the z spacing is lost (set to 1).

This is related to SimpleITK/SimpleITK#586

[blowekamp]

I wonder if the OpenSlide ImageIO would be any better? #139

[zivy]

Not sure about OpenSlide, they had a discussion about supporting 3D about three years ago (openslide/openslide#166) and the project isn't too active, at least on github (https://github.com/openslide/openslide/graphs/code-frequency).

[nslay]

This also happens when writing individual DICOM slices/files from a 3D DICOM volume (it clobbers the SpacingBetweenSlices tag "0018|0088" with value 1.0, even if it was there before and not 1.0). My workaround (rather tedious) is to promote the 2D image slice to a 3D volume with a singleton z dimension and extracting/setting the spacing, direction cosines and origin... and then saving the 3D slice to a DICOM file.

[nslay]

P.S. openslide, to my knowledge, does not support writing slides/tiffs. If it did, ITKIOOpenSlide would have supported that ability.

[maekclena]

There is no standard way of storing a Z spacing in TIFF but the format allows private tags. For example, MIPAV handles ZResolution and GeoTIFF defines ModelPixelScaleTag.

For DICOM slices, here's an example to preserve metadata:

itk::GDCMImageIO::Pointer gdcmIO = itk::GDCMImageIO::New();
ReaderType::DictionaryRawPointer dict = (*(reader->GetMetaDataDictionaryArray()))[sliceNumber];
gdcmIO->SetMetaDataDictionary(*dict);
writer->SetImageIO(gdcmIO);
writer->UseInputMetaDataDictionaryOff();
writer->SetInput(slice2D);
writer->Update();

[maekclena]

Some more informations: VTK uses Zeiss 3D TIFF and MeVisLab uses SGI 3D TIFF.

[blowekamp]

There are also a couple ImageJ TIFF private tags which can contain 3D information: https://github.com/imagej/ImageJA/blob/master/src/main/java/ij/io/TiffDecoder.java#L43-L44

I can't seem to find a specification for them right now.

[blowekamp]

More info about these tags in this ITK discourse thread:
https://discourse.itk.org/t/unknown-tags-reading-tiff/1719/2

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.