[HN Gopher] Show HN: Bulk convert images online without sending ...
___________________________________________________________________
Show HN: Bulk convert images online without sending to server
Author : akmittal
Score : 140 points
Date : 2022-01-23 13:13 UTC (9 hours ago)
(HTM) web link (www.webutils.app)
(TXT) w3m dump (www.webutils.app)
| yawnxyz wrote:
| This is so cool!
|
| I'm completely new to WASM but excited to learn -- how did you
| use the Squoosh repo to turn it into WASM, and how did you embed
| that into your app? Is that just a static file you can "import"
| and use in the client?
|
| And can anything be "turned into" WASM (e.g. a python library),
| or is that kind of a new paradigm of writing code from scratch?
| skilled wrote:
| Nice! Thank you.
| cblconfederate wrote:
| This is the real decentralized web. Current web sucks because
| your data touches servers you re supposed to "trust". Trust
| nothing
| bserge wrote:
| xml wrote:
| I also implemented a batched client-side web tool to resize
| photos to a certain file size (in a few hundred lines of JS). It
| only supports JPEG, but it resizes photos almost instantly
| https://randomforest.net/resizePhoto.html
|
| Here are a few ideas to make yours faster:
|
| 1. Use the browser's canvas element to compress JPEG or PNG
| images instead of WASM. The libraries which come with browsers
| can use processor-specific instructions, while WASM only targets
| the smallest common denominator of the most common architectures,
| so it will be slower.
|
| 2. Which resizing method are you using to find a fitting image
| size? For me, it worked well enough to downscale by some factor a
| few times until it fits, but if you want to get super close, you
| could use binary search.
| mnutt wrote:
| My experience has been that using canvas to resize images
| produces inconsistent results from one browser to another, and
| in most cases is higher file size and lower quality than other
| tools. Enabling imageSmoothingEnabled helps, but is only
| supported in chromium-based browsers right now:
|
| https://caniuse.com/mdn-api_paintrenderingcontext2d_imagesmo...
| personjerry wrote:
| How can it be both online AND not need a server? In this case, it
| sounds like it's not online -- you can simply save the script.
| akmittal wrote:
| Images are not send to server, all processing is on client
| side. Server is required to download the webpage/wasm, but not
| to process files.
|
| In future planning to make the app available offline using
| service worker. So first time internet would be required, next
| time onwards without internet also it will work.
| tantalor wrote:
| The actual conversion is offline, so "convert online" is kind
| of weird/confusing.
| rubyist5eva wrote:
| "convert online" = "using a webpage in a browser"
| hunter2_ wrote:
| You can certainly open local html files that run JS using
| a web browser while your network stack is offline though,
| and doing so can't be described as being online. I guess
| you could argue whether doing this actually constitutes
| opening "web pages" but I think most people would say it
| does.
| throwoutway wrote:
| You could test this simply by disconnecting your device from
| wifi and seeing if it works as stated
| dylan604 wrote:
| >Bulk convert images online without sending to server
|
| If the data never leaves the local, how is it online?
|
| "Bulk convert images in the browser without sending to server"
| seems more appropriate
| akmittal wrote:
| I probably messed up the title, I mean you need to be online to
| use webapp, but app won't sent any images to remote server for
| processing.
| hunter2_ wrote:
| Would it be possible to eliminate the need to be online, so
| then you could make the much more enticing claim (for
| privacy-conscious users) that it works offline? Maybe a PWA,
| or just by clicking "File > Save."
| akmittal wrote:
| Yes have plan for same, will be done in next 2 days.
| dylan604 wrote:
| This isn't any different from any other image processing app
| that you download and use, except you have to download it
| every time you need to use it again. So the advantage is that
| you don't have to make multiple versions of native apps, and
| you didn't make it an electron app. Other than that, it's YA
| image tool. I hope you learned whatever you set out to learn
| with this.
| tomcatfish wrote:
| I disagree with this and it's overly negative. This is
| pretty useful for places where you are unable to download
| applications.
| zerop wrote:
| Recommend a good such tool for all kinds of image editing
| /Cropping/etc in browser?
| rikschennink wrote:
| Not op but I created https://edit.photo just for that :)
|
| It's 100% private, editing happens in the browser.
| poniko wrote:
| Pixlr E has a batch tool with 20+ things you can batch .. also
| in the browser, just like all of the Pixlr tools.
| (https://pixlr.com/e/)
| arriu wrote:
| Thanks for building this! Would you be able to add something like
| dcraw.js for various RAW file support?
| flykespice wrote:
| dilliwal wrote:
| Bookmarked! thanks for this amazing tool.
| jeroenhd wrote:
| This looks like a nice alternative to https://squoosh.app/. I
| particularly like the "resize image to a particular size"
| (https://www.webutils.app/compress-image-to/50kb) feature, that's
| very useful.
|
| Sadly, because of the nature of the web, one can never be sure
| that the image _actually_ stays within the browser. There 's no
| way to prevent it from secretly sending everything you convert
| with this to some shady website because it runs in the browser. I
| trust the people behind this just fine, but sadly the promise of
| offline-level privacy and running code inside the browser just
| don't go well together.
| jimkleiber wrote:
| Android used to have a permission for internet access and when
| I was building an app that I wanted to prove to people that was
| local-only, fully offline, it helped to show that the app
| didn't even have permission to access the internet.
|
| I wish browsers, Android, and iOS had this option so that users
| could be confident that the app/site doesn't have access to the
| internet. Maybe a little tricky with a browser but perhaps it
| could be possible somehow.
| tyingq wrote:
| I tried making a chrome dev tools network throttling profile
| set to "0 kbps", and it seems to work...you get "no internet"
| if you try and reload the page, xhr in the console fails, etc.
| So cumbersome, but it does work.
| gruez wrote:
| >if you try and reload the page, xhr in the console fails,
| etc.
|
| what about:
|
| * DNS leaks (eg. trying to connect to
| payloadhere454098357987.attacker.example, leaks
| payloadhere454098357987 to the attacker)
|
| * websocket
|
| * webRTC
|
| * prefetching
|
| * service workers (background sync)
|
| * beacons
|
| * CSP reports
| tyingq wrote:
| Sure, there is probably more needed. Some of your list is
| covered though. For example, I tried websockets, and those
| are blocked by the throttle.
| akmittal wrote:
| I guess one may disable wifi+data if on mobile.
|
| Disconnect wifi of on Desktop, but agree with OP there is no
| good way to check if processing is actually happening
| locally.
| scrollaway wrote:
| > _Sadly, because of the nature of the web, one can never be
| sure that the image actually stays within the browser. There 's
| no way to prevent it from secretly sending everything you
| convert with this to some shady website because it runs in the
| browser._
|
| The thing is, that logic applies just as well to desktop apps.
| There's never any guarantee on either desktop or web unless you
| have very specific counter-measures in place (firewalls,
| airgapping, ...).
|
| It's just "closer to the web" when it runs in the browser, but
| if malice is the intent, it's as likely on either. Desktop apps
| are just "harder" to install.
| bserge wrote:
| rom1v wrote:
| > The thing is, that logic applies just as well to desktop
| apps.
|
| A website might serve a different code every time you use it.
| It might even serve a malicious code specifically for some
| users.
| indymike wrote:
| > A website might serve a different code every time you use
| it. It might even serve a malicious code specifically for
| some users.
|
| Desktop apps can do this little trick, too. Also, many
| desktop apps can enlist the help of other desktop apps
| using the three decades or so of various ways our OSes have
| made to lett apps talk to each other. Bad actors were using
| macro languages in desktop apps long before the invention
| of the web browser. Now, it's just as easy for a desktop
| app to hit an endpoint, grab a script (shell or macro
| language) and then execute it. The browser is just another
| desktop app - one with much more scrutiny than that MP3
| tagging thing with a built in Lua interpreter that Bob in
| sales just gave local admin privileges to...
|
| Oh, and most desktop apps have some level of access to your
| identity - or outright have you confirm your identity when
| you activate your license.
| mattl wrote:
| A desktop app could do the same. It would be trivial to run
| a little bit of extra code if the person running the app's
| username is yours.
| tuyiown wrote:
| If you consider arbitrary code execution for desktop apps
| you'll see that there's no much difference at a conceptual
| level.
| bbarnett wrote:
| This is why one reason why sensible Linux distros go though a
| multi-year process of release stabilization, assessment and
| testing.
|
| While not impossible, the likelihood of, say, imagemagick
| doing this, while going through this process, is extremely
| improbable.
|
| I agree that just downloading apps off random websites is
| every bit as risky as a browser app.
|
| But who does that?!
|
| (The last statement was sarcastic, and aimed at the curl |
| bash crowd, the nodejs crowd, the composer crowd... these
| things are the polar opposite of trusted, secured, audited,
| safe, sensible.)
| dahart wrote:
| Seems like you've conflated a lot of things here. Binaries
| in the Ubuntu Snap store are not reviewed for years, it's
| days at best (and that's only for classic mode, the
| confined apps are released without human review). Software
| you get from NPM isn't a random website nor is it a desktop
| binary, it's source code you can read. I trust random web
| pages much more than I trust Linux Desktop apps, because
| the browsers are far more audited and safe than
| applications, and I have complete control over what data I
| put in the browser.
| pjerem wrote:
| > Software you get from NPM isn't a random website nor is
| it a desktop binary, it's source code you can read.
|
| Most NPM libraries (even open source) are compiled and /
| or minified before they are uploaded to npm so it's
| actually pretty common to get unreadable source code from
| npm.
|
| Nothing in NPM ensures that the package code is the same
| thing you see on GitHub. This would require NPM to
| checkout and build all the packages by themselves.
|
| So no, with NPM, you are totally running random code on
| your company's computer. But surprisingly the world seems
| to be ok with that.
| dahart wrote:
| That's a fair point, though are you sure about _most_?
| And are you saying most code only comes in minified form,
| or are you referring to libraries that come with a pre-
| minified option in addition to readable source? I've used
| NPM a bunch and rarely seen minified code only, and
| usually minification happens on my end as part of my
| site's build, not to obscure JS library source code.
|
| It's true that use of NPM requires trust. At least NPM
| projects have a name attached to them and some
| accountability. It is by no means foolproof, but
| malicious projects lose their accounts along with the
| reputation that takes time to earn. The world does seem
| to be okay with a certain amount of trust.
|
| This is really true of _any_ software distribution
| system, even and including all distros of Linux. The
| point at the top of the thread is that we don't have a
| way to know what happens when we download any software,
| or when we give our data to an application. We can
| protect our computers by auditing software and sandboxing
| systems, but the system still requires trust. Open source
| and auditing is still just a narrative that I have to
| trust from my point of view, unless I'm the person doing
| the auditing myself.
|
| It might help to clarify the threat model. The poster I
| replied to confused a security model with a privacy
| model. The thread above it was about privacy, not about
| security. There is no software distribution model
| anywhere that addresses what happens with my data on
| somebody's backend once sent, nor whether they can share
| data that I enter into an application over the internet,
| right?
| bbarnett wrote:
| So you pick one linux variant which doesn't follow my
| statements, then presume I'm conflating?
|
| Just because ubuntu is terrible, and uses snaps, does not
| mean all distros do. You should have taken the high road,
| and debated what I was discussing here.
|
| In Debian proper, you can read the source code of
| everything too. After all, old school distros like debian
| are they very reason you have such freedoms. They've been
| fighting the good fight for decades, working to keep OSS
| running pure, untarnished from closed licenses!
|
| The very idea that you think Linix distros are less
| audited than npm, and have less accessible source code,
| is, to me, incomprehensible. It also shows how little you
| know about OSS, while you use the very tools giants
| crafted for you.
|
| This doesn't make me mad, it makes me very, very sad.
| dahart wrote:
| > It also shows how little you know about OSS
|
| Snaps seemed like a fair example since you didn't
| specify, and Ubuntu is one of the largest distros by
| market share. I don't know what licensing has to do with
| your original point. I don't know what vanishingly small
| linux distros used by a tiny minority of technical people
| has to do with @scrollaway's point. I don't know how
| making assumptions about what I know to slide in an ad-
| hom zinger has to do with taking the high road.
|
| The point that you bypassed with your straw man in the
| first place is that once a software distribution
| ecosystem gets large enough, it's guaranteed to run on
| some amount of trust and gets too large to be auditable.
| This is why we have sandboxing, but ultimately even
| sandboxed apps when they get popular are a privacy
| threat, this is a problem Debian hasn't even remotely
| solved.
| justin66 wrote:
| > There's never any guarantee on either desktop or web unless
| you have very specific counter-measures in place (firewalls,
| airgapping, ...).
|
| Windows Firewall commonly serves this purpose even among
| users who are not familiar with terms like "countermeasures."
| The only problem with their system is, the warnings are so
| common that clicking through them becomes a reflex action.
| zamadatix wrote:
| It's a rare breed that runs Windows Firewall (or any
| firewall) in default deny outbound mode, I can't see more
| than 0.01% of users (i.e. no more than 1 in 10,000) being
| protected from this scenario with their current Windows
| Firewall setup.
| teawrecks wrote:
| Also, how many times have you launched an app for the first
| time on windows, use it flawlessly online for hours, and
| then close it only to find out that there was a firewall
| access request in the background the whole time. Failing to
| allow the app didn't make any difference at all.
| pjerem wrote:
| Ah this ! I always wondered what this window is asking me
| to authorize when the app is already downloading tons of
| things.
|
| I can't imagine it's just so flawed because it's been
| like that for years. There must be another reason I don't
| get.
| akmittal wrote:
| I actually use wasm codecs built by squoosh team. Squoosh is
| freaking awesome.
|
| Resize to particular size idea came, when online service asked
| me to upload image upto 25KB. I had to just keep on changing
| size till image became 25KB.
| mobilio wrote:
| Squoosh is WASM version of popular Mac App ImageOptim
| osrec wrote:
| Offline-level privacy is not guaranteed with native apps
| either, so please don't live under that incorrect notion!
|
| If you do not trust the developer of a web app, you can always
| disconnect from your Wi-Fi, use the app, close the tab and then
| reconnect to your Wi-Fi.
| quaintdev wrote:
| Well at least on Linux I can do something like below with
| native apps firejail --net=none firefox
|
| Disables internet for firefox
| extra88 wrote:
| So do that to the browser running the web app after you've
| downloaded it.
| jeroenhd wrote:
| Firewalls have been built into Windows for around 19 years
| now. There are tons of other options on all other platforms
| (thought Apple's platforms have more restrictions than
| others) to prevent outgoing connections. Mobile firewalls
| seem to use built-in VPN functionality and can often block
| per domain and per app as well.
|
| Web browsers don't come with such a firewall, and they need
| to be permitted by the system firewall to operate normally.
| It's technically possible to block outgoing requests with
| addons and configuration, but that's a pain to get right,
| especially compared to the simple toggle you can find in most
| OS firewalls.
| osrec wrote:
| You can throttle (including completely disable) the
| internet per tab via devtools in most modern browsers...
| [deleted]
| [deleted]
| xml wrote:
| Can't you just unplug the Ethernet cable/turn off the Wi-Fi
| module? (At least if the website was not lazy-loading
| resources.)
| sokoloff wrote:
| A _typical user_ might not be able to easily be sure, but using
| dev tools (or network monitoring tools), it's definitely
| possible to know.
| ir193 wrote:
| well done! i really wish more tasks can be done in browser.
|
| did you compile some c++ library into wasm or js is enough to do
| the job?
| akmittal wrote:
| I actually use wasm build by https://squoosh.app/ team.
| h2odragon wrote:
| or there's http://www.imagemagick.org/
| anaganisk wrote:
| [deleted]
| hoherd wrote:
| MacOS also included the Scriptable Image Processing System
| `sips`
|
| https://www.unix.com/man-page/osx/1/sips/
| akmittal wrote:
| Yes, Imagemagick is great and I love it.
|
| But most people are not comfortable using CLI or someone may
| just not want to install it for one off conversion. Also webapp
| works on smartphones, tablets or anything with browser, while
| Imagemagick does not.
|
| Imagemagick is ofcourse lot more feature rich and fast. If
| anyone is already comfortable using Imagemagick, webapp is not
| for them.
| s_gourichon wrote:
| These points are only weakly in favor of such a web app.
| Don't like CLI? Use gimp or similar. Don't want to install
| anything? On some OS it might make sense. On that OS consider
| Paint. It probably does not support webp, but if you're
| serious about webp you have tools. Smartphone/tablet? Is
| there even a need to do conversion on those? Privacy? Use an
| operating system that has some reputation, like Debian
| stable, not a web app. IMHO this web app is a nice exercice
| for its author.
| karanbhangui wrote:
| HN feedback has become cancer. OP, this site is great, and
| even as a highly technical user, I'd use this site in a
| heart beat. Thank you!
| natch wrote:
| "Cancer" is a little melodramatic.
|
| Negative feedback (including yours, and mine, and that of
| those who may reply to this disagreeing with me) has its
| place.
|
| I've seen forums (fora?) where almost everyone is
| exclusively positive (like some reddit look-what-I-made
| topics), and that well-intentioned behavior can be pretty
| unhelpful if you're trying to get different perspectives
| on your own project.
|
| Yet there are always people there who bend over backwards
| to make someone feel bad if the person was (sarcasm: rude
| enough) to suggest there may be a way to improve
| something. Enforcing the positivity-only social norms.
|
| I'm glad that HN, by contrast, stands out as having more
| free range thinkers who tell it like it is.
| poisonborz wrote:
| This is wholly true, but the comment above makes absurd
| claims ("Smartphone/tablet? No one converts there! Want
| privacy? Use Debian!"), bending backwards to say
| something negative.
| bbarnett wrote:
| It may seem negative, but it is also true.
|
| You cannot have privacy with web apps. At all. Ever.
| poisonborz wrote:
| This is so much of a HN comment that I wonder if it's
| satire or written by a bot.
| marginalia_nu wrote:
| I sometimes think we're approaching a future where people
| will learn to bake bread by scraping the topping off frozen
| pizza unless we make an effort to educate users on how to use
| the tools they have at their disposal.
| KaoruAoiShiho wrote:
| Is there an open sourced version of this so I can process the
| images the user uploads first before sending it to s3 thus saving
| space?
| akmittal wrote:
| I have published to npm https://www.npmjs.com/package/optimg-
| wasm Sorry there is no documentation for now. Will be doing it
| first thing tomorrow (IST)
| KaoruAoiShiho wrote:
| Thank you, awesome.
| kretaceous wrote:
| Oh heavens, this is really neat! Thank you! I love Squoosh but I
| often have a multiple photos to compress to WEBP.
|
| On a similar note, does anyone know similar lightweight
| web/desktop apps for basic photo editing, specifically, resize,
| conversion, crop, color overlay, etc. I use Photopea[0] on Linux
| but I still feel I could go lighter.
|
| [0]: https://photopea.com
| jakub_g wrote:
| Check https://edit.photo - it's similar to popular Android
| native mobile apps.
| akmittal wrote:
| There are lots of solutions already, but most solutions have too
| many ads or they process on server(privacy concern).
|
| Webutils convert all images on client using webassembly.
| kingcharles wrote:
| Webassembly is going to be fantastic for building a lot of
| similar apps like this that avoid the server. It also keeps
| costs of the developer to a minimum because huge data files are
| not being transferred to/fro.
___________________________________________________________________
(page generated 2022-01-23 23:01 UTC)