Unbelievable... :exploding_head: I'm working righ...
# random
s
Unbelievable... 🤯 I'm working right now on HEIC support for my metadata parsing library and got it working so far with my iPhone HEIC from my own device. Now I took a HEIC test image with my wifes Samsung Galaxy 21 FE and figured out that the meta box (containing metadata) comes last after the mdat box (containing actual image data). It's specified that meta should come first and at least Apple adheres to that. This is now the same sh*t as with WebP where metadata come last, too. 🙄 You might think it doesn't matter, but for me this is important, because Ashampoo Photos also supports cloud hosted images and because the poor metadata provided by OneDrive & Dropbox API (that's another story) is not enough I actually use to read the headers and let my library read as much from a Ktor stream as it needs to get all metadata. For example JPEG metadata is limited to 64 kb, but usually it only takes around 10 kb from the beginning of the file to get all information I need. WebP would require me to download the whole file to parse it's metadata and users of Ashampoo Photos might not accept this as it takes long and has a lot of traffic. I'm disappointed to learn that Samsung did this. I needed a place to vent about Samsung not doing this properly and I sincerely hope that's not the case with all Android HEICs. Thank you for your attention. 😄
hex.png
y
If it's done locally, would it take as long/would the traffic matter? "uploading" a few MB locally should be fine, right? I haven't done web in a while though
That is really frustrating though when they could've so easily complied with the standard, but they didn't
👍 1
s
If it's done locally, would it take as long/would the traffic matter?
It can't be done locally. I don't understand what you mean. 🤔 Ashampoo Photos is a photo organizer app where people can connect their Dropbox or OneDrive cloud accounts. They may have HEIC files on that. Of course I have no server-side access to those files as the credentials are only present on the client. I need to extract the metadata of those files to properly display the image with it's date taken, location, keywords, etc. Downloading the whole cloud drive (people might have many GB of images there) isn't the solution. My "read the headers" solution works fine for JPG and PNG.
y
I mean like the app itself processes the images locally, right? Hence, you might have to download a few MB for an image, but you won't be limited by any upload speeds. That's assuming that users only analyse one photo at a time though. However, if Ashampoo Photos goes through their entire photo library, then yeah that's not feasible at all and is really frustrating.
s
Yes, it's only download, but it's usually the entire cloud drive. The app provides browsing and searching all images. If it was an app that processes the full image anyway (like an photo editing software) this wouldn't matter much.
y
I wonder if there's something that can be done with Google Apps script to like go through all the images and extract the metadata as a pre-processing step. It would run on Google servers so it might be faster, but ofc setting up an Apps script is a non-trivial task for a user lol
s
I did not grasp the decision for metadata at the end in the first place. For RIFF/WebP it's even specified this way.
but ofc setting up an Apps script is a non-trivial task for a user lol
This won't happen ^^ Ashampoo software aims to be as simple as possible. The user base is also mostly 60+. 😄 The selling point is being easier to use than competitors. The scripts go in the opposite direction 😉