I built the image compression for imgfiber using CompressorJS as the base. It’s a reliable library by Feng Yuanchen (https://fengyuanchen.github.io/compressorjs/), originally designed for lossy compression. I wrapped and modified it to meet our specific needs, tweaking the code so the results differ from the default - you won’t get the same file size or optimization when using it out of the box. Full credit for the core library goes to the original author; my work was to modify it for our usecase. to solve our own personal pain point.
Using CompressorJS means lossy image compression. You really shouldn't be calling this "Instant, Lossless File Compression" on your page.
Also, because you're using CompressorJS's default settings, you should know that PNG files > 5 MB are converted to JPG (https://github.com/fengyuanchen/compressorjs?tab=readme-ov-f...). Your site, however, keeps the .png file name ending for the converted image, again falsely suggesting lossless compression.
> I wrapped and modified it to meet our specific needs, tweaking the code so the results differ from the default - you won’t get the same file size or optimization when using it out of the box.
I presume this is an oversight; changing CompressorJS's quality setting from its default of 0.8 to 0.75 results in the exact same output as ImgFiber.
Yeah, but if you're trying to promote your AI generated React bloat wrapper in a "Show HN", you should at least be honest and describe how it's actually working instead of writing mindless, non-coherent, intentionally misleading ad blurbs without any actual information imho.
It's not a AI generated React bloat wrapper as you seem to think somehow.
We did not lie about actual working when fellow developers demanded answers. I love talking about what i have build. Maybe just nudge better? instead of hating?
Lossless compression means the pixels of the output image are 100% identical to that of the output image.
This site is clearly not doing that, and should thus not be called "lossless compression". The industry term for lossy compression that appears to be basically the same as the source is "visually transparent" or just "transparent". Though this doesn't seem like that either, especially when you're compressing large PNGs into JPGs while naming the output as PNGs. That's just outright deceitful, and not a good look.
judging by the response we got , we will update site to reflect on “nearly lossless” approach than calling it “lossless” then We don’t mean to be deceitful.
As an alternative to this, I quite like https://squoosh.app/ - Also works on-device, but additionally it's open source, supports multiple output formats, and exposes all the speed / quality / transparency options.
Squoosh is great but for average user dealing with so many peremeters feels overwhelming and provides odd results.When you're handling a large number of files - like a Midjourney archive or a collection of images,it’s more convenient to use an app with preset settings that can process them in bulk, rather than one with detailed options that require fine-tuning.
Can you explain a bit how working with JPG format was different than working on PNG format?
How did you achieve significant savings for both formats, given that many clever people have worked on this before?
Yes, some gains come from stripping metadata, but structural compression means optimizing how image data is encoded, like better Huffman tables for JPGs or smarter filtering for PNGs.
That's not compression, that's just deleting people's data.
structural compression means optimizing how image data is encoded, like better Huffman tables for JPGs or smarter filtering for PNGs.
I think that's just called compression.
How are you getting better huffman tables for JPGs and how are you doing 'smarter' filtering for PNGs ?
I'm asking for deeper technical explanations because not only would beating current image compression libraries be a technical feat, a lot of people in this thread think that you aren't actually doing anything differently.
Is the tool working? I uploaded a couple images and it gave out 0 compression.
Also I am not sure if you thought the product through, when I want to compress images I want to control the output and also control the quality setting. This does not seem to do anything.
yes tool works. its weird your images didn’t show any reduction in size. would love to try fixing it.
we did thought it through based on our use case :) that is working on bulk image processing where a slight loss in quality for Higher reduction in size is appreciated :) mostly for wallpaper apps or any image related sites. but yeah we will improvise to offer even cleaner approach
Ohh, Optimage and ImageOptim are different. thanks for pointing that out! We just came acrross imageoptim thanks to your comment. interesting to see how it offers subscriptions.
JPEG-XL definitely way to go. we’re exploring ways to integrate support for formats like JXL and AVIF soon.
This is a CompressorJS wrapper.
https://fengyuanchen.github.io/compressorjs/
https://github.com/fengyuanchen/compressorjs
I built the image compression for imgfiber using CompressorJS as the base. It’s a reliable library by Feng Yuanchen (https://fengyuanchen.github.io/compressorjs/), originally designed for lossy compression. I wrapped and modified it to meet our specific needs, tweaking the code so the results differ from the default - you won’t get the same file size or optimization when using it out of the box. Full credit for the core library goes to the original author; my work was to modify it for our usecase. to solve our own personal pain point.
Using CompressorJS means lossy image compression. You really shouldn't be calling this "Instant, Lossless File Compression" on your page.
Also, because you're using CompressorJS's default settings, you should know that PNG files > 5 MB are converted to JPG (https://github.com/fengyuanchen/compressorjs?tab=readme-ov-f...). Your site, however, keeps the .png file name ending for the converted image, again falsely suggesting lossless compression.
> I wrapped and modified it to meet our specific needs, tweaking the code so the results differ from the default - you won’t get the same file size or optimization when using it out of the box.
I presume this is an oversight; changing CompressorJS's quality setting from its default of 0.8 to 0.75 results in the exact same output as ImgFiber.
Full settings dump:
the settings dump you dropped will not deliver on same outputs :)
Isn't everything a wrapper for something in the end? Weird comment ...
Is CompressorJS a wrapper?
I mean software product. Everything commodities something in the end imho
Yeah, but if you're trying to promote your AI generated React bloat wrapper in a "Show HN", you should at least be honest and describe how it's actually working instead of writing mindless, non-coherent, intentionally misleading ad blurbs without any actual information imho.
It's not a AI generated React bloat wrapper as you seem to think somehow.
We did not lie about actual working when fellow developers demanded answers. I love talking about what i have build. Maybe just nudge better? instead of hating?
Welcome to HN ;) Lots of nay-sayers that haven't build a thing ever. Keep at it and don't worry.
Well said
But we're not at the end yet
Lossless compression means the pixels of the output image are 100% identical to that of the output image.
This site is clearly not doing that, and should thus not be called "lossless compression". The industry term for lossy compression that appears to be basically the same as the source is "visually transparent" or just "transparent". Though this doesn't seem like that either, especially when you're compressing large PNGs into JPGs while naming the output as PNGs. That's just outright deceitful, and not a good look.
judging by the response we got , we will update site to reflect on “nearly lossless” approach than calling it “lossless” then We don’t mean to be deceitful.
In image compression "lossless" is a term of the art. What you're doing is a practically useful quality degradation, but it's not lossless.
I just tested with a folder full of jpegs and I didn't even have to compare to see the artifacts kind of "looseless"
What am I missing about the 2.8mb example image not reducing to 698kb as it says on the homepage?
I downloaded https://www.imgfiber.com/compare/original.jpg and dragged it into the try-it-now section - says it's now 1.3mb.
That's worse than Squoosh's default 897kb (https://squoosh.app/editor), though better than CompressorJS's default 2.21mb (https://fengyuanchen.github.io/compressorjs/), (edit ii) tho changing CompressorJS's quality setting to 0.75 results in the exact same output as ImgFiber.
Edit: this is on latest Chrome + macos.
As an alternative to this, I quite like https://squoosh.app/ - Also works on-device, but additionally it's open source, supports multiple output formats, and exposes all the speed / quality / transparency options.
Squoosh is great but for average user dealing with so many peremeters feels overwhelming and provides odd results.When you're handling a large number of files - like a Midjourney archive or a collection of images,it’s more convenient to use an app with preset settings that can process them in bulk, rather than one with detailed options that require fine-tuning.
Sidenote, but I enjoyed seeing the squoosh maintainers talk through [1] how they diagnosed and resolved a memory leak they had a while back.
[1]: https://youtu.be/YDU_3WdfkxA?si=n-ZZwRI9V51p-Pxc
I would suggest avoid using in Firefox, the images can appear to be brighter than converting in other browsers.
Are you using a known tool or library? If not, what’s the algorithmic technique?
we're using highly modified CompressorJS library to get this results. hope that helps.
Can you explain a bit how working with JPG format was different than working on PNG format? How did you achieve significant savings for both formats, given that many clever people have worked on this before?
We focused on lossless techniques like metadata cleanup, optimal encoding settings, and structural compression—for both JPG and PNG.
Does this mean that some of your 'compression' is just deleting meta data?
structural compression
What does this mean?
Yes, some gains come from stripping metadata, but structural compression means optimizing how image data is encoded, like better Huffman tables for JPGs or smarter filtering for PNGs.
some gains come from stripping metadata,
That's not compression, that's just deleting people's data.
structural compression means optimizing how image data is encoded, like better Huffman tables for JPGs or smarter filtering for PNGs.
I think that's just called compression.
How are you getting better huffman tables for JPGs and how are you doing 'smarter' filtering for PNGs ?
I'm asking for deeper technical explanations because not only would beating current image compression libraries be a technical feat, a lot of people in this thread think that you aren't actually doing anything differently.
I'm a big fan of Clop. https://lowtechguys.com/clop/
love the drag and drop to optimize approach. so cool.
Is the tool working? I uploaded a couple images and it gave out 0 compression.
Also I am not sure if you thought the product through, when I want to compress images I want to control the output and also control the quality setting. This does not seem to do anything.
yes tool works. its weird your images didn’t show any reduction in size. would love to try fixing it.
we did thought it through based on our use case :) that is working on bulk image processing where a slight loss in quality for Higher reduction in size is appreciated :) mostly for wallpaper apps or any image related sites. but yeah we will improvise to offer even cleaner approach
I really like the kewltools image file size reducer
https://kewltools.com/image-resizer
Just enter in the desired file size and it will compress down to it
wow. really love this. thank you for mentioning it. its super useful for uploading on government websites they really love limiting uploads
[dead]
Ohh, Optimage and ImageOptim are different. thanks for pointing that out! We just came acrross imageoptim thanks to your comment. interesting to see how it offers subscriptions.
JPEG-XL definitely way to go. we’re exploring ways to integrate support for formats like JXL and AVIF soon.
[dead]