<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi all,</p>
<p>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. <br>
</p>
<p>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]:</p>
<p><i>"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."</i></p>
<p>So we do have to handle images with negative spacing in OTB...<br>
</p>
<p>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:</p>
<p><a moz-do-not-send="true"
href="https://issues.itk.org/jira/browse/ITK-3314">https://issues.itk.org/jira/browse/ITK-3314</a><br>
</p>
<p>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.</p>
Regards,<br>
<p>Manuel<br>
</p>
<p><a href="http://geotiff.maptools.org/spec/geotiff2.6.html">[1]
http://geotiff.maptools.org/spec/geotiff2.6.html</a></p>
<br>
<div class="moz-cite-prefix">Le 21/07/2017 à 19:31, Lowekamp,
Bradley (NIH/NLM/LHC) [C] a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:00E5A302-4AB2-4614-BBD6-42704179687E@mail.nih.gov">
<pre wrap="">Sean,
The other patch related to this change is the following:
<a class="moz-txt-link-freetext" href="https://github.com/InsightSoftwareConsortium/ITK/commit/d447f0452bb5ea92a555e630d05b57da535bd3a9">https://github.com/InsightSoftwareConsortium/ITK/commit/d447f0452bb5ea92a555e630d05b57da535bd3a9</a>
ENH: Explicitly warn and deprecate negative pixel spacing.
The DICOM standard explicitly disallows negative pixel spacing:
<a class="moz-txt-link-freetext" href="http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_10.7.html#sect_10.7.1.3">http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_10.7.html#sect_10.7.1.3</a>
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?
</pre>
<blockquote type="cite">
<pre wrap="">What do you think about adding an API so that it can be known if/which axes were flipped?
</pre>
</blockquote>
<pre wrap="">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" <a class="moz-txt-link-rfc2396E" href="mailto:sean@rogue-research.com"><sean@rogue-research.com></a> wrote:
On Fri, 2 Jun 2017 16:18:37 -0400, Sean McBride said:
>7501479a970694b0dd4a8c4bbf7cbcc033fe059c is the first bad commit
>commit 7501479a970694b0dd4a8c4bbf7cbcc033fe059c
>Author: Francois Budin <a class="moz-txt-link-rfc2396E" href="mailto:francois.budin@gmail.com"><francois.budin@gmail.com></a>
>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:
><a class="moz-txt-link-rfc2396E" href="http://review.source.kitware.com/#/c/21685/"><http://review.source.kitware.com/#/c/21685/></a>
>
>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 <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>
Visit other Kitware open-source projects at
<a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>
Kitware offers ITK Training Courses, for more information visit:
<a class="moz-txt-link-freetext" href="http://kitware.com/products/protraining.php">http://kitware.com/products/protraining.php</a>
Please keep messages on-topic and check the ITK FAQ at:
<a class="moz-txt-link-freetext" href="http://www.itk.org/Wiki/ITK_FAQ">http://www.itk.org/Wiki/ITK_FAQ</a>
Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://public.kitware.com/mailman/listinfo/insight-developers">http://public.kitware.com/mailman/listinfo/insight-developers</a>
_______________________________________________
Community mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Community@itk.org">Community@itk.org</a>
<a class="moz-txt-link-freetext" href="http://public.kitware.com/mailman/listinfo/community">http://public.kitware.com/mailman/listinfo/community</a>
_______________________________________________
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>
Visit other Kitware open-source projects at
<a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>
Kitware offers ITK Training Courses, for more information visit:
<a class="moz-txt-link-freetext" href="http://kitware.com/products/protraining.php">http://kitware.com/products/protraining.php</a>
Please keep messages on-topic and check the ITK FAQ at:
<a class="moz-txt-link-freetext" href="http://www.itk.org/Wiki/ITK_FAQ">http://www.itk.org/Wiki/ITK_FAQ</a>
Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://public.kitware.com/mailman/listinfo/insight-developers">http://public.kitware.com/mailman/listinfo/insight-developers</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Manuel GRIZONNET
</pre>
</body>
</html>