0

I have hundreds of USGS NAIP imagery GeoTIFFs that are in JP2 format, EPSG:3857.

I am using QGIS 3.16 to convert them to GeoTIFFs ("Rendered Images") as EPSG:4326, but I can only process one image at a time from within the GUI which is very, very tedious...

I can't use the GDAL_TRANSLATE command line option as when I originally built GDAL quite some time ago, I did not foresee using JP2 imagery. I don't have the time right now to rebuild GDAL (and a little afraid I might break something and create a work stoppage...), so I'm using GeoJasper to convert the JP2s to GeoTIFFs and that works fine.

"geojasper -f in.jp2 -F out.tif -T tif"

However, when I use GDALWARP to change the EPSG:

"gdalwarp -overwrite in.tif out_a.tif -s_srs EPSG:3857 -t_srs EPSG:4326"

the resulting GeoTIFF's colors are washed-out when viewed in QGIS (still RGB, but very, very light, almost as if the brightness is set too high). Any ideas as to what might be the cause?

I will use a batch file to process all of the files once the problem is resolved, which is much, much faster than QGIS (surprised I can't select multiple files within QGIS to do this...).

Improve this question
5
  • If your QGIS can read JP2 then it should have a GDAL version with some JPEG 2000 driver. Jasper has been rather useless for big JP2 files but perhaps GeoJasper is better. I recommend to acquire OpenJPEG driver. If you have hundreds of images it certainly pays back your effort.
    – user30184
    Commented Feb 10, 2021 at 19:05
  • Thanks - GeoJasper works fine for the conversion. I can run all of the files at one time. It's the gdal_translate process that seems to strip something out of the converted GeoTiff related to the RGB pallet, or at least that's what I'm guessing. All of the color bands seem to be correct - it's just the paleness of the converted file that is the issue. I've compared translated images with their originals and nothing appears obviously abnormal. If I perform both the format conversion and change of the EPSG in QGIS (one...single...file...at...a...time), it works fine.
    – Stevenj279
    Commented Feb 10, 2021 at 21:37
  • What JPEG 2000 drivers your GDAL has? Check with gdalinfo --formats. What sort of images you have? Check that also with gdalinfo. Alpha band may play some role. And one small sample file would be really useful.
    – user30184
    Commented Feb 10, 2021 at 21:40
  • It has the JPEG JFIF driver. The images are all NAIP, JP2 format (1-meter resolution) from USGS at the following url: apps.nationalmap.gov/downloader/#/productSearch One image file is about 27 mb, so I think you'd have to download one from there, rather than I try to upload one to here.
    – Stevenj279
    Commented Feb 10, 2021 at 21:48
  • JPEG JFIF is not JPEG 2000 driver. GDAL JPEG 2000 drivers have JP2 in their short name, like JP2OpenJPEG -raster,vector- (rwv): JPEG-2000 driver based on OpenJPEG library. You can't upload such image into gis.stackexchange and I may feel too lazy to study how to download USGS NAIP images. I would prefer to have a direct link to a sample.
    – user30184
    Commented Feb 10, 2021 at 21:53

1 Answer 1

Reset to default
1

The source image is a 4 band image. The metadata page https://www.sciencebase.gov/catalog/item/51355312e4b0e1603e4fed62 does not explain what bands are included but there seems to be red, green blue, and near infrared band. Gdalinfo reports them this way:

  COLORSPACE=MULTIBAND
  COMPRESSION_RATE_TARGET=9
Corner Coordinates:
Upper Left  (-10985845.247, 4491509.546) ( 98d41'15.10"W, 37d22'30.07"N)
Lower Left  (-10985845.247, 4482752.546) ( 98d41'15.10"W, 37d18'44.93"N)
Upper Right (-10978881.247, 4491509.546) ( 98d37'29.89"W, 37d22'30.07"N)
Lower Right (-10978881.247, 4482752.546) ( 98d37'29.89"W, 37d18'44.93"N)
Center      (-10982363.247, 4487131.046) ( 98d39'22.49"W, 37d20'37.53"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Undefined
  Description = Band #1
  Overviews: 3482x4378, 1741x2189, 870x1094, 435x547, 217x273
Band 2 Block=256x256 Type=Byte, ColorInterp=Undefined
  Description = Band #2
  Overviews: 3482x4378, 1741x2189, 870x1094, 435x547, 217x273
Band 3 Block=256x256 Type=Byte, ColorInterp=Undefined
  Description = Band #3
  Overviews: 3482x4378, 1741x2189, 870x1094, 435x547, 217x273
Band 4 Block=256x256 Type=Byte, ColorInterp=Undefined
  Description = Band #4
  Overviews: 3482x4378, 1741x2189, 870x1094, 435x547, 217x273

Converting image into GeoTIFF with gdalwarp does not make troubles with deflate compression

gdalwarp -of GTiff -co tiled=yes -co compress=deflate m_3709843_ne_14_1_20150628_20150922.jp2 m_deflate.tif -t_srs epsg:4326
Creating output file that is 7913P x 7910L.
Processing m_3709843_ne_14_1_20150628_20150922.jp2 [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.

Due to the fourth band JPEG compression gives a warning

Warning 1: TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.

and the result image has a bit different band definitions

Band 1 Block=256x256 Type=Byte, ColorInterp=Gray
  Description = Band #1
Band 2 Block=256x256 Type=Byte, ColorInterp=Undefined
  Description = Band #2
Band 3 Block=256x256 Type=Byte, ColorInterp=Undefined
  Description = Band #3
Band 4 Block=256x256 Type=Byte, ColorInterp=Undefined
  Description = Band #4

QGIS opens the converted 4-band GeoTIFFs so that it shows bands 1, 2, and 3 as RGB. User can select bands 4,3, and 2 to show a false colour version.

I suppose that for some reason in your workflow gdalwarp in changing the meaning of the fourth band of the TIFF that GeoJasper wrote into alpha. If this is the case you can open the image properties with QGIS and set the transparency band into "None" and the image should look good.

There are a few alternatives for a proper fix. You can for example convert just bands 1, 2, and 3 if you do not need NIR band. Or you can edit the image metadata and fix the interpretation that 4th band means alpha with gdal_edit.

Improve this answer
4
  • My sincere thanks for your help and detailed review! Your gdalwarp example works great on my end as well, but it is throwing one error: C:\OSGEO4~1\bin\gdalplugins\gdal_HDF5.dll
    – Stevenj279
    Commented Feb 11, 2021 at 14:33
  • It must unrelated. If conversion works you can forget the error from loading the HDF5 plugin gdal.org/drivers/raster/hdf5.html.
    – user30184
    Commented Feb 11, 2021 at 14:42
  • Thank you so very much! I was able to process the imagery files in a fraction of the time it would have taken me to do so in QGIS. The new GeoTiffs now show (in QGIS properties) that the 4th band is: COLORSPACE=MULTIBAND, whereas it needs to be AREA_OR_POINT=Area. The GeoTiffs I created the hard way showed band 4 to be "Alpha". Can gdal_edit be used to change this 4th band to make the GeoTiffs what I referenced above?
    – Stevenj279
    Commented Feb 12, 2021 at 0:07
  • AREA_OR_POINT has a different meaning, there is no need to touch that. The interpretation of the 4th band can be edited. gdal.org/programs/gdal_edit.html colorinterp_X red|green|blue|alpha|gray|undefined Change the color interpretation of band X (where X is a valid band number, starting at 1). Set band 4 into undefined. I am not sure if other bands needs editing as well but try.
    – user30184
    Commented Feb 12, 2021 at 7:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.