gdalinfo fails for jpg/jpeg on Windows

[pathmapper]

Expected behavior

gdalinfo doesn't error for the following jpg: sample_jpg.zip

Actual behavior

gdalinfo errors with

ERROR 1: libjpeg: Bogus Huffman table definition
gdalinfo failed - unable to open '004.JPG'.

Steps to reproduce the problem.

gdalinfo 004.JPG

Operating system

Windows 10

GDAL version and provenance

GDAL 3.1.4 installed with OSGeo4W Shell along with QGIS 3.16.1

---

This happens for a lot of different images captured with different devices.

Using GDAL 2.4.0 on Linux (Debian) installed with QGIS 3.16.1 gdalinfo shows no error.

Also with several image viewers (e.g. GIMP) the sample jpg works flawlessly and it's possible to show the EXIF data.

[jratike80]

Some quick tests:

• A few weeks old GDAL 3.2.0dev from gisinternals.com does not show that error.
• OSGeo4W throws an error for me too.
• Irfan View, Windows Photo viewer are happy with the image.
• Convert JPEG->JPEG with the gisinternals version - OSGeo4W versions reads the copy.

[rouault]

I see that OSGeo4W uses the internal libjpeg (6-b) of GDAL, and I believe (not completely sure) gisinternals.com, also does. I've tried on Linux a build with internal libjpeg, and I manage to read the image. So, I'm not completely sure why this happens on OSGeo4W builds. Wondering if it might not be a conflict between the symbols of the internal libjpeg in GDAL and an external libjpeg that would be a dependency of a library that GDAL would link against too. CC @jef-n

[jratike80]

Gisinternals do not list libjpeg as dependency https://gisinternals.com/packageinfo.php?file=release-1911-x64-gdal-mapserver.zip. Mayby that means that internal jpeg of GDAL is used.

[pathmapper]

@rouault @jratike80 thanks for looking into this.

FWIW the error message varies (using the same setup for different images). Here are two other error messages:

ERROR 1: libjpeg: Invalid component ID 0 in SOS
gdalinfo failed - unable to open 'IMG_0077.JPG'.

ERROR 1: libjpeg: Bogus DHT index 4
gdalinfo failed - unable to open 'Willich_25_809_5.JPG'.

[agiudiceandrea]

On Windows 10 64 bit, GDAL 3.0.2 (OSGeo4W gdal-3.0.2-3) and GDAL 3.0.3 (OSGeo4W gdal-3.0.3-2) succeed to open the provided jpeg file:

C:\>gdalinfo --version
GDAL 3.0.2, released 2019/10/28

C:\>gdalinfo C:\TMP\004.JPG
Driver: JPEG/JPEG JFIF
Files: C:\TMP\004.JPG
Size is 3264, 2448
Metadata:
...

C:\>gdalinfo --version
GDAL 3.0.3, released 2020/01/08

C:\>gdalinfo C:\TMP\004.JPG
Driver: JPEG/JPEG JFIF
Files: C:\TMP\004.JPG
Size is 3264, 2448
Metadata:
...

while GDAL 3.0.4 (OSGeo4W gdal-3.0.4-2) fails:

C:\>gdalinfo --version
GDAL 3.0.4, released 2020/01/28

C:\>gdalinfo C:\TMP\004.JPG
ERROR 1: libjpeg: Bogus Huffman table definition
gdalinfo failed - unable to open 'C:\TMP\004.JPG'.

On both OSGeo4W installation, libjpeg and libjpeg12 version 6b (libjpeg-6b-4, libjpeg12-6b-4) are installed.

The difference I see between 3.0.2/3.0.3 and 3.0.4 is that for 3.0.2/3.0.3 gdal300.dll is linked to jpeg.dll (from libjpeg-6b-4), while for GDAL 3.0.4 gdal300.dll doesn't use jpeg.dll.

[agiudiceandrea]

It seems the same happens (on Windows 10 64 bit / OSGeo4W 64 bit) with GDAL 3.2.0dev/3.3.0dev and GDAL 3.1.0:
both GDAL 3.2.0dev and GDAL 3.3.0dev succeed to open the jpeg file (gdal302.dll and gdal303.dll have jpeg.dll as dependency), while GDAL 3.1.0 (gdal-dev 3.1.4rc2-1) fails to open the jpeg file (gdal 301.dll is not linked to jpeg.dll) via gdalinfo.

[rouault]

I've reported the issue to the OSGeo4W tracker: https://trac.osgeo.org/osgeo4w/ticket/654

[rouault]

https://trac.osgeo.org/osgeo4w/ticket/654 is indicated as fixed. Thanks @jef-n