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.grizon...@cnes.fr>
Date: Thursday, July 27, 2017 at 9:03 AM
To: "insight-developers@itk.org" <insight-developers@itk.org>
Cc: "otb-develop...@googlegroups.com" <otb-develop...@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" 
<s...@rogue-research.com><mailto:s...@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.bu...@gmail.com><mailto:francois.bu...@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

    commun...@itk.org<mailto:commun...@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


_______________________________________________
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

Reply via email to