Codec Request: Magic Kernel Sharp

[cadilhac]

I previously used pica and it uses the mks2013 algorithm, as well as lanczos (but not sure which is doing what). There is no mks2013 option in your library? Or it could be a feature? I was liking its speed and quality result.

[jamsinclair]

Thanks for the suggestion @cadilhac. This is the first time I've heard of the "Magic Kernel Sharp".

There are two explanations as to why:

• The libraries and tools contained in this repo are all derived from GoogleChromeLabs/squoosh
• "Magic Kernel Sharp" seems to be a lesser known tool, in terms of google search results and available ports in various programming languages.

I don't have time currently to look at this. I'd welcome the addition of a wasm compiled version of mks (Magic Kernel Sharp), if someone wants to look at contributing? 🙇

There are two sources that look promising for compiling with WebAssembly

• Original ANSI C source
• Rust source

[jamsinclair]

@cadilhac it turned out to be reasonably simple to add the Magic Kernel methods thanks to a recent rust implementation (Assuming the Rust implementation is valid).

I've refactored the @jsquash/resize module to support the following resize methods and published them in v2.1.0

• magicKernel (The original algorithm)
• magicKernelSharp2013 (The version that I believe is also used in pica)
• magicKernelSharp2021 (The most recent version of the algorithm)

If you end up using the module, it would be great to hear if you encounter any issues and/or if the outputs look correct.

[cadilhac]

Thanks so much. I will try the 3, for sure.
In the meantime, can you tell me if you internally use steppers, i.e. intermediate resizes when the original and target sizes are really distant (like pica does)?

[jamsinclair]

No, unfortunately, we don't internally use steppers. The resize logic is very primitive. It only resizes directly between the given parameters.

If you're in need of production performance I would suggest sticking with Pica, as this is not the core goal of this project.

[cadilhac]

For performance reasons, I can't use pica. Pica uses a web worker internally, which is fine. But I need to control the workers as I need to do several things around the resize in the same worker. With your lib, I can control this workflow. If you don't use steppers, it's fine. I can still develop my own at the client level.

[jamsinclair]

I am glad to hear this library can still prove useful. If there's a simple way to implement steppers I would be open to adding it as an opt-in strategy to the resize library.

[cadilhac]

I have made a comparison test with a specific image. I got these results:
lanczos3: 567 ms
magicKernel: 685 ms
magicKernelSharp2013: 942 ms
magicKernelSharp2021: 1304 ms

Lanczos3 clearly wins here but pica has a tiler that processes 1024x1024 tiles in parallel so it's faster or equivalent (it uses magicKernelSharp2013 by default) than your library. However, since I need the control of the web worker, as I told you, I will continue using lanczos3 as it is fast and the image quality compared to the original is very good. And after all, I don't need a stepper since the original and destination have not a huge gap.

Note: I noticed that magicKernel produces a softened image.