# Differences between using component ITKImageIO and explicitly setting ITKIOTIFF
**URL:** https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697
**Category:** Engineering
**Tags:** io, bug
**Created:** [February 21, 2018, 7:29pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697 "2018-02-21T19:29:09Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@phcerdan](https://discourse.itk.org/u/phcerdan)
#### Post date: [February 21, 2018, 7:29pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697/1 "2018-02-21T19:29:09Z")
I have found an odd behavior, but only tested in my local computer.
If I use any automatic IO detection [(pre 4.13 approach, or newer/cleaner ITKImageIO)](https://discourse.itk.org/t/find-all-available-modules-from-groupio/351/6) and try to read a 3D **.tiff** image, for example, 64x64x16, I get a 64x64x1 image from the reader.
However if I explicitly use ITKIOTIFF, it works as expected.
Here is the minimal working example to test/reproduce it: [https://github.com/phcerdan/bug\_itkimageio](https://github.com/phcerdan/bug_itkimageio).
test it using `ctest -V` and see differences changing the cmake option `USE_ITKIMAGEIO`:
```auto
if (USE_ITKIMAGEIO) # All available IO
set(use_itk_modules
ITKImageIO
)
else (USE_ITKIMAGEIO) # Only a few IO
set(use_itk_modules
ITKIOImageBase
ITKIOTIFF
)
endif (USE_ITKIMAGEIO)
find_package(ITK COMPONENTS ${use_itk_modules} REQUIRED)
include(${ITK_USE_FILE})
```
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [February 21, 2018, 7:38pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697/2 "2018-02-21T19:38:30Z")
Maybe another ImageIO, that can also read a TIFF file, reads the file before `itk::TIFFImageIO` gets a chance.
After calling `->Update()` on the `reader`, what does printing `reader->GetImageIO()` return?
---
### Author:  [@phcerdan](https://discourse.itk.org/u/phcerdan)
#### Post date: [February 21, 2018, 7:49pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697/3 "2018-02-21T19:49:15Z")
Good point, that’s exactly what happening, it is SCIFIOImageIO.
```auto
reader->GetImageIO()->Print( std::cout );
```
I get:
```auto
SCIFIOImageIO (0x55fb3dd814e0)
RTTI typeinfo: itk::SCIFIOImageIO
Reference Count: 1
Modified Time: 228
Debug: Off
Object Name:
Observers:
none
AbortGenerateData: Off
Progress: 0
FileName: /path/to/itk_bug_io/src/collagen_64x64x16.tiff
FileType: Binary
ByteOrder: BigEndian
IORegion:
ImageIORegion (0x55fb3dd81578)
Dimension: 3
Index: 0 0 0
Size: 64 64 1
Number of Components/Pixel: 1
Pixel Type: scalar
Component Type: unsigned_short
Dimensions: ( 64 64 1 16 )
Origin: ( 0 0 0 0 )
UseCompression: Off
UseStreamedReading: On
UseStreamedWriting: Off
ExpandRGBPalette: On
IsReadAsScalarPlusPalette: False
ImageSize:[64, 64, 1]
Expected:[64, 64, 16]
Error, different sizes [64, 64, 1]!= expected: [64, 64, 16]
```
Is there a way to give preference to ITKIOTIFF?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [February 21, 2018, 8:21pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697/4 "2018-02-21T20:21:53Z")
One option is to [call `SetImageIO` on the reader](https://itk.org/ITKExamples/src/IO/TIFF/WriteATIFFImage/Documentation.html). But, it means other IO formats will not be supported.
You could also try calling [`itk::TIFFImageIOFactory::RegisterOneFactory()` at the start of the program](https://itk.org/ITKExamples/src/IO/ImageBase/RegisterIOFactories/Documentation.html). This may put TIFF higher in the factory list, but that assumption needs to be tested. We do not yet have a good way to explicitly specify the factory preferences.
In the end, it may be best create a `itk::TIFFImageIO`, call `CanReadFile()` on it, then set it as the ImageIO for the `itk::ImageFileReader` if it can read the file.
Other option is to fix the SCIFIO reader 😉 .
---
### Author:  [@phcerdan](https://discourse.itk.org/u/phcerdan)
#### Post date: [February 22, 2018, 12:28pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697/5 "2018-02-22T12:28:38Z")
Thanks @matt.mccormick, I would go for your last suggestion.
Fixing it will be way better of course, but maybe it’s not even a bug but a failure in converting the image from the microscopy format to tiff.
The bioformat reader is reading the image as a 4D:
In itk: `Dimensions: ( 64 64 1 16 )`.
In OME Metadata (from imageJ bioformats plugins):
```xml
```
So maybe it is just a metadata conversion error…
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [February 22, 2018, 6:38pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697/6 "2018-02-22T18:38:05Z")
@ctrueden Any thoughts on whether we are handling the dimensions correctly?
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [February 22, 2018, 7:53pm UTC](https://discourse.itk.org/t/differences-between-using-component-itkimageio-and-explicitly-setting-itkiotiff/697/7 "2018-02-22T19:53:58Z")
This is tangentially related. The ImageFileReader by default just produced the first “slice” of a higher dimension volume. Part of this behavior is dictated by this section of code in the ImageFilterReader:
>
I believe an important motivation for this behavior is that a DICOM slice is reported as (X,Y,1), and this behavior enables it to be loaded into a 2D image.
There is no automatic middle dimension squishing for ITK.
I recently enabled SCIFIO for SimpleITK and the if I recall correctly a basic 2D image was reported as (X,Y,1,1) for it’s size and refused to load. I should try it with the new 4D feature in SimpleITK though.