[Feature Request] Linux support about photosauce HOT 12 CLOSED

Yep, I've been meaning to put an update on here. The 0.13 release (which is very nearly done) will include full support for plug-in codecs, clearing the way to integrate the standard native xplat codecs (libjpeg[-turbo], libpng, etc), which are the largest remaining piece for Linux compat. I have some experimental native codecs (libjxl and libheif) building and integrated already and have been testing those on x64 and ARM64 Ubuntu alongside the Windows support.

There will be a few more things that need to be filled in before Linux has full feature parity, including the standard xplat codec wrappers. Depending on the amount of help and/or funding I can get, those should be doable for this year. I can finally see the light at the end of the tunnel 😄

from photosauce.

I am pleased to announce that with the v0.13.2 release, MagicScaler is now usable from Linux! I've published native codec packages for JPEG, PNG, GIF, WebP, HEIF, and JXL.

There is a bit of work remaining to reach full feature parity with the WIC integration, so work will continue on this. CMYK conversion is not yet supported, and a few codecs are left to do (notably BMP and TIFF). I'll be closing this issue and opening new ones for tracking the remaining features.

from photosauce.

A good starting point would be to split this library into platform dependant and independant parts, so that e.g. the high quality convolution code could be used in say SkiaSharp.

I've been chipping away at the WIC dependencies for a while, and I'm happy to report that as of
3ea9087, it is now possible to run the MagicScaler pipeline on Linux for many scenarios, provided you roll your own codec support.

I've put together a quick sample showing how to integrate SkiaSharp for the decode/encode steps in this gist, which I've tested on WSL against the latest CI build.

There is still quite a bit of work to do to get native codecs fully integrated with the pipeline, and I will start that effort in earnest later in the year.

Of course the trick to use an already downsampled image directly from the JPEG DCT components won't work, but as far as I known, JPEG doesn't use a linear color space, so to get the highest possible quality, this trick should be avoided anyway?

True, if you want the 'highest possible' quality, however the margin MagicScaler leaves when using this technique (3x by default) means there is no perceptible difference in quality.

The hybrid scaling technique could actually be used when integrating with SkiaSharp as well. When decoding with SKCodec, simply give smaller dimensions on the SKImageInfo, and Skia will request a frequency-domain resize from the JPEG codec.

from photosauce.

I'm afraid not. There is a hard dependency on the Windows Imaging Component (WIC) for codec, metadata, and color management support for now. I am working on replacing those dependencies with either managed or platform-native components, but it will likely be some time before full Linux compatibility is possible.

I'll leave this issue open as a marker for the status of that effort in case anyone else is looking for it.

from photosauce.

ImageSharp has definitely closed the gap with their 2.0 release, but I've got some decent improvements coming in MagicScaler 0.13 as well 🚀

The codecs are the main bottleneck for both libraries at this point. I'll be integrating libjpeg-turbo first, but my plan is to work with the ImageSharp team to make the managed codecs the fastest things out there -- at least for the classic formats.

OSX doesn't interest me, as I have no desire to support a company as openly developer-hostile as Apple, but I won't be doing anything to prevent running there. It might work coincidentally 😉

from photosauce.

Yes, we are looking for Linux support for this great library. I have to say that it's making a great quality for resized images. Thank you for your work!

from photosauce.

Hi all :)

@saucecontrol: any update on this topic?

from photosauce.

OSX doesn't interest me, as I have no desire to support a company as openly developer-hostile as Apple, but I won't be doing anything to prevent running there. It might work coincidentally

LOL. You should try getting an M1 Mac and using it for .Net development.... you might be pleasantly surprised!! ;)

from photosauce.

Seconded, Linux support would be amazing for this!

from photosauce.

A good starting point would be to split this library into platform dependant and independant parts, so that e.g. the high quality convolution code could be used in say SkiaSharp.

PS: Of course the trick to use an already downsampled image directly from the JPEG DCT components won't work, but as far as I known, JPEG doesn't use a linear color space, so to get the highest possible quality, this trick should be avoided anyway?

from photosauce.

Amazing!

from photosauce.

Great! Will this just be Linux or true x-plat with OSX support too?

Would be great to see some updated benchmarks too; I'm intrigued to know if ImageSharp has closed the gap performance-wise in its latest releases.

from photosauce.