Re: [gdal-dev] Reading a JP2 file - obj_decode() failed
I guess this is what you want: 132000 248000 Which I'm assuming means it's not tile. On 2020-08-09 15:46, Even Rouault wrote: On dimanche 9 août 2020 15:30:12 CEST Jonathan Moules wrote: > Hi Even, > > Ah, it's comma delimited. I tried spaces. > > Here's the response, with with light editing to get rid of duplicate > info (The bands are all the same). Nothing in the output with the string > "tile". Ah, sorry, I now see those debug traces aren't compiled in in release mode. OK, so download https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/samples/dump_jp2.py and run python dump_jp2.py FILENAME.jp2 | grep Tsiz -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading a JP2 file - obj_decode() failed
On dimanche 9 août 2020 15:30:12 CEST Jonathan Moules wrote: > Hi Even, > > Ah, it's comma delimited. I tried spaces. > > Here's the response, with with light editing to get rid of duplicate > info (The bands are all the same). Nothing in the output with the string > "tile". Ah, sorry, I now see those debug traces aren't compiled in in release mode. OK, so download https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/samples/dump_jp2.py and run python dump_jp2.py FILENAME.jp2 | grep Tsiz -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading a JP2 file - obj_decode() failed
Hi Even, Ah, it's comma delimited. I tried spaces. Here's the response, with with light editing to get rid of duplicate info (The bands are all the same). Nothing in the output with the string "tile". Cheers, Jonathan OPENJPEG: info: Start to read j2k main header (0). OPENJPEG: info: Main header has been correctly decoded. OPENJPEG: SRGB color space GDALJP2Metadata: Got projection from GeoJP2 (geotiff) box (0): PROJCS["British National Grid (ORD SURV GB)",GEOGCS["OSGB 1936",DATUM["OSGB_1936",SPHEROID["Airy1830",6377563.396,299.3249612664951,AUTHORITY["EPSG","7001"]],AUTHORITY["EPSG","6277"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4277"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",40],PARAMETER["false_northing",-10],UNIT["metre",1,AUTHORITY["EPSG","9001"]]] MDReaderPleiades: Not a Pleiades product MDReaderPleiades: Not a Pleiades product GDAL: GDALOpen(FILENAME.jp2, this=060407F0) succeeds as JP2OpenJPEG. Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library GDAL: GDALDefaultOverviews::OverviewScan() Files: FILENAME.jp2 FILENAME.jp2.aux.xml ... Metadata: GEOTIFF_CHAR__GeogAngularUnitsGeoKey=Angular_Degree GEOTIFF_CHAR__GeogEllipsoidGeoKey=Ellipse_Airy_1830 GEOTIFF_CHAR__GeogGeodeticDatumGeoKey=Datum_OSGB_1936 GEOTIFF_CHAR__GeographicTypeGeoKey=GCS_OSGB_1936 GEOTIFF_CHAR__GTModelTypeGeoKey=ModelTypeProjected GEOTIFF_CHAR__GTRasterTypeGeoKey=RasterPixelIsArea GEOTIFF_CHAR__ProjCoordTransGeoKey=CT_TransverseMercator GEOTIFF_CHAR__ProjectedCSTypeGeoKey=User-Defined GEOTIFF_CHAR__ProjectionGeoKey=User-Defined GEOTIFF_CHAR__ProjLinearUnitsGeoKey=Linear_Meter GEOTIFF_NUM__1024__GTModelTypeGeoKey=1 GEOTIFF_NUM__1025__GTRasterTypeGeoKey=1 GEOTIFF_NUM__1026__GTCitationGeoKey=British National Grid (ORD SURV GB) GEOTIFF_NUM__2048__GeographicTypeGeoKey=4277 GEOTIFF_NUM__2049__GeogCitationGeoKey=OSGB 1936 GEOTIFF_NUM__2050__GeogGeodeticDatumGeoKey=6277 GEOTIFF_NUM__2054__GeogAngularUnitsGeoKey=9102 GEOTIFF_NUM__2056__GeogEllipsoidGeoKey=7001 GEOTIFF_NUM__2057__GeogSemiMajorAxisGeoKey=6377563.396000 GEOTIFF_NUM__2059__GeogInvFlatteningGeoKey=299.324961 GEOTIFF_NUM__3072__ProjectedCSTypeGeoKey=32767 GEOTIFF_NUM__3074__ProjectionGeoKey=32767 GEOTIFF_NUM__3075__ProjCoordTransGeoKey=1 GEOTIFF_NUM__3076__ProjLinearUnitsGeoKey=9001 GEOTIFF_NUM__3080__ProjNatOriginLongGeoKey=-2.00 GEOTIFF_NUM__3081__ProjNatOriginLatGeoKey=49.00 GEOTIFF_NUM__3082__ProjFalseEastingGeoKey=40.00 GEOTIFF_NUM__3083__ProjFalseNorthingGeoKey=-10.00 GEOTIFF_NUM__3092__ProjScaleAtNatOriginGeoKey=0.999601 Image Structure Metadata: INTERLEAVE=PIXEL OGRCT: Source: +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40 +y_0= -10 +datum=OSGB36 +units=m +no_defs OGRCT: Target: +proj=longlat +datum=OSGB36 +no_defs Corner Coordinates: ... Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red Min=168.000 Max=255.000 Minimum=168.000, Maximum=255.000, Mean=243.359, StdDev=16.164 Overviews: 66000x124000, 33000x62000, 16500x31000, 8250x15500, 4125x7750, 2062 x3875, 1031x1937, 515x968, 257x484, 128x242, 64x121 Overviews: arbitrary Metadata: STATISTICS_APPROXIMATE=YES STATISTICS_MAXIMUM=255 STATISTICS_MEAN=243.35889029004 STATISTICS_MINIMUM=168 STATISTICS_STDDEV=16.164314681862 STATISTICS_VALID_PERCENT=100 Image Structure Metadata: COMPRESSION=JPEG2000 ... GDAL: GDALClose(FILENAME.jp2,this=060407F0) On 2020-08-09 15:21, Even Rouault wrote: On dimanche 9 août 2020 12:47:33 CEST Jonathan Moules wrote: > Hi Even, > Thanks for getting back to me. I'm a little rusty with GDAL; it has > probably been 5+ years since I last used it. > > I can confirm my QGIS install version (OSGEO4W) does have the JP2ECW > driver (`gdalinfo --formats`). > > I'm using the Python GDAL build from > https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal - doesn't say it > includes JP2ECW. I only have access to that GDAL build via Python but > haven't managed to figure out what the Python API equivalent of > "gdalinfo --formats" is (assuming there is one). > > I don't seem to be able to force JP2OpenJPEG on the OSGeo4W one. > gdalinfo --config GDAL_SKIP JP2ECW FILENAME.jp2 = uses the MrSID driver > gdalinfo --config GDAL_SKIP JP2ECW --config GDAL_SKIP JP2MrSID > FILENAME.jp2 = Goes back to JP2ECW If you specify several times a configuration option, the last value for a given key will override the previous one(s). You can skip several drivers by using comma as a separator. And I forgot a very important switch for what I had in mind, "--debug on" instead of my buggy --format So try: gdalinfo --config GDAL_SKIP JP2ECW,JP2MrSID --debug on FILENAME.jp2 > I can't help but notice the block size and overview levels are reporting >
Re: [gdal-dev] Reading a JP2 file - obj_decode() failed
On dimanche 9 août 2020 12:47:33 CEST Jonathan Moules wrote: > Hi Even, > Thanks for getting back to me. I'm a little rusty with GDAL; it has > probably been 5+ years since I last used it. > > I can confirm my QGIS install version (OSGEO4W) does have the JP2ECW > driver (`gdalinfo --formats`). > > I'm using the Python GDAL build from > https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal - doesn't say it > includes JP2ECW. I only have access to that GDAL build via Python but > haven't managed to figure out what the Python API equivalent of > "gdalinfo --formats" is (assuming there is one). > > I don't seem to be able to force JP2OpenJPEG on the OSGeo4W one. > gdalinfo --config GDAL_SKIP JP2ECW FILENAME.jp2 = uses the MrSID driver > gdalinfo --config GDAL_SKIP JP2ECW --config GDAL_SKIP JP2MrSID > FILENAME.jp2 = Goes back to JP2ECW If you specify several times a configuration option, the last value for a given key will override the previous one(s). You can skip several drivers by using comma as a separator. And I forgot a very important switch for what I had in mind, "--debug on" instead of my buggy --format So try: gdalinfo --config GDAL_SKIP JP2ECW,JP2MrSID --debug on FILENAME.jp2 > I can't help but notice the block size and overview levels are reporting > different info compared to the JP2ECW output Yes, the various JPEG2000 driver have different logic (or arbitrariness...) to decide the block size. For the JP2OpenJPEG driver, 1024x1024 is either because it is the JPEG2000 tile size or as an arbitrary block size for a single tiled image. The --debug on will output lower level info. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading a JP2 file - obj_decode() failed
Hi Even,
Thanks for getting back to me. I'm a little rusty with GDAL; it has
probably been 5+ years since I last used it.
I can confirm my QGIS install version (OSGEO4W) does have the JP2ECW
driver (`gdalinfo --formats`).
I'm using the Python GDAL build from
https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal - doesn't say it
includes JP2ECW. I only have access to that GDAL build via Python but
haven't managed to figure out what the Python API equivalent of
"gdalinfo --formats" is (assuming there is one).
I don't seem to be able to force JP2OpenJPEG on the OSGeo4W one.
gdalinfo --config GDAL_SKIP JP2ECW FILENAME.jp2 = uses the MrSID driver
gdalinfo --config GDAL_SKIP JP2ECW --config GDAL_SKIP JP2MrSID
FILENAME.jp2 = Goes back to JP2ECW
(Doesn't support the -if flag).
But I found `gdal.Info("FILENAME.jp2")` on the Python version, and that
does use the JP2 OpenJPEG driver. No tile information on there:
Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
...
Image Structure Metadata:
INTERLEAVE=PIXEL
...
Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
Overviews: 66000x124000, 33000x62000, 16500x31000, 8250x15500,
4125x7750, 2063x3875, 1032x1938, 516x969, 258x485, 129x243, 65x122
Overviews: arbitrary
Image Structure Metadata:
COMPRESSION=JPEG2000
...
I can't help but notice the block size and overview levels are reporting
different info compared to the JP2ECW output (ECW one has different
rounding <= 2062*3875):
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
Description = Red
Overviews: 66000x124000, 33000x62000, 16500x31000, 8250x15500,
4125x7750, 2062
x3875, 1031x1937, 515x968, 257x484
and JP2MrSID for comparison:
Band 1 Block=1024x128 Type=Byte, ColorInterp=Red
Min=168.000 Max=255.000
Minimum=168.000, Maximum=255.000, Mean=243.359, StdDev=16.164
Overviews: 66000x124000, 33000x62000, 16500x31000, 8250x15500,
4125x7750, 2063
x3875, 1032x1938, 516x969, 258x485, 129x243, 65x122, 33x61
Metadata:
STATISTICS_APPROXIMATE=YES
STATISTICS_MAXIMUM=255
STATISTICS_MEAN=243.35889029004
STATISTICS_MINIMUM=168
STATISTICS_STDDEV=16.164314681862
STATISTICS_VALID_PERCENT=100
All three report different Overview levels too. Odd but no idea if it is
pertinent to this problem.
Cheers,
Jonathan
p.s. I was looking for Python API docs but it seems there aren't any.
This page:
https://pypi.org/project/GDAL/#usage - has a link to
http://www.gdal.org/gdal_tutorial.html, but that's a 404. I think it
wants to be: https://gdal.org/tutorials/index.html
On 2020-08-09 11:14, Even Rouault wrote:
Jonathan,
The GDAL build that comes with rasterio must have only JP2OpenJPEG
enabled (the error with opj_decode() comes from that driver), whereas
the GDAL build in QGIS has also JP2ECW, which is used in priority.
The file is large. It would be interesting to know if it is tiled. If
you do "gdalinfo --format FILENAME.jp2 --config GDAL_SKIP JP2ECW", and
look at the beginning of the output, you should see lines like
OPENJPEG: nTileW =
OPENJPEG: nTileH =
which values are reported ?
If it is tiled (values <= 2048 let's say), this should normally work.
Openjpeg will have more difficulties with single-tile JPEG2000 files,
although latest versions (2.3.1) have seen improvements in that regard
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading a JP2 file - obj_decode() failed
Jonathan, The GDAL build that comes with rasterio must have only JP2OpenJPEG enabled (the error with opj_decode() comes from that driver), whereas the GDAL build in QGIS has also JP2ECW, which is used in priority. The file is large. It would be interesting to know if it is tiled. If you do "gdalinfo --format FILENAME.jp2 --config GDAL_SKIP JP2ECW", and look at the beginning of the output, you should see lines like OPENJPEG: nTileW = OPENJPEG: nTileH = which values are reported ? If it is tiled (values <= 2048 let's say), this should normally work. Openjpeg will have more difficulties with single-tile JPEG2000 files, although latest versions (2.3.1) have seen improvements in that regard Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
