Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPS tags on mobile devices #64

Open
m-yakymenko opened this issue Jun 6, 2021 · 7 comments
Open

GPS tags on mobile devices #64

m-yakymenko opened this issue Jun 6, 2021 · 7 comments

Comments

@m-yakymenko
Copy link

m-yakymenko commented Jun 6, 2021

Hello! I have problem with parse GPS tags on mobile devices. On destop all working well.
image

But with same photo, on mobile I can not parse no one GPS tags.
image

How can i get this tags? Here https://mutiny.cz/exifr/ all working well.
I had this problem with other exif-programs like exif-js.
Thank you

@MikeKovarik
Copy link
Owner

Hello. Can you describe the problem a little more?
Is it the same code/app, same photo, same actions, but different result on phone?
Could you share the photo, or the photo? Or anything that could help me find out what's wrong.
Thanks

@m-yakymenko
Copy link
Author

m-yakymenko commented Jun 6, 2021

Yes, I can! While i making test projects, I had a suspicion on my React.
Firstly what I do, its vanilla html projects and he works well on all platforms. https://github.com/gonzika/test (photo for testing with gps tags here)
Then I trying to integrate different ways in my react-projects, i including your library from CDN (normaly it installed from npm), i even turning off all rendering, but it does not help.

Test projects where I can retry bug here https://codepen.io/gonzika/pen/QWprXdK
You can see, two different ways (i thinked what its babel's guilt, but libray from CDN and logic in index's <script> does not work too.
...Without react does not work too https://codepen.io/gonzika/pen/VwpxJgZ

@bdk0172
Copy link

bdk0172 commented Jul 2, 2021

Having a similar issue in a React project where I'm using Capacitor Camera plugin in conjunction with exifr. I've got it set up to create an Android project and to verify that exifr was working I have 2 alerts set up, one to display make and model and another to display lat/lon. When I run it directly from VS Code as a PWA I can attach an image that I've transferred from my Android phone and it will display the correct lat/lon in the alert. When I run it on my phone through Android Studio and take a picture, I get the make and model alert, but not the lat/long alert I'm assuming because it's getting an error. When I attach the same photo that gave me the correct lat/lon in PWA, it gives me "0/0" when running on my phone. I'm guessing there's a location permissions issue that needs to be set in the Androidmanifest.xml, but I haven't figured that out yet.

@19th
Copy link

19th commented Jul 6, 2021

I have a similar issue, but the problem is not in the library, but in the device. Android and iOS strips down geolocation data on file upload. On Android - if I choose to browse files with another app, then geolocation data is preserved.

@Ivwc
Copy link

Ivwc commented Apr 18, 2022

you can try input without accept.
on Android is work

@josephfrazier
Copy link

I'm experiencing a similar issue, and I think I've been able to rule out Android metadata-stripping as the cause. I may try to put together a minimal test case to make debugging easier, but I've starting describing my problem and work-in-progress to fix it at josephfrazier/reported-web#360, including a bit where I'm md5sum'ing the image uploaded by the browser, and getting the same result on both desktop and mobile.

josephfrazier added a commit to josephfrazier/reported-web that referenced this issue Aug 22, 2022
This fixes #361. Here's the whole saga:

Here's an example image that works on desktop, but not mobile: https://photos.app.goo.gl/AcEfSrYTMqgp6JfX8

Using [`eruda`](https://www.npmjs.com/package/eruda) to see the JS console with [this branch](#360), I see this on desktop:

```js
Extracted GPS latitude/longitude location from EXIF metadata Object {latitude: 40.717019444444446, longitude: -73.99356388888889}
```

but this on mobile:

```js
Extracted GPS latitude/longitude location from EXIF metadata Object {latitude: "NaN", longitude: "NaN"}
```

---

Seems like this issue might be within the `exifr` library: https://github.com/MikeKovarik/exifr

---

To rule out the possibility that the EXIF metadata is getting stripped when uploaded from my phone, [I logged out the md5sum of the image right before parsing the metadata](4208a1b), and it is `441018525208457705bf09a8ee3c1093` on both desktop and mobile, yet the `GPSLatitude` and `GPSLongitude` arrays are `[NaN, NaN, NaN]` on mobile, but `[40, 43, 1.27]`and `[73, 59, 36.83]` on desktop, respectively.

---

related exifr issue: MikeKovarik/exifr#64

---

> [I logged out the md5sum of the image right before parsing the metadata](4208a1b), and it is `441018525208457705bf09a8ee3c1093` on both desktop and mobile

Ugh, it looks like the package I chose to use might have a bug that causes this value to show up for ArrayBuffers: pvorb/node-md5#49

---

If I switch to [object-hash](https://github.com/puleos/object-hash), I get a sha1 of `b287c307cd89cfd2ce779b975b961b4824f2714a` on desktop, but it crashes on my phone, so I guess I need something less resource-intensive...

---

Seems like Android is stripping GPS from EXIF after all, when the `<input>` element has an `accept` attribute specifying images, but removing the attribute does the trick for me.
@josephfrazier
Copy link

josephfrazier commented Mar 2, 2023

I was just revisiting this issue, and wanted to confirm for anyone else who ends up here that removing the accept attribute from the <input> element worked for me, as @Ivwc said above. It was due to Android stripping metadata after all, and my previous comment was mistaken (I encountered this bug in the md5 sum package I was using)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants