Trying to get the histogram from a sample NITF. Running from the command line, gdalinfo -hist, I get this...
Band 1 Block=512x512 Type=Byte, ColorInterp=Undefined 0ERROR 1: COMRAT=4.50 ARIDPCM is not supported. Currently only 0.75 is supported. ERROR 1: U_0001A.NTF, band 1: IReadBlock failed at X offset 0, Y offset 0 In Java code (Gdal 2.1 from Maven against a Windows Gdal installation), this line... int status = band.GetDefaultHistogram(dfMin, dfMax, panHistogram, true); causes a dump... # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000078f7c1b0, pid=2240, tid=3296 # # JRE version: Java(TM) SE Runtime Environment (8.0_71-b15) (build 1.8.0_71-b15) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.71-b15 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [msvcr100.dll+0x3c1b0]ERROR 1: COMRAT=4.50 ARIDPCM is not supported. Currently only 0.75 is supported. ERROR 1: B:\data\raster\NITF\U_0001A.NTF, band 1: IReadBlock failed at X offset 0, Y offset 0 # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows With exceptions enabled, I get the same thing without the ERROR string and no exception is caught. Culprit file is http://download.osgeo.org/gdal/data/nitf/nitf1.1/U_0001a.ntf So, I can't check the status return from GetDefaultHistogram, I can't catch an exception, and I think ARIDPCM is valid for NITF prior to 2.1, so I can't really exclude ARIDPCM compression. Workarounds or bug? -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Gdal-Java-GetDefaultHistogram-causing-core-dump-tp5307438.html Sent from the GDAL - Dev mailing list archive at Nabble.com. _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
