Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Benchmarks and commentary
See original GitHub issueLoads a large tiff image, shrinks by 10%, sharpens, and saves again. On this test NetVips is around 15 times faster than Magick.NET and 6 times faster than ImageSharp.
ImageSharp doesn’t support Tiff but you know this already.
I’m curious about the sharpening phase of the test. Passing .75F to the ImageSharp GaussianSharpen algorithm will create a kernel with a radius of 3. Does net-vips adjust the dimensions of the input kernel to match that radius when dividing by 8?
The resize phase definitely differs. Both ImageSharp and Skia are using sampling algorithms that sample more surrounding pixels than the linear sampler used in the net-vips code. I cannot comment on Magick.NET implementation as I do not know the internals.
I absolutely love a bit of healthy competition and it’s really nice to see others interested in the space.
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@kleisauke Oh, I’d completely forgotten that. Yes, it would be an interesting experiment.
@JimBobSquarePants that just happens automatically with demand-driven processing, no wizardry heh.
This is an nice thread, thank you both for the interesting discussion.
On speed, the libvips binary is usually built with dcommander’s fantastic libjpeg-turbo, which is typically 3x faster than the regular IJG libjpeg. This could explain a large part of the difference, as you say @JimBobSquarePants.
libvips is able to run the decompress and compress operations at the same time, so it gets a factor of two on compress/decompress speed there.
libvips does run-time code generation for convolution: it looks at the convolution mask and the image, and writes a short mmx/sse/neon/etc. program, depending on the host CPU, to compute the result.
It does the same thing for the vertical part of resize, though not the horizontal, unfortunately. From memory, excluding jpg decompress/recompress, about 60% of libvips runtime on this test is in these two or three lines of unvectorised code 😦