[ITK] [ITK-dev] Probelms with recent "Image spacing must be positive" change...

Thu Jul 27 09:18:56 EDT 2017

Hello Manuel,

Thank you for sharing your use case!

With the recent change to the ImageFileReader below when an ImageIO reports negative space, it is applied to the Direction cosine matrix so that the physical location of the pixel remains the same. I believe reading and processing images in ITK should work properly for your applications after the negative spacing is applied to the Direction cosine matrix.

However, logic may need to be added to writing images with file formats that don’t support the direction cosine matrix but do support negative spacing.

Have you encountered any specific problems with these changes?

Thanks,
Brad

From: Manuel Grizonnet <manuel.grizonnet at cnes.fr>
Date: Thursday, July 27, 2017 at 9:03 AM
To: "insight-developers at itk.org" <insight-developers at itk.org>
Cc: "otb-developers at googlegroups.com" <otb-developers at googlegroups.com>
Subject: Re: [ITK-dev] [ITK] Probelms with recent "Image spacing must be positive" change...

Hi all,

I'm part of the remote sensing library orfeo toolbox  team which used (a lot) ITK internally.  Following this discussion, I would like to add that in case of OTB, the strict sign checking of image spacing will have probably major impact for us as we're used to deal with images with negative spacing.

An example of remote sensing images with negative spacing is the well known Geotiff format (TIFF file with embedded georeferencing information). You can find in the geotiff specification [1]:

"simple reversals of orientation between raster and model space (e.g. horizontal or vertical flips) may be indicated by reversal of sign in the corresponding component of the ModelPixelScaleTag. GeoTIFF compliant readers must honor this sign-reversal convention."

So we do have to handle images   with negative spacing in OTB...

We also understand the point in ITK as we've also already faced issue with filters that assume positive spacing. See for instance this issue and discussion with Matt on JIRA:

https://issues.itk.org/jira/browse/ITK-3314

I don't have yet a clear idea on how to handle this properly but wanted to join the discussion. I've added otb-dev mailing list developer to the discussion as there are probably other otb developers interested by the discussion.
Regards,

Manuel

[1] http://geotiff.maptools.org/spec/geotiff2.6.html<http://geotiff.maptools.org/spec/geotiff2.6.html>

Le 21/07/2017 à 19:31, Lowekamp, Bradley (NIH/NLM/LHC) [C] a écrit :

Sean,

The other patch related to this change is the following:

https://github.com/InsightSoftwareConsortium/ITK/commit/d447f0452bb5ea92a555e630d05b57da535bd3a9

ENH: Explicitly warn and deprecate negative pixel spacing.

The DICOM standard explicitly disallows negative pixel spacing:

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_10.7.html#sect_10.7.1.3

Additionally, it is fundamentally unnatural to have negative space or

"size" of an object. The negative is a directional information which

should be contained in the direction cosine matrix not the spacing

attribute.

Change-Id: I1519faee14f48d2eecc08e100562f820eb6aa6ef

Are you proposing a flag in the  ImageFileReader class? What bout the Series reader? Will it be placed in the MetaData dictionary?

What do you think about adding an API so that it can be known if/which axes were flipped?

The wording is going to tricky. Some file formats native coordinates are LPS ( ITK ) while others are RAS, so there may be some “flipping” already done during reading in ImageIO classes.

As the ImageFileReader is doing the conversion and not the ImageIO, would it suffices to just query ImageIO::GetSpacing to see if it’s changed?

Brad

On 7/21/17, 12:35 PM, "Sean McBride" <sean at rogue-research.com><mailto:sean at rogue-research.com> wrote:

    On Fri, 2 Jun 2017 16:18:37 -0400, Sean McBride said:

    >7501479a970694b0dd4a8c4bbf7cbcc033fe059c is the first bad commit

    >commit 7501479a970694b0dd4a8c4bbf7cbcc033fe059c

    >Author: Francois Budin <francois.budin at gmail.com><mailto:francois.budin at gmail.com>

    >Date:   Mon Oct 31 17:04:05 2016 -0400

    >

    >    ENH: Image spacing must be positive

    >

    >    Image spacing must have values greater than 0. Negative

    >    values could create issues with filters that assume that they

    >    are positive.

    >    When an image is loaded, if its spacing is negative, its absolute

    >    value is kept, and the image direction along each axis with a

    >    negative spacing is flipped.

    >

    >    Change-Id: Id81d61b7fd3f60df2b38e30e540664dba6264996

    >

    >Which is here:

    ><http://review.source.kitware.com/#/c/21685/><http://review.source.kitware.com/#/c/21685/>

    >

    >Looks like this shipped in 4.11 (we are using 4.10.1).

    >

    >Our test case is an Analyze 7.5 file with negative spacing.  I'll dig

    >into it next week...

    François, Matt,

    So this change is causing us backwards-compatibility problems.

    What do you think about adding an API so that it can be known if/which axes were flipped?  As it is now, the flipping newly performed by ITK cannot be detected.  If such a change is acceptable, I can make a patch...

    (Our app used to warn users that files with negative spacing are problematic, but now we have no means to generate this warning, unless I'm missing something.)

    Thanks,

    Sean

    _______________________________________________

    Powered by www.kitware.com<http://www.kitware.com>

    Visit other Kitware open-source projects at

    http://www.kitware.com/opensource/opensource.html

    Kitware offers ITK Training Courses, for more information visit:

    http://kitware.com/products/protraining.php

    Please keep messages on-topic and check the ITK FAQ at:

    http://www.itk.org/Wiki/ITK_FAQ

    Follow this link to subscribe/unsubscribe:

    http://public.kitware.com/mailman/listinfo/insight-developers

    _______________________________________________

    Community mailing list

    Community at itk.org<mailto:Community at itk.org>

    http://public.kitware.com/mailman/listinfo/community

_______________________________________________

Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at

http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:

http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:

http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:

http://public.kitware.com/mailman/listinfo/insight-developers

--

Manuel GRIZONNET

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20170727/89116c23/attachment-0001.html>
-------------- next part --------------
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers