MagicScalar Linux issue

[BritBlaster]

I'm trying to resize an image stream, using

                var processImageSettings = new ProcessImageSettings()
                {
                    Width = width,
                    Height = height,
                    ResizeMode = CropScaleMode.Crop,
                    HybridMode = HybridScaleMode.Turbo
                };

                MagicImageProcessor.ProcessImage(stream, outstream, processImageSettings);

This works well in windows, but I'm trying to run my app in an Azure web container running Linux.
I've downloaded the codecs, and registered them with:

    CodecManager.Configure(codecs => {
        codecs.UseLibwebp();
        codecs.UseLibjpeg();
        codecs.UseLibpng();
        codecs.UseGiflib();
        codecs.UseLibheif();
        codecs.UseLibjxl();
    });

But this causes an exception: Image format not supported. Please ensure the input file is an image and that a codec capable of reading the image is registered.

I'm not sure what the limitations are of the codecs. The files I've tried are all pretty typical jpg files. I'm sure this must be user-error, but not sure what I've done wrong here...

I have verified that the libraries are all present

-rwxr--r-- 1 root root  555520 Oct 11 21:16  PhotoSauce.MagicScaler.dll
-rwxr--r-- 1 root root   32256 Oct 11 21:17  PhotoSauce.NativeCodecs.Giflib.dll
-rwxr--r-- 1 root root   49152 Oct 11 21:17  PhotoSauce.NativeCodecs.Libheif.dll
-rwxr--r-- 1 root root   44032 Oct 11 21:17  PhotoSauce.NativeCodecs.Libjpeg.dll
-rwxr--r-- 1 root root   42496 Oct 11 21:17  PhotoSauce.NativeCodecs.Libjxl.dll
-rwxr--r-- 1 root root   33280 Oct 11 21:17  PhotoSauce.NativeCodecs.Libpng.dll
-rwxr--r-- 1 root root   53760 Oct 11 21:17  PhotoSauce.NativeCodecs.Libwebp.dll

Thanks for any pointers...

[saucecontrol]

There isn't enough information here to make a positive diagnosis, but yeah, it's probably user error. I can suggest you check the following:

1. You should have the native .so files for the native codecs on Linux in addition to those managed .dll wrappers. If you publish your app with a Linux RID (e.g. dotnet publish -c Release -r linux-x64), your deployment folder should automatically contain the correct managed .dll and native .so files. Make sure you deployed all of them.

2. The exception indicating you don't have an appropriate codec registered probably means that your call to CodecManager.Configure has not been executed before your call to ProcessImage. On Windows, this step is unnecessary, as the library will automatically register the Windows codecs if you don't register anything yourself. However, on Linux, there will be no codecs registered unless you register them explicitly -- this should be done once at app startup.

3. It's possible that your input Stream is not correctly positioned. The library will detect a stream positioned at its end and give you a helpful error to that effect, but if the stream is positioned elsewhere, it may just look like bad data.

[BritBlaster]

Thanks for the quick response.

1. The native binaries seem to be handled properly through the dotnet publish/dockerfile, and I can see:

root@:/app# find . -name "*.so"
./runtimes/linux-arm64/native/libpsjpeg.so
./runtimes/linux-arm64/native/libpspng.so
./runtimes/linux-arm64/native/libjxl.so
./runtimes/linux-arm64/native/libheif.so
./runtimes/linux-arm64/native/libwebpmux.so
./runtimes/linux-arm64/native/libwebpdemux.so
./runtimes/linux-arm64/native/libwebp.so
./runtimes/linux-arm64/native/libgif.so
./runtimes/linux-x64/native/libpsjpeg.so
./runtimes/linux-x64/native/libpspng.so
./runtimes/linux-x64/native/libjxl.so
./runtimes/linux-x64/native/libheif.so
./runtimes/linux-x64/native/libwebpmux.so
./runtimes/linux-x64/native/libwebpdemux.so
./runtimes/linux-x64/native/libwebp.so
./runtimes/linux-x64/native/libgif.so

It's using the default dockerfile which has:
RUN dotnet publish "MyApp.csproj" -c Release -o /app/publish /p:UseAppHost=false
I'll try adding the -r linux-x64 to see if it changes anything.

2. The call to register the codecs is done prior to app.Run() in program.cs, and the console log confirms that it was executed without any exceptions.
3. The stream is correctly positioned, and works correctly on a windows-specific build.

thanks again.

[saucecontrol]

The /runtimes/ folders will work if you use dotnet run, because the SDK will resolve the native libraries correctly through the .deps.json file. However, for the app to run with its own executable or with the dotnet runtime host, the native libraries must be copied into the main app's root folder. dotnet publish with the correct RID is the correct way to handle this.

If that were your issue, I'd expect some kind of library load exception however, instead of the exception telling you it can't find a codec. Registering the codec creates the entries for the magic byte patterns for the associated image files, so it should know a codec is registered. It will then try to load the codec native library.

Again, an issue with codec registration won't cause a failure on Windows because we'll automatically find the Windows Imaging Component codecs. I'd still guess your failure is on that step.

[BritBlaster]

I've done a new build, and it is now working successfully. Not sure what changed...
thanks for assistance :)