Cant Load requested DLL about gdal-sid

[idanmiara]

@SomeJuan588 I released gdal-sid==3.6.4 if you can upgrade your gdal to 3.6 it might be also a solution for you.
I've updated the README with some useful info from this thread.
Note the remark about gdalplugins (also noted at the bottom of the README)

[idanmiara]

Hi,

I can confirm this issue.

I have an old installation of Python 3.8 with GDAL 3.4.1 that I also download from https://www.lfd.uci.edu/~gohlke/pythonlibs/.
With that version gdal-sid==3.4.1 and gdal-sid==3.4.3 do work.

But for some reason I can't get gdal-sid it to work with the Christoph Gohlke's GDAL 3.4.3 wheels of Python 3.8/3.10 (but they do work with gdal-ecw==3.4.3)
As the GDAL 3.4.1 wheels are no longer available online I can't find the source of this issue.

@cgohlke would you be able to share links for the old wheels you published for GDAL 3.4.1 so I can check the source of this issue?

I also tried to make gdal-sid==3.6.4 (https://test.pypi.org/project/gdal-sid/) and gdal-ecw==3.6.4 (https://test.pypi.org/project/gdal-ecw/) in the same way from the gisinternal to use with GDAL-3.6.4-cp310-cp310-win_amd64.whl from https://github.com/cgohlke/gdal.whl/releases but for some reason GDAL doesn't pick up the plugins and I get an unsupported file format error (I'm not sure if something has changed with the way that plugins get loaded in GDAL 3.5 or 3.6).

>>> ds = gdal.Open('d:\dev\gdal-sid\sample_data\mercator.sid')
ERROR 4: `d:\dev\gdal-sid\sample_data\mercator.sid' not recognized as a supported file format.

When I try to use gdal from gisinternals (release-1928-x64-gdal-3-6-4-mapserver-8-0-1.zip, release-1928-x64-gdal-3-4-3-mapserver-7-6-4.zip) it does pick up the plugins (both in gdalinfo and using Python).

[SomeJuan588]

@idanmiara thanks for looking into it. If @cgohlke is able to provide links to previous versions (GDAL 3.4.1), I would be able to work with that.

For your awareness, I went ahead and tried Python 3.7.9 with GDAL 3.4.2 (which is at least a somewhat older version still available from gohlke), with gdal-sid 3.4.3 and gdal-sid 3.4.1. Neither one worked. Same exact error print-outs. Therefore, I suppose this means you could use gohlke's 3.4.2 (which is still available for Python 3.7.9) to investigate the source of the issue.

NOTE: I don't really know the rules for version compatibilities between GDAL and gdal-sid, but assumed (from your example) the first two version components must match but the third is not required (e.g. 3.4.x is compatible with 3.4.y).

[SomeJuan588]

@idanmiara Python 3.7.9 with GDAL 3.3.3 (from gohlke) and gdal-sid 3.3.2 works. In particular, no more error print-outs. Also,
when running:

from osgeo import gdal
# List GDAL supported formats containing the string 'sid' in their LongName
print([gdal.GetDriver(i).LongName for i in range(gdal.GetDriverCount()) if 'sid' in gdal.GetDriver(i).LongName.lower()])

It printed:

['Multi-resolution Seamless Image Database (MrSID)']

Previously, it would print empty list because gdal-sid was not working with GDAL.

Ultimately, I was able to achieve my goal, which was to convert *.sid files into corresponding *.tif files using:
gdal.Translate(output_tiff_file, input_mrsid_file, format="GTiff")

Thanks

`

[cgohlke]

GDAL 3.4.1 was built against static libgeotiff 1.7.0, which contained a bug resulting in libgeotiff functions being exported from the GDAL DLL. GDAL‑3.4.3 was build with libgeotiff 1.7.1 and does not export those functions. Gdal_MrSID.dll seems to rely on those functions, which can be verified with the Dependencies app.

[idanmiara]

@cgohlke thanks so much for looking into this!
Would you be able to re-upload 3.4.1 wheels for us please?

@SomeJuan588, yes, the compatibility is indeed between gdal x.y.p1 and gdal-sid x.y.p2 for any p1 and p2.

[idanmiara]

@cgohlke as per GDAL-3.6.4 - I see that GDAL_MrSID.dll from gisinternals (release-1928-x64-gdal-3-6-4-mapserver-8-0-1.zip,) does not depend on the GTIF* functions that were are not exported in gdal.dll after that bugfix. There are no errors shown in the Dependencies app when I use GDAL_MrSID.dll with your GDAL-3.6.4-cp310-cp310-win_amd64.whl, but it just doesn't load the plugin in (no error message either).
Using the gdal from gisinternal the plugin does work, so I'm not sure what's the difference between your build and gisinternal's build in that respect.

If you want to try yourself, I've uploaded the plugins to test.pypi:
gdal-sid==3.6.4 (https://test.pypi.org/project/gdal-sid/) and gdal-ecw==3.6.4 (https://test.pypi.org/project/gdal-ecw/) i

[cgohlke]

There are no errors shown in the Dependencies app when I use GDAL_MrSID.dll with your GDAL-3.6.4-cp310-cp310-win_amd64.whl

tiff.dll depends on zlib.dll, which is missing. Anyway, it's not a good idea to mix different GDAL distributions.

it just doesn't load the plugin

Set the GDAL_DRIVER_PATH environment variable to the gdalplugins directory or uncomment the section in osgeo/__init__.py

[idanmiara]

tiff.dll depends on zlib.dll, which is missing.

Right, I'll add this one. thanks!

Anyway, it's not a good idea to mix different GDAL distributions.

Yeah, I understand the point but I don't have any other easy alternative for installing gdal plugins on vanilla python.

Set the GDAL_DRIVER_PATH environment variable to the gdalplugins directory or uncomment the section in osgeo/__init__.py

Yes, you are right, it works now.
Now I remember our email conversation on that matter in Feb 2021 -
I asked you back then to uncomment this in your distributions to smooth the plugins installation.
You said "that sounds good. I'll try to remember next time I compile GDAL." -
So gdal-sid and gdal-ecw worked without this extra step for past versions.

Did you have any drawback for having this option on by default?