Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDALRasterSource will read corrupt jp2 successfully #3547

Open
bossie opened this issue Aug 14, 2024 · 4 comments
Open

GDALRasterSource will read corrupt jp2 successfully #3547

bossie opened this issue Aug 14, 2024 · 4 comments
Labels
question Further information is requested

Comments

@bossie
Copy link

bossie commented Aug 14, 2024

Describe the bug

I can create a GDALRasterSource from a corrupt JPEG2000 file and successfully read from it. I would expect it to throw an exception instead of silently proceeding with wrong data.

To Reproduce

import geotrellis.raster.gdal.GDALRasterSource
import geotrellis.raster.io.geotiff.MultibandGeoTiff

val rs = GDALRasterSource("https://artifactory.vgt.vito.be/artifactory/testdata-public/T29UMV_20180327T114351_B04_10m.jp2")
val Some(raster) = rs.read()
MultibandGeoTiff(raster, rs.crs).write("/tmp/rasterSourceFromCorruptTile.tif")

This will successfully read a corrupt JPEG2000 file and write it to a GeoTiff that looks funky. GDAL will output erorr messages along the way look like this:

[1 of 1000] FAILURE(3) CPLE_AppDefined(1) "Application defined error." Inconsistent marker size
[2 of 1000] FAILURE(3) CPLE_AppDefined(1) "Application defined error." opj_get_decoded_tile() failed 

Expected behavior

I would expect it to throw an exception instead of silently proceeding with wrong data. gdalinfo for example, will output error messages instead:

$ gdalinfo -stats https://artifactory.vgt.vito.be/artifactory/testdata-public/T29UMV_20180327T114351_B04_10m.jp2
...
ERROR 1: Stream too short, expected SOT

ERROR 1: opj_get_decoded_tile() failed
ERROR 1: /vsimem/http_1/T29UMV_20180327T114351_B04_10m.jp2, band 1: IReadBlock failed at X offset 5, Y offset 8: opj_get_decoded_tile() failed

Environment

  • Java version: 11
  • Scala version: 2.12.18
  • GeoTrellis version: 3.6.0
  • gdal-warp-bindings version: 3.8.0
@pomadchin pomadchin added the bug label Aug 14, 2024
@pomadchin
Copy link
Member

pomadchin commented Aug 14, 2024

Hey @bossie thx for reporting! Are u sure that's the GeoTrellis issue and not the underlying bindings? Have u tried to reproduce it via the bare bindings code?

@pomadchin
Copy link
Member

I wonder if smth could be swallowed on the bindings lvl.

@bossie
Copy link
Author

bossie commented Aug 15, 2024

Hi @pomadchin. Thanks for the quick response.

Hey @bossie thx for reporting! Are u sure that's the GeoTrellis issue and not the underlying bindings? Have u tried to reproduce it via the bare bindings code?

I have not so it's entirely possible that it's within the bindings code but I'm not familiar with that.

What I initially tried was significantly lowering geotrellis.raster.gdal.number-of-attempts because that seemed to make it fail but:

  • it doesn't always so it's unreliable;
  • it also makes perfectly good files fail 😄

So I guess that's unrelated and I'm on the wrong track here.

@pomadchin
Copy link
Member

Oooh interesting. Yest, that's definitely the bindings thing: https://github.com/geotrellis/gdal-warp-bindings/blob/v3.9.0/src/com_azavea_gdal_GDALWarp.c

That's been a way to fight with the not nicely fited for the JVM parallelism GDAL Datasets access.

Check the completely opposite scenarios:

@pomadchin pomadchin added question Further information is requested and removed bug labels Aug 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants