<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p>I have tried to use GDAL 2.2 in OTB. I have some issues with
output images in the ENVI format. Some of the images I use have :</p>
<ul>
<li>A geotransform with an origin, for instance : geotransform =
{10, 1, 0, 10, 0, 1} </li>
<li>No map projection (the image comes from a sensor image, or may
come from a plain jpg file).<br>
</li>
</ul>
As you can see, the 2x2 linear part of the geotransform is an
identity matrix. When I write such an image using the ENVI format, I
get a 90° rotation :<br>
map info = {Arbitrary, 1, 1, 10, 10, 1, 1, 0, North,
rotation=90}<br>
<br>
Does ENVI support negative values for "Pixel Y size", in order to
handle this Y-flipping ?<br>
<br>
Regards,<br>
Guillaume Pasero<br>
<br>
<div class="moz-cite-prefix">On 03/01/2017 04:03 PM, Kurt Schwehr
wrote:<br>
</div>
<blockquote
cite="mid:CACmBxyvPHvjVRtC7S4-_dKQYDW9gAeg5z8i6OGirTYXevqkE8w@mail.gmail.com"
type="cite">
<div dir="ltr">Even,
<div><br>
</div>
<div>I already do direct tests with jp2kakdataset_test.cc with
bazel and it works great. I can directly probe the methods
without worrying about any other mechanism getting between the
test and the class. e.g. I can directly mess with Identify,
Open and any helpers. I can also do things like disable
identify so that fuzzing can more quickly get into the guts
and find trouble: </div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/jp2kak/jp2kakdataset.cpp#L812">https://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/jp2kak/jp2kakdataset.cpp#L812</a><br>
</div>
<div><br>
</div>
<div>
<div>GDALDataset *JP2KAKDataset::Open( GDALOpenInfo *
poOpenInfo ) {</div>
<div>#ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION</div>
<div> // During fuzzing, do not use Identify to reject
crazy content.</div>
<div> if( !Identify(poOpenInfo) )</div>
<div> return NULL;</div>
<div>#endif</div>
</div>
<div><br>
</div>
<div>We are putting resources behind this... we are running
fuzzing on jp2kak and related. e.g. with >600K core hours
of fuzzing this month (> 14e12 iterations).</div>
<div><br>
</div>
<div>If I don't break things apart, fuzzing a component goes
much slower and is far less likely to identify issues in the
lower level components and libs.</div>
<div><br>
</div>
</div>
</blockquote>
<div class="moz-signature"><br>
</div>
</body>
</html>