MAZANOKE update (image optimizer via browser): Batch upload and download
from lent9004@lemmy.world to selfhosted@lemmy.world on 04 Apr 02:46
https://lemmy.world/post/27770289
from lent9004@lemmy.world to selfhosted@lemmy.world on 04 Apr 02:46
https://lemmy.world/post/27770289
Thank you for the support that I’ve received during the launch of MAZANOKE—a self-hosted local image optimizer that runs in your browser! It can run offline and is installable as a web app too.
This week, I’ve been addressing the feature that has been a bottleneck for the usability of an image optimizer, namely: batch upload and download.
Project page: https://github.com/civilblur/mazanoke
Highlights v1.0.1 (view release note)
- Upload multiple files simultaneously
- Images are processed one at a time to prevent excessive browser resource usage.
- Download all optimized images as a zip file.
- Files over 1GB are split into multiple zip files.
- Large downloads may take time, depending on hardware and browser.
- Option to clear optimized images from the “Images” section.
- Convert GIF and SVG to PNG.
- GIF-to-GIF optimization is not supported.
- SVG optimization is not planned.
threaded - newest
I’m confused, isn’t this running locally? Why are you using the words “upload” and “download”?
That’s a valid question! The app is intended for less tech-savvy people, as such, the terminologies used are to accommodate those users. “Upload” would rather be “Import”, while “Download” would be “Export”.
I’ve shared the use case in a previous Lemmy post:
While I appreciate the sentiment, I do think that despite being well-intentioned this could just contribute to today’s digital illiteracy. It also downplays the app’s privacy, I almost dismissed it as a cloud service the moment I saw that.
Perhaps you could use “open” and “save”, which is widely understood and probably more appropriate.
That said, the app is a great initiative, and I’ll certainly give it a look once I get in front of a computer, and probably recommend it to students.
Just because its run locally, doesnt mean it still isnt a web server. The software could run anywhere and be accessed over the network. The image optimization happens at the server, so download and upload are more accurate.
Fair enough!
Wait, the optimization does not leave the browser. There isn’t any need for a web server.
If this can be used as an offline PWA, it doesn’t even need to be ‘self-hosted’, except for keeping it up to date.
Edited: removed reference to “device”, to avoid confusion.
.
Yeah, you’re totally right.
And then it mentions that you can just open the index.html directly, which means it uses clientside javascript or wasm and runs on the browser. You are correct!
On the topic of word choice, you might be right. Save or open might be better.
Thanks for sharing this! I used it today to resize my Very large phone selfie I had to do for a profile image update at work and it did very nicely! Much faster for me to do that then load it in Gimp and scale it down since I was running late for work. : )
Haha, very interesting scenario, glad it worked out well!
Nice. I use Squoosh for this, which is also free and runs in the browser.
squoosh.frostoven.com
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?
Sounds like an oversight. Consider filing a bug with them.
github.com/frostoven/Squoosh-with-CLI
I’m glad to have some competition for the Frost Oven Squoosh, which is being lightly maintained. I opened some issues in the Mazanoke issue tracker for some features to consider.
One feature I started on for that project but got stuck on was implementing a STDIN / STDOUT CLI workflow.
github.com/frostoven/Squoosh-with-CLI/issues/10
As I said there, the goal was a workflow where I take a screenshot, annotate it, optimize it, copy it and paste it into my blog… without creating any intermediate temp files.
At least on Linux, all the the steps of the pipeline are solved, except for a CLI image compressor that could accept an image STDIN and produce a compressed image on STDOUT.
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.
I installed this after seeing your v1 post and already got use out of it resizing some images on mobile. The only thing I noticed as lacking was a multiple file selector, so this is a great first update!