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

Manuel Grizonnet manuel.grizonnet at cnes.fr
Thu Jul 27 08:52:41 EDT 2017


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> 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>
>      >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/>
>      >
>      >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
>      
>      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
>      http://public.kitware.com/mailman/listinfo/community
>      
>
> _______________________________________________
> 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

-- 
Manuel GRIZONNET

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20170727/84240233/attachment.html>


More information about the Insight-developers mailing list