

If I understand it correctly, the heic image does get read and compressed. However, it’s the last part when clicking the download button that it instead displays the image as a jpeg (on a new tab)?
If I understand it correctly, the heic image does get read and compressed. However, it’s the last part when clicking the download button that it instead displays the image as a jpeg (on a new tab)?
That’s still very interesting to hear, maybe I’ll look into it for my next (simpler) project just to try it out.
I think @jogai_san@lemmy.world put out some great points. On top of this, you can still install MAZANOKE as a PWA, so you “essentially” get a native application experience.
Thanks for your kind words, I tried putting some effort into making the interface a bit more fun and interactive, so thanks for noticing!
In regards to Rust, I’ve been interested in learning more about it, but I’ve not had time yet, so it’s been in a “soon ™” limbo. As I’m comfortable with JavaScript/JS frameworks, sticking with JS was a quick way to get started without much friction.
To preface a bit. I occasionally run my images through Sharp over CLI, and I am also a daily user of the Caesium desktop app. However, I haven’t explored the details of how Caesium is implemented.
The biggest difference is that MAZANOKE targets a different user group, essentilly those who would use online tools over installing applications, which is something you see more of these days. I wanted my family and friends to have a safe drop-in replacement for those shady websites. For those who want to use a “native app”, installing MAZANOKE as a PWA is also a great option.
In terms of core functionality, they are very similar and support the same output image formats. But at the end of the day, MAZANOKE is privacy-focused too, and have plans to add a simple image editor for obfuscation, cropping, and related features. You can also access MAZANOKE anywhere, whether it is self-hosted or on the official instance.
Fundamentally, MAZANOKE relies heavily on the device, and the browser’s Canvas API. This means that the speed and quality could slightly differ depending on which device/browser you use. I believe Caesium’s performance would be more consistent.
(I didn’t know where to put this, but my favorite feature is being able to paste to compress an image right away using MAZANOKE.)
Edit: typo
For this project, I think I’ll keep it to just images, but if I tackle a project with videos, it would be separate from MAZANOKE.
The unofficial unraid template was graciouslly provided by ctrlaltd1337ed, but I appreciate the sentiment.
About the name, It is an amalgamation of two words, I’ll leave the rest to your imagination!
Correct! This all works in the browser offline. As outlined in the install instructions, you can simply download the project files and just launch index.html
. The docker setup is if you want to be able to access the service on local network or share it publicly.
Yes, it’s all JavaScript and essentially relies on the Canvas API to compress the images, so the performance is heavily dependent of your device and browser. I haven’t delved into WASM yet, but it would indeed open up doors for improvements, such a more file format support and more intelligent optimization. At the moment, working with canvas keeps things a lot more straightforward, however.
There is no funding I can provide at all (I’ve received 2 donations so far, which I’m very grateful for!). I just do this on my spare time, which I have a lot less of these days. I initially created MAZANOKE as a drop-in replacement for family and friends, specifically to those who tend to use questionable or ad-bloated online tools.
As a Lemmy user myself, I totally get the sentiment. GitHub isn’t ideal, and I had also considered Codeberg in the past (not for this project, but way back for others). Unfortunately, the simple reason is that the community is already on there, which makes getting contributions and engagement much easier. Managing and tracking issues across two platforms would be quite (mentally) taxing, which is on top of the effort already going into developing the app.
I’m glad to hear it’s being used frequently! I’ve heard a similar, but not exactly the same use case, so I recommend submitting a feature request on GitHub. That way, I can review it later to assess if the feature could be included when I plan ahead for new releases.
If you get around to it, I’d love to know about it and add that as a feature.
EXIF data is removed by default, at the moment, there’s no way to keep those data. I personally see that more as a feature than a bug though. The primary reason why there is no option to keep EXIF data is to maintain feature parity across different image formats.
The conversion option “Default” is meant to retain the file format when possible, but you can actively select the other options like jpg or webp if that fits your use case better.
Currently, only SVG to PNG is supported. SVGOMG is a great tool I’ve used many times as a user, but since it runs as a Node.js app, it would require server-side processing, unlike the local browser-based approach of this app.
If I understand it correctly, then yes, that’s the case! I’ve utitlized several libraries such as “Browser Image Compression”, “heic-to”, and more, to wrap it in a web interface.
Oh wow, thank you for taking the time creating the feature requests/issues. I just finishing replying to them.
I’ll give the workflow another think and see if it fits within the project as a whole.
Even though this squoosh instance seems to be selfhosted, it has Google Analytics tracking (since Google made this app). MAZANOKE does not include any tracking nor require any internet connection at all if you install it as a PWA.
Edit: Looked at the source code of the fork, and it is applying the same tracking ID (to the big G). As squoosh is apache2 licensed, from my understanding, they should be able to simply remove that off the fork?
Haha, very interesting scenario, glad it worked out well!
Based off the things you mentioned, especially the “little quirk”, there something in the pipeline that fails. The file name extension is intended to show regardless of which output format that is selected.
Are you perhaps using a privacy-focused browser like Librewolf (opposed to vanilla Firefox)? Or do you have any extension that might be used for anti-fingerprinting? MAZANOKE need to be able to access the browser’s canvas feature in order to convert images, and some browsers are blocking this feature to prevent fingerprinting.
Also, have you tested MAZANOKE on a different browser to see if it works there?
If the issue still persist, would you mind sending me a screenshot of the browser console log, in order for me to see where it fails. This will hopefully provide some hints.
Additionally, while I don’t have a Windows environment readily available, I’ve tested MAZANOKE on Ubuntu and macOS using both firefox and chromium, but I wasn’t able to reproduce it. Will test on Windows when I find the chance to.