Comment by iamcalledrob
20 hours ago
Similarly, the native Android photo picker strips the original filename. This causes daily customer support issues, where people keep asking the app developer why they're renaming their files.
https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).
Obviously an image picker shouldn't leak filenames... The filename is a property of the directory entry storing the file storing the image. The image picker only grants access to the image, not to directories, directory entries or files.
If you want filenames, you need to request access to a directory, not to an image
"Obviously"
There are plenty of use cases where the filename is relevant (and many, many people intentionally use the image name for sorting / cataloging).
I have had more cases where I was very surprised that the local filename I used for something became part of its record when I uploaded it somewhere. (For instance, uploading an Mp3 using Discord on desktop web.)
There are many, many more cases where the user doesn’t expect the name to become public when he sends a photo. If I send you a photo of a friend that doesn’t mean I want you to know his name (which is the name I gave the file when I saved it)
2 replies →
It's not "obvious" at all, since it's contextual, it depends on the purpose and semantics of whatever service you're uploading the photo to.
Depending on how it'll be used next, not only can the current filename be important, I may even want to give something a custom filename with more data than before.
The path is different than the filename though. If I want to find duplicates, it will be impossible if the filename changes. In my use case
/User/user/Images/20240110/happy_birthday.jpg
and
/User/user/Desktop/happy_birthday.jpg
are the same image.
> it will be impossible if the filename changes.
Not impossible, just different and arguably better - comparing hashes is a better tool for finding duplicates.
2 replies →
If your camera (or phone) uses the DCF standard [0], you will eventually end up with duplicates when you hit IMG_9999.JPG and it loops around to IMG_0001.JPG. Filename alone is an unreliable indicator.
[0]: https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...
3 replies →
> If I want to find duplicates, it will be impossible if the filename changes.
Depends on what is meant by a "duplicate." It would be a good idea to get a checksum of the file, which can detect exact data duplicates, but not something where metadata is removed or if the image was rescaled. Perceptual hashing is more expensive but is better distinguish matches between rescaled or cropped images.
https://en.wikipedia.org/wiki/Perceptual_hashing
This a very weird set of choices by Google. How many users are uploading photos from their camera to their phone so they can then upload them from the phone to the web?
I bet almost 100% of photo uploads using the default Android photo picker, or the default Android web browser, are of photos that were taken with the default Android camera app. If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
My phone: my private space. Anything in the browser: not my private space.
I want exactly that: the OS to translate between that boundary with a sane default. It’s unavoidable to have cases where this is inconvenient or irritating.
I don’t even know on iPhone how files are named “internally” (nor do I care), since I do not access the native file system or even file format but in 99% of all use cases come in contact only with the exported JPEGs. I do want to see all my photos on a map based on the location they were taken, and I want a timestamp. Locally. Not when I share a photo with a third party.
It is not just a default when it is the only option.
The word default is more appropriately used when the decision can be changed to something the user finds more suitable for their usecase
> Anything in the browser: not my private space.
Google’s main business is ads, ie running hostile code on your machine.
> If Google feels that the location tags and filenames are unacceptably invasive, it can stop writing them that way.
Something can be "not invasive" when only done locally, but turn out to be a bad idea when you share publicly. Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
Definitely. I want to be able to search my Google Photos for "Berlin" and get me all the pictures I took there.
> Not hard to imagine a lot of users want to organize their libraries by location in a easy way, but still not share the location of every photo they share online.
The location isn't just embedded in the EXIF tags. It's also embedded in the visual content.
I imagine people will get tired of their image uploads being blacked out pretty quickly.
> How many users are uploading photos from their camera to their phone so they can then upload them from the phone to the web?
To _their phone_ specifically? Probably almost nobody. But to their Google/Apple Photos library?
A lot, if not most of people who use DSLRs and other point-and-shoot cameras. Most people want a single library of photos, not segregated based on which device they shot it on.
I use to send pictures over the camera wifi from my Sony W500 to my phone. The main purpose is backup (think I'm in the middle of nowhere or with little internet for days) and then to send them to friends with WhatsApp. If I'm at home I pull the SD card and read it from my laptop. It's quicker.
I do it all the time for different reasons:
- have a local backup - being able to see them from a larger screen - being able to share them - sync them to home while I am away
I don't upload anything to google photos or apple cloud.
Yep, and having location data is really useful for organizing said photos.
I think it's really neat Google Photos lets you see all photos taken at a particular location. One of my pet peeves is when friends share photos with me that we took together at a gathering and only the ones I took with my phone show up in that list unless I manually add location data. (Inaccurate timestamps are an even more annoying related issue.)