Image dithering when transforming vector PDF to TIFF in GDAL 3.9.1

[cxcandid]

What is the bug?

When I load a vector PDF in QGIS 3.38.1 (Windows 10 - GDAL 3.9.1), the resulting image looks like it has been dithered. The same happens when I use gdal_translate to convert the PDF.

With QGIS 3.30.1 (GDAL 3.6.4) there seems to be no image dithering.

Is there any setting to disable this kind of dithering, or do I face a bug here?

The original PDF for testing purposes: test.pdf

Steps to reproduce the issue

Drag & Drop PDF in QGIS 3.38.1

Versions and provenance

Windows 10, GDAL 3.9.1

Additional context

No response

[rouault]

I don't reproduce image dithering on Linux with gdal_translate, using either Poppler 22.02 or 24.04

[agiudiceandrea]

I can confirm the issue using GDAL/OGR 3.9.1 on Windows 10 from OSGeo4W. gdal_translate test.pdf test.tif outputs: (test_3.9.1.tif in test_3.9.1.tif.zip)

while using GDAL/OGR 3.8.4 on the same system it outputs: (test_3.8.4.tif in test_3.8.4.tif.zip)

[rouault]

@agiudiceandrea Do you have a Windows conda-forge environment at hand ? It would be interesting to try the "libgdal-pdf" package and check

[agiudiceandrea]

Do you have a Windows conda-forge environment at hand ?

@rouault, not for now. Anyway I've also checked GDAL/OGR 3.8.5 from OSGeo4W and it also shows the same issue. I guess the issue may be due to some libraries / building options change between GDAL/OGR 3.8.4 and 3.8.5 in OSGeo4W: https://lists.osgeo.org/pipermail/qgis-developer/2024-April/066691.html

[agiudiceandrea]

@rouault, the issue doesn't occur using gdal 3.9.1 with libgdal-pdf from conda-forge on Windows 10. The issue occurs using GDAL 3.9.1 from GISInternals (release-1930-x64-gdal-3-9-1-mapserver-8-2-0) on the same system.

[agiudiceandrea]

The issue is reproducible just using the poppler tool pdftoppm -tiff test.pdf test: it occurs using poppler 24.04.0 shipped by OSGeo4W since GDAL/OGR 3.8.5 while it doesn't occur using poppler 23.07.0 shipped by OSGeo4W until GDAL/OGR 3.8.4. Moreover, the issue doesn't occur using poppler 24.04.0 from conda-forge.

So it definitely looks like not a GDAL issue (and probably not even an issue in poppler itself).

[rouault]

@jef-n I suspect the root cause of this issue is the latest update in Poppler in OSGeo4W, and particularly disabling LCMS support

Closing as not a GDAL issue

[jef-n]

@rouault Rebuilding with lcms2 doesn't seem to change anything. Any other clues?

[rouault]

@rouault Rebuilding with lcms2 doesn't seem to change anything. Any other clues?

@jef-n Not really. I've looked at the poppler recipe in Conda-Forge (https://github.com/conda-forge/poppler-feedstock/tree/main/recipe), but nothing strikes me at immediately relevant . The Conda Forge recipe has a number of Windows specific patches, but they seem related to compile-time issues. I also note it has the fontconfig dependency, but the rendering issue observed doesn't seem to be font specific.

[agiudiceandrea]

particularly disabling LCMS support

Not sure this could be the root cause: it looks like both 23.07.0 and 24.04.0 from OSGeo4W were built without LCMS support, since the pdftoppm -h output doesn't list the "-default*profile" options for both.

https://gitlab.freedesktop.org/poppler/poppler/-/blob/master/utils/pdftoppm.cc#L172-177

I've tested various pdftoppm options, and it looks like there's something not working well when both the "-aaVector yes" and the "-gray" options are specified (which are by default).

When "-mono" is specified, both pdftoppm 23.07.0 and 24.04.0 from OSGeo4W behave the same way and they output an identical image with "-aaVector yes" and another identical image with "-aaVector no", while when "-gray" is specified then they output an identical image with "-aaVector no" but they output different images with "-aaVector yes". Maybe there is something not working well with the gray color space?

[agiudiceandrea]

@jef-n, if it is not possible to fix the OSGeo4W poppler 24.04.0 build, or in the meantime that it will be fixed, I propose to downgrade the OSGeo4W poppler package to the previous version and rebuild gdal and other dependent packages in order to avoid the reported issue.

[jef-n]

see also https://trac.osgeo.org/osgeo4w/ticket/850