[gdal-dev] NITF Int16 image size limit

Even Rouault even.rouault at spatialys.com
Wed Apr 7 01:23:47 PDT 2021


Hi,

Actually the error message doesn't look like there's a uint32 overflow 
as it displays a file offset that is beyond the 4 GB limit.

Did you check that your file size is at least 4324329780 + 4194302 = 4 
328 524 082 bytes ? I guess it is not, or then there's some mysterious 
error in the low level GDAL I/O layer.

So if your file is smaller than that,

- either it is corrupted (would be good if you could check that with a 
non-GDAL implementation)

- or there's a bug in the NITF driver in how it computes offsets. Could 
you report the values of the NITF_ABPP, NITF_IC and NITF_IMODE metadata 
reported by gdalinfo ?

Even

Le 07/04/2021 à 02:09, ni hao a écrit :
> gdalinfo output i:
> Driver: NITF/National Imagery Transmission Format
> Files: ##CH_CV_GRD\imagery\12499.ntf
> Size is 61180, 19694
> Coordinate System is `'
> GCP Projection =
> GEOGCS["WGS 84",   ... ]
> Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Gray
> Band 2 Block=1024x1024 Type=UInt16, ColorInterp=Gray
>
> Also I am sure it is the UInt16 overflow, as the message is:
> ERROR 3: Unable to read 4194302 byte block from 4324329780
> and 2**32 = 4294967296
>
> ------------------------------------------------------------------------
> *From:* bradh at frogmouth.net <bradh at frogmouth.net>
> *Sent:* April 6, 2021 8:17 PM
> *To:* Even Rouault <even.rouault at spatialys.com>; ni hao 
> <ni_hao88 at hotmail.com>
> *Cc:* gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
> *Subject:* Re: [gdal-dev] NITF Int16 image size limit
> Also if you can show the headers (e.g. from gdalinfo), that might 
> provide indication of exactly which value is the issue.
>
> Brad
>
> On 7 Apr. 2021 04:00, Even Rouault <even.rouault at spatialys.com> wrote:
>
>     Please keep the mailing list copied (I re-added it)
>
>     This is not the most recent one (3.2.2 is), but skimming quickly
>     through release notes, I can't see anything directly related, so
>     it might still be current with the recent versions. Altough I see
>     that a bunch of "avoid unsigned integer overflow" type of fixes
>     have been done since 2.4, so some of them might have accidentally
>     fixed the issue.
>
>     If you can try with the latest version ( Docker images mentioned
>     at https://github.com/OSGeo/gdal/tree/master/gdal/docker
>     <https://github.com/OSGeo/gdal/tree/master/gdal/docker>, Conda,
>     etc .), that could be interesting.
>
>
>     Le 06/04/2021 à 19:51, ni hao a écrit :
>
>         Hi Even,
>
>         The version is 2.4.4.
>         ------------------------------------------------------------------------
>         *From:* Even Rouault <even.rouault at spatialys.com>
>         <mailto:even.rouault at spatialys.com>
>         *Sent:* April 6, 2021 2:46 PM
>         *To:* ni hao <ni_hao88 at hotmail.com>
>         <mailto:ni_hao88 at hotmail.com>; gdal-dev at lists.osgeo.org
>         <mailto:gdal-dev at lists.osgeo.org> <gdal-dev at lists.osgeo.org>
>         <mailto:gdal-dev at lists.osgeo.org>
>         *Subject:* Re: [gdal-dev] NITF Int16 image size limit
>
>         Shawn,
>
>         This sounds more like a unwanted integer overflow somewhere in
>         the NITF driver.  Is this with a recent GDAL ? If so, please
>         file a bug at https://github.com/OSGeo/gdal/issues/new
>         <https://github.com/OSGeo/gdal/issues/new> with all the
>         details needed. A link to the dataset would be ideal, but
>         otherwise please provide in the ticket description the output
>         of "gdalinfo your.nitf"
>
>         Even
>
>         Le 06/04/2021 à 19:35, ni hao a écrit :
>
>             Hi list,
>
>
>             I encountered problem ingesting a large NITF Int16 image
>             with GDAL:
>
>             NITF 2-band image in Int16 format, 4.3 GB. It has 19690
>             lines x 61180 pixels.   The upper 90% of the image looks
>             fine.   But the last 2000 lines fail to load by GDAL. 
>              That coincides with the 32-bit boundary.
>
>
>             Note that another larger NITF in 32-bit float, 10.1 GB
>             file loads fine.
>
>
>             Is there a hard limit on NITF Int16 file size?
>
>             Thanks,
>             Shawn
>
>
>             _______________________________________________
>             gdal-dev mailing list
>             gdal-dev at lists.osgeo.org  <mailto:gdal-dev at lists.osgeo.org>
>             https://lists.osgeo.org/mailman/listinfo/gdal-dev  <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>
>         -- 
>         http://www.spatialys.com  <http://www.spatialys.com>
>         My software is free, but my time generally not.
>
>     -- 
>     http://www.spatialys.com  <http://www.spatialys.com>
>     My software is free, but my time generally not.
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210407/6384b48a/attachment.html>


More information about the gdal-dev mailing list