Geotag function for photographers

Béla Nagy shared this idea 3 years ago
Declined

Hi! I have a small suggestion for the developer team. There are lots of photographers (including me) who would like to be able to geotag their photos (taken with their cameras, not the phone).

If Locus Map is running anyway, registering a track - all we need is an app (running from your servers, or offline on a pc) which can merge the coordinates of the recorded points into the EXIF of the photos - based on timestamps. There are apps for this (for example: Geotag Photos Pro - I'm using it) - but your app is running anyway and it would be much more useful to have this function integrated as well -- I would even gladly pay for it!

Comments (32)

photo
2

I'm using an external app as well but actually would like it to stay that way as in my opinion, this use case is too far off Locus' area of expertise. The app would become too convoluted if features like these made it into the main app. An extension might be an option, though.

photo
1

I think you can use locus to create a gpx file. Import the gpx in your software and syncronise the photos. All you need is to keep time on your camera sync with the mobile.

I usually do this with locus and base camp of Garmin, or with a script that uses exifftools that is faster than garmin.

I think locus can not do all the job.

photo
1

In the beta version of Locus became possible to display geotagged photos. It would be nice to add also this feature

photo
2

I don't think this is a problem that Locus should solve.

First, I don't want to have to copy gigabytes of data to my phone just to perform geotagging.

Second, there are many desktop applications dedicated to this which would run on the way more powerful hardware of your desktop computer.


I think what Lorenzo said is true. Record your track, preferably take a picture of the current GPS status with your camera to compute the time offset and just use a desktop application.

photo
2

While I am always eager to get more power - and usability (like a standard panel for the left side) - from Locus, here I agree that there is no chance for Locus to match functions line "GeoSetter beta" e.g. is offering.

photo
1

Hello guys,


thank you for a valuable feedback, I can only agree with "negative" opinions. In this case - idea declined.


Btw. Jens, to synchronize photos on PC, I once created a "QR Code generator" (at bottom in list of functions), that generate QR code with current device time, that may be later used for some automatic sync of track & photos. How to do this automatic sync - don't know. Clever guys anyway usually figure out this task ;).

photo
1

I probably did not explain clearly enough. There is no copying involved. The app (Locus in this case) should record the track (exactly how it is recording now) and the photos could be geotagged based on timestamps with a desktop extension. On the other hand if there is no demand for this - I can understand it wont be developed. I can still use Geotag Photos Pro - as I did until now.

photo
1

I think I understand the point. But this geotagging still needs a few steps - record a track (Locus), take the photos (camera), geotag them (some other software - Locus Desktop, or other)? Does it make sense to create extra software when there is already many of them and another one do not bring anything special?


I'm not skilled in this area, so I just guess.

photo
1

If Menion agree I can send my procedure for geotagging photos:

Locus, for track generation and export to GPX format.

A command line to use with exfitool (freesoftware)

Optional

reg code to easly implement geotagging_Foto script directly with right-click menu on the windows folder and into the folder.

photo
2

Try GeoSetter beta - it uses exiftool, but gives you much more power to manage anomalies.

photo
1

I have to say that geotagging photos in Locus Pro might be extremely useful tool. My camera allows uploading photos via wifi to mobile phone and this possibility is really nice: no cable, no desktop, just few minutes to upload daily photos - to view them more comfortably (on bigger screen) or just to make extra copy of camera memory card. Of course it is still possible to upload those photos to desktop, export tracks from Locus to gpx and then use exiftool to geotag photos, but it is relatively complicated task. I dream about menu option in Locus Map, which simplifies this task and just geotag all photos with timestamp fitting current track. Additionaly this option would be very nice for Strava users, because this service accepts geotag only from photos uploaded via mobile phone. Now Strava users who want to upload photos better than those made by mobile phone have to accept that those photos are not shown on activity map. So users who record track with Locus Map (and export it to strava for sharing, analysing, etc) may get BETTER result than plain strava app users. Sounds tempting? :-)

photo
1

Hello Jarosław,

thanks for the feedback. Understand your usecase anyway I still think as I wrote before. Such feature is little out of the general hike & bike usage of Locus Map and it will also duplicate the functionality of many applications available in the world. Thanks for understanding.

photo
1

I understand your point of view but I can't agree that there are many applications with such functionality. All I can find are desktop applications and all them needs also gpx file to be exported from Locus. This is not a problem when you work with thosands photos taken on larger journey, but it is little too much when all you want is just upload few fine photos taken in one day trip. Locus can upload to strava directly and this is why I still use Locus not only to use good offline maps, but also to record tracks. You might say that all I need to join Locus and Strava is an export to gpx file function in Locus, but instead you've made better functionality: direct upload to Strava. And it is great! Such "flexibilty" is, in my opinion, the power of Locus. I would be delighted if you can make geotaging function embeded in Locus.

photo
1

You should use automation tools to do this.


I guess the pain in this process is to manually search and export the track into an GPX file because locus does not store GPX tracks in folders.

Would be nice to improve track database access.


@Menion would it be possible to write a SQL statement for selecting point and track ids beween 2 timestamps? This would allow addon developers to implement all kinds of track database management like geotag photos based on locus track database. Or like searching a track of a certain date. Point information are usefull for geotagging and track information are usefull to search tracks or to tell user existance of multible tracks with same timestamp.


Currently your api does only allow access a whole tracks based on an unknown trackid:

https://github.com/asamm/locus-api/blob/7f8f0f8b16c93fe69d501e6ad926127393b78360/locus-api-android/src/main/java/locus/api/android/ActionBasics.kt#L757


Please could you tell me which locus content uris are exposed to other applications? Content resolver should be able to do all the nessasarry filtering. I would to do some thing like this based on your point table.


final String[] projection = { People._ID, People.NAME, People.NUMBER };
cursor = resolver.query(People.CONTENT_URI, projection, People.NAME + " LIKE ?", new String[] {  "Max%" }, null);
Please could you provide an content uri and the following fields:

point lan

point lat

trackid


If joins are possible track name would be nice too, but in worst case I will just create another query.


After we did implement a point query, it would be very easy to use automation tools to geotag photos or to search tracks.

photo
photo
1

Instead of implementing this into locus it would be great to make addon developers able to access locus point database: https://help.locusmap.eu/topic/api-access-to-recorded-point-database

photo
1

This whole write data into images topic is very android version specific.

  • Below Android K: you can do anything
  • Since K: you need permissions to write anything on external SD
  • exceptions since K: for some devices you are not allowed to write anything to external SD, even with permission you can only access your own package directory
  • between L and P it was a lot more easy, you could place location into media database, but this feature got removed with Q
  • and with upcomming Q: each file action need users approval, maybe after switching to Q you can write to any files again like before KITKAT, because you are able to request for user approval.


There is only one way to solve the problem for alle Android Versions:

  • Kopie Fotos into Locus Addon Directory or into other places where the app is able to write to
  • you can't automatically delete the original, you will get your fotos 2 times in your galery. One with location in app directory and the original in any other directory.

@Jarosław Strzałkowski

@Lorenzo Cassani

@Béla Nagy

@Евгений Прокопенко

@[ˈpʌtaˌfɔʏfɔʏ]

Would you like it if geotagging will copy all your fotos into a specific folder /[anyexternalstorage]/Android/data/menion.android.locus/files ?


Other impelementations would be less stable because there will be devices which can't write anywere. Many devices can write anyware depending on manufactor and android version, but not all of them.


I have something like this in mind: "App is not allowed to write into selected photos/folder. Would you like to copy them? This can take a while."

And then a selection of possible places to put the copies.


I did already implement a android version dependend solutions for power users which does watch folder changes and automatically geotags new files depending on all available locus tracks. But of curse such an "unstable" version need device specific maintenence which is only worthwhile for power users. This solution is based on tasker which make it very easy to tweak each stepp in the whole geotagging process to fit device requirements and accuracy requirements. It would be a nightmare to implement an UI for all 10-20 tweakable places, which means tasker is the way to go.

photo
1

Sounds great! My app for fetching photos from external camera via wifi allows to specify directory for uploaded photos - it may be anywhere so it may be also /[anyexternalstorage]/Android/data/menion.android.locus/files.

photo
1

My Samsung S4 for example allow write anywere onto external storage 1 but don't allow anything on external storage 2 which took very long to discover because this strange behaivor isn't documented.


I guess you are interested in the power user feature "watch folder change"? This has less interactions with locus because it is way more custom and would get done first.

Stable solution with deeper locus integration will come later.

photo
photo
1

I did add an example solution for this problem

https://github.com/Falcosc/locus-addon-tasker/wiki/Examples#geotagging

photo
1

Great work! I've just bought Tasker & Locus tasker extension and now I'm looking into your "example" code. It's not easy, but seems to be possible to use. Thank you!

photo
1

If it is to complicated, I still work on the Locus Maps solution:


  1. open tracks
  2. select your track
  3. click on share -> Geotag with Locus Tasker Addon
  4. Select your folder
  5. wait until notification process bar is done

This isn't full automated like tasker watch folder, but it is more easy and better supported by Locus API.

I guess this will be released in 1-2 Weeks with a new Locus Tasker Addon version.

photo
photo
1

I have problem with task "Improve Geotag" - as on attached snapshot. Without proper indexes I can not even think about success in geotagging - with my collection of tracks work for only one photo lasts many minutes (still waiting for end). I've checked tmp directory and sql file copy exists in this directory.

photo
1

How large is your tracks.db file? You may have to manually create index because of unknown limitations of taskers sqllite connector.


Would be nice if you could find a way to share your db in private over Dropbox. Please create an issue at my own issue board at github.

photo
1

I did add error output for you and I did extent the task with multible work folders in case of device specific permission problems.

You need to download and import it again: https://github.com/Falcosc/locus-addon-tasker/wiki/Examples#Geotagging


The non power user solution for UI with manual track selection is still in work.

photo
photo
1

UI integrated addon solution for Locus Maps Geotagging is ready for Beta Testing:

https://play.google.com/apps/testing/falcosc.locus.addon.tasker


On Track details screen will be a new option in share menu.

photo
1

First test (for one photo manually "touched") looks OK ! Great!


Is it possible to add any message after finished geotagging? Eg. message with list/number of photos affected? Just to know if anything happened.

photo
1

Currently you get only notification during processing to follow progress bar. And on error to review errors.


But you are right, success usecase is needed as notification, too.


Maybe even with a share button to send result direct to the next app in your mobile fotos workflow https://developer.android.com/reference/android/content/Intent.html#ACTION_SEND_MULTIPLE

photo
1

Today I've made a real test and everything went good: all 43 photos made while my 120km bike trip with son were geotagged correctly. That's wonderful!

But is it possible to process images in order? Eg. filename order? Now images are geotagged in random order what makes a great mess in eg. images gallery app (in every app which uses file modification time to order photos).

photo
1

It's processed on multible cores to speed it up by 20 to 50%

list ist ordered by last modification to start with newst files first. File Access Read and write cache ist handled by os.


Would you think filename order and seqentiell processing is worth a 20 to 50% slower processing time?


That is the big reason why I dont like non tasker solutions, you have to choose a way to do it because you cant make everything configureable.

photo
1

I will try something special:


  1. search files which match the track in parallel mode
  2. close files which don't have any matching Location but don't close files which got a location because we need to block any changes and more importand: we don't want to parse all EXIF tags again. I hope https://developer.android.com/reference/android/os/ParcelFileDescriptor#detachFd() will allow me to hold the open file.
  3. sort all files which are still open with parallel processing by actuall Recording time (this is much better then last modification and is only possible because we did already do the expensive exif parsing)
  4. write exif changes sequentiel

There is only one issue here: android can hold many thousand or even million of open files. But one app is only allowed to keep 1024 open files. This should be no issue because we close all files which don't match to track but I still need to implement a warning that this functionallity is not designed for very large amount of photos. For example you can't abort the process by design (to complicated to implement this very rare usecase)

photo
1

if detachFd will work as expected I could count open files and if we got close to limit I could write exif data during parallel processing (onordered file modifcations) to keep the list of open files for step 3 small.


In theory this all should be even faster because

read and write parallel should be slower then

read parallel and write sequentiel

because we may have read cache but propably no or not enoght write cache


I hope the drawback of holding many open files or detaching filedescriptors (IoUtils.acquireRawFd) is not to expensive


I just know that read and write sequentiel is the slowest solution because it goes like this:

  1. waiting for read next file from storage, CPU is idle (wasting time)
  2. do some parsing or location matching, waiting for CPU, storage is idle (wasting time)
  3. write to storage, CPU is idle (wasting time)

photo
photo
1

Of course it would be better to process 50% slower but without problems. The whole process seems to last only few seconds so 50% more is just nothing.

niedz., 16 cze 2019, 22:41 użytkownik Locus Map <locus.map@asamm.com> napisał:

photo
1

Would it make sense to order by exif time instead of order by name?

For example you have files from multible cameras in your folder.

photo
photo
1

It would be ideal choice! I didn't know if it is possible (and not too complicated).

W dniu 17.06.2019 o 08:27, Locus Map pisze:

photo
1

Processing images in order based on exif time would be fantastic feature! It would fix also problematic behavior of camera app which uploades photos in reverse order, so browsing them eg. in google photos needs special attention: order of photos changes after some, random time (google processes exif data in background and then reorders photos). I would be delighted if you could make this feature before my trip to Greece in next week :-)

photo
1

My new beta has everything:

- compatibility to latest android Q write permission enforcements

- support for seekable writeable cloud storage files

- custom time adjustments based on selectable example file

- background processing to keep you able to use your device

- multicore exif parsing

- multicore binary search of nearest location

- realtime monitoring of operating system policies for maximum open files

- out of order processing in case of OS policy violation

- caching of already parsed matching photos to process them later in order

- reduced battery drain and processing time by keep processed files meta data in memory

- skip of non matching photos

- sorting of matching photos by exif recording date

- sequentially progressing of exif writes to get modification time in order of exif time and to benefit from higher sequential sd card performance

- ability to skip exotic errors to keep processing good photos

- IO depending progressbar segmenting (33% for read operation and 66% for copy and write)

- detailed error messages for each step in processing

- realtime monitoring of skipped files

- reporting and exporting of detailed error messages of skipped files

- ability to share successful geotagged photos

Totally over the top :D

photo
1

Works absolutely perfect! You are great! Thank you very much. Good work!

I see no progress bar, but every else is just as needed.

wt., 18 cze 2019, 20:36 użytkownik Locus Map <locus.map@asamm.com> napisał:

photo
1

There is one problem: you are too fast :-) When google photos app encounters situation when two photos has exactly the same time, it skips those photos in transfer. In app those photos are shown, but app can not upload them.

That's sad but I have to ask you to slow down a little to avoid images with exactly the same modification time :-(

photo
1

Well, even very cheap cameras can shoot 5 picture per second. And Storage is fast enoght to store more then 2 photos per second. If this is really a problem, then google photos is just broken, Would make sense to implement a save delay such to support such a broken app.

You should create a Tasker task to copy your files with delay and you should report this bug to google.


Progressbar is in your notification list because it's a background job.

Are you sure that google photo is broken? Maybe there is just a scan media missing? Try to run a Scan Media Tasker task and if this does solve it, then I need to create a scan media intent in the geotagging.

photo
1

Maybe your photos are just missing some exif data.


https://support.google.com/photos/forum/AAAAzDQC9KEVa-Wl9cOl9g/?hl=en&msgid=JIHdTOL4BAAJ&gpf=d/msg/photos/Va-Wl9cOl9g/JIHdTOL4BAAJ


Accordoing to this page you may need to set exif DateTimeOriginal.


Next version will

  • set GPS Date Time if missing based on Locus GPS DateTime
  • set originial date time if missng based on DateTime
  • set date time if missing based on DateTimeOriginal
  • have a checkbox "write time offset to exif"
  • fire scan media intent

If this will not work, you have to stick to the power user solution where you could configure everything according to your taste with tasker. The UI driven geotag inside of Locus Map will be more common with much less customizations.

photo
photo
1

Series of photos are recognised (by exif data?) and treated by google in special way: presented in albums as one shot but with extra option. So this situation is totally different - two separate photes in the same second. I suppose that this bug is a result of:

"Google Photos can smartly detect duplicate photos and will skip uploading them if a copy has been uploaded previously. The file names of your photos can be different and they can reside in different folders of your hard disk but the service will still recognize the duplicates and remove them from the upload queue."

but this behaviour is definitely a bug - even when I manually force those photos to upload nothing happens. The only way to fix it it to purge all google app data - after many hours of resync all photos were uploaded including those "duplicates" (first time it happend I thought that it is random mistake so I've made such hard fix).

I may make a issue for google (I pay for their service, I may try to find how) but I have no hope that it might be fixed in any rational time :-(

Problem affects only 10-30% of photos so necessary slow down is really small. Please...

W dniu 18.06.2019 o 23:28, Locus Map pisze:

photo
1

I suppose that this is not that problem - when I've sent "problematic" photo via email to desktop and then uploaded to google photos this worked. In this test exif data was untouched - the only thing what was changed is file modification time.

wt., 18 cze 2019, 23:28 użytkownik Locus Map <locus.map@asamm.com> napisał:

photo
1

Maybre the bug get resolved if we set all datetime exif fields. Maybe the dupplication check does look on some of them because it is silly to just look to midification time. I guess "last modification" check is just a fallback because your photos are missing importand exif datetime fields.


Please can you tell which exif fields are populated for the file which got detected as dupplicate?

Can you ask google which exif fields need to be set to define a non dupplicate photo?

photo
1

First example of photo for which upload from app failed (but succeeded from web interface on desktop):

File Name : DSC00701.JPG

Directory : .

File Size : 5.4 MB

File Modification Date/Time : 2019:06:17 10:26:26+02:00

File Access Date/Time : 2019:06:17 10:26:28+02:00

File Inode Change Date/Time : 2019:06:17 10:26:26+02:00

File Permissions : rw-rw-r--

File Type : JPEG

File Type Extension : jpg

MIME Type : image/jpeg

Exif Byte Order : Little-endian (Intel, II)

Make : SONY

Orientation : Horizontal (normal)

Modify Date : 2019:06:16 14:18:39

GPS Latitude Ref : North

GPS Longitude Ref : East

Y Resolution : 350

X Resolution : 350

Camera Model Name : DSC-WX350

Software : DSC-WX350 v2.00

Image Description :

Y Cb Cr Positioning : Co-sited

Exif Version : 0230

Scene Type : Directly photographed

Exposure Compensation : 0

Exposure Program : Program AE

Color Space : sRGB

Max Aperture Value : 5.6

Exif Image Height : 3672

Brightness Value : 6.91171875

Date/Time Original : 2019:06:16 14:18:39

Flashpix Version : 0100

Warning : [minor] Possibly incorrect maker notes offsets (fix by -93?)

Rating : 0

Brightness : 0

Long Exposure Noise Reduction : On (unused)

High ISO Noise Reduction : Normal

HDR : Off; Uncorrected image

WB Shift AB GM : 0 553648128

Face Info Offset : 0

Sony Date Time :

Sony Image Height : 0

Sony Image Width : 0

Faces Detected : 0

Face Info Length : 0

Meta Version :

Creative Style :

Color Temperature : Auto

Color Compensation Filter : 0

Scene Mode : Auto

Zone Matching : ISO Setting Used

Dynamic Range Optimizer : Auto

Image Stabilization : On

Color Mode : Standard

Full Image Size : 0x14

Preview Image Size : 0x1

File Format : ARW 2.3.1

Quality : Fine

Flash Exposure Compensation : -1.354767065e-09

White Balance Fine Tune : 0

White Balance : Auto

Sony Model ID : Unknown (0)

Multi Frame Noise Reduction : Off

Picture Effect : Off

Soft Skin Effect : Off

Vignetting Correction : n/a

Lateral Chromatic Aberration : n/a

Distortion Correction Setting : n/a

Lens Spec : Unknown (01 0 100 0 0 01)

Auto Portrait Framed : No

Flash Action : Did not fire

Electronic Front Curtain Shutter: Off

Multi Frame NR Effect : Normal

Macro : Off

AF Area Mode : Default

AF Illuminator : Off

JPEG Quality : Fine

Flash Level : Normal

Release Mode : Normal

Sequence Number : Single

Anti-Blur : On (Shooting)

High ISO Noise Reduction 2 : Normal

Intelligent Auto : On

Focus Mode : Unknown (0x58)

Camera Temperature : 0 C

Release Mode 2 : Normal

Release Mode 3 : Bracketing

Self Timer : Unknown (3)

Flash Mode : Autoflash

Stops Above Base ISO : 11.0

HDR Setting : Off

Picture Profile : Unknown (21)

Picture Effect 2 : Unknown (218)

Quality 2 : Unknown (3)

WB RGB Levels : 7716 40620 35

Min Focal Length : 1228.8 mm

Sony ISO : 6553600

Interoperability Index : R98 - DCF basic file (sRGB)

Custom Rendered : Normal

Exposure Mode : Auto

Exposure Time : 1/250

Flash : Off, Did not fire

F Number : 5.6

User Comment :

Exif Image Width : 4896

Saturation : Normal

ISO : 500

Components Configuration : Y, Cb, Cr, -

File Source : Digital Camera

Compressed Bits Per Pixel : 2

Contrast : Normal

Sharpness : Normal

Digital Zoom Ratio : 1

Create Date : 2019:06:16 14:18:39

Metering Mode : Multi-segment

Focal Length : 42.3 mm

Scene Capture Type : Standard

Light Source : Unknown

Resolution Unit : inches

Compression : JPEG (old-style)

Thumbnail Offset : 31935

Thumbnail Length : 8779

MPF Version : 0100

Number Of Images : 2

MP Image Flags : Dependent child image

MP Image Format : JPEG

MP Image Type : Large Thumbnail (full HD equivalent)

MP Image Length : 553531

MP Image Start : 5144591

Dependent Image 1 Entry Number : 0

Dependent Image 2 Entry Number : 0

Image Width : 4896

Image Height : 3672

Encoding Process : Baseline DCT, Huffman coding

Bits Per Sample : 8

Color Components : 3

Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1)

Aperture : 5.6

Blue Balance : 0.000862

GPS Latitude : 49 deg 51' 12.43" N

GPS Longitude : 19 deg 42' 33.76" E

GPS Position : 49 deg 51' 12.43" N, 19 deg 42' 33.76" E

Image Size : 4896x3672

Preview Image : (Binary data 553531 bytes, use -b option to extract)

Megapixels : 18.0

Red Balance : 0.189956

Shutter Speed : 1/250

Thumbnail Image : (Binary data 8779 bytes, use -b option to extract)

Focal Length : 42.3 mm

Light Value : 10.6


Another example (from yesterday evening test):

File Name : DSC00721.JPG

Directory : .

File Size : 5.9 MB

File Modification Date/Time : 2019:06:19 12:21:51+02:00

File Access Date/Time : 2019:06:19 12:21:51+02:00

File Inode Change Date/Time : 2019:06:19 12:21:51+02:00

File Permissions : rw-rw-r--

File Type : JPEG

File Type Extension : jpg

MIME Type : image/jpeg

Exif Byte Order : Little-endian (Intel, II)

Make : SONY

Orientation : Horizontal (normal)

Modify Date : 2019:06:18 21:08:11

GPS Latitude Ref : North

GPS Longitude Ref : East

Y Resolution : 350

X Resolution : 350

Camera Model Name : DSC-WX350

Software : DSC-WX350 v2.00

Image Description :

Y Cb Cr Positioning : Co-sited

Exif Version : 0230

Scene Type : Directly photographed

Exposure Compensation : 0

Exposure Program : Program AE

Color Space : sRGB

Max Aperture Value : 5.0

Exif Image Height : 3672

Brightness Value : 0.3453125

Date/Time Original : 2019:06:18 21:08:11

Flashpix Version : 0100

Warning : [minor] Possibly incorrect maker notes offsets (fix by -93?)

Rating : 0

Brightness : 0

Long Exposure Noise Reduction : On (unused)

High ISO Noise Reduction : Normal

HDR : Off; Uncorrected image

WB Shift AB GM : 0 553648128

Face Info Offset : 0

Sony Date Time :

Sony Image Height : 0

Sony Image Width : 0

Faces Detected : 0

Face Info Length : 0

Meta Version :

Creative Style :

Color Temperature : Auto

Color Compensation Filter : 0

Scene Mode : Auto

Zone Matching : ISO Setting Used

Dynamic Range Optimizer : Auto

Image Stabilization : On

Color Mode : Standard

Full Image Size : 0x35

Preview Image Size : 0x1

File Format : ARW 2.3.1

Quality : Fine

Flash Exposure Compensation : -7.181397369e-10

White Balance Fine Tune : 0

White Balance : Auto

Sony Model ID : Unknown (0)

Multi Frame Noise Reduction : Off

Picture Effect : Off

Soft Skin Effect : Off

Vignetting Correction : n/a

Lateral Chromatic Aberration : n/a

Distortion Correction Setting : n/a

Lens Spec : Unknown (08 800 100 0 0 01)

Auto Portrait Framed : No

Flash Action : Did not fire

Electronic Front Curtain Shutter: Off

Multi Frame NR Effect : Normal

Macro : Off

AF Area Mode : Default

AF Illuminator : Off

JPEG Quality : Fine

Flash Level : Normal

Release Mode : Normal

Sequence Number : Single

Anti-Blur : On (Shooting)

High ISO Noise Reduction 2 : Normal

Intelligent Auto : On

Focus Mode : Unknown (0x48)

Camera Temperature : 0 C

Release Mode 2 : Unknown (620756992)

Release Mode 3 : Bracketing

Self Timer : Unknown (14)

Flash Mode : Autoflash

Stops Above Base ISO : 16.0

HDR Setting : Off

Picture Profile : Unknown (21)

Picture Effect 2 : Unknown (23)

Quality 2 : Unknown (3)

WB RGB Levels : 44204 63859 38

Min Focal Length : 4889.6 mm

Sony ISO : 6553600

Interoperability Index : R98 - DCF basic file (sRGB)

Custom Rendered : Normal

Exposure Mode : Auto

Exposure Time : 1/25

Flash : Off, Did not fire

F Number : 5.0

User Comment :

Exif Image Width : 4896

Saturation : Normal

ISO : 3200

Components Configuration : Y, Cb, Cr, -

File Source : Digital Camera

Compressed Bits Per Pixel : 2

Contrast : Normal

Sharpness : Normal

Digital Zoom Ratio : 1

Create Date : 2019:06:18 21:08:11

Metering Mode : Multi-segment

Focal Length : 13.1 mm

Scene Capture Type : Standard

Light Source : Unknown

Resolution Unit : inches

Compression : JPEG (old-style)

Thumbnail Offset : 31935

Thumbnail Length : 9273

MPF Version : 0100

Number Of Images : 2

MP Image Flags : Dependent child image

MP Image Format : JPEG

MP Image Type : Large Thumbnail (full HD equivalent)

MP Image Length : 551277

MP Image Start : 5599759

Dependent Image 1 Entry Number : 0

Dependent Image 2 Entry Number : 0

Image Width : 4896

Image Height : 3672

Encoding Process : Baseline DCT, Huffman coding

Bits Per Sample : 8

Color Components : 3

Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1)

Aperture : 5.0

Blue Balance : 0.000595

GPS Latitude : 50 deg 5' 43.92" N

GPS Longitude : 20 deg 4' 13.46" E

GPS Position : 50 deg 5' 43.92" N, 20 deg 4' 13.46" E

Image Size : 4896x3672

Preview Image : (Binary data 551277 bytes, use -b option to extract)

Megapixels : 18.0

Red Balance : 0.692213

Shutter Speed : 1/25

Thumbnail Image : (Binary data 9273 bytes, use -b option to extract)

Focal Length : 13.1 mm

Light Value : 4.3

photo
1

I've used "Send Feedback" feature on photos.google.com. Mayby after some months I would get any reply...

photo
1

What happens if you copy photos after exif? Should be same error because copy is even faster.

But I can't imagin that even a copy action would be broken.

photo
1

Good question. And answer is suprising: even when 3 photos having exactly the same time, google photos uploades them without any exeption (when they have no location info). I have really no idea what happens :-(


OK, now I have to stop trying to improve my photo toolkit - I need to focus on packing for bike trip. Thank you for all your attention!

photo
1

I did expect this answer. Maybe MediaStore/MediaScan Update will improve it.

It's just a bit more complicated because MediaScan is deprecated with Android Q but the alterternative "MediaStore" doesn't support responses from android file and folder picker.


But I found a way and just need to finish it.

photo
photo
1

Ok, only one more test: 15 photos which i previously geotagged in location scanned by google photos and 3 of them were skipped by google upload to cloud.

Now I deleted them all, reuploaded from camera to directory not scanned by google, then geotagged and in next step copied to directory scanned by google one by one ( avoiding files with the same mod. time).

And now all photos are uploaded to google without any problem!

Interesting? Mayby first observation (files which cannot be uploaded to google have the same time as previous image) is right, somehow. Mayby all what is neccesary to avoid google bug is a 1s delay between photos?

Regards.

ps: packing for 2 weeks bike travel with my son is a horrible task! I love travels but I hate packing :-)

czw., 20 cze 2019, 00:10 użytkownik Locus Map <locus.map@asamm.com> napisał:

photo
1

more interesting would be if a mass copy would trigger the bug because if not, we may just do some thing wrong. For example media store wasn't updated.

New test version does update mediastore after exif write. You need to accept the write permission request because I skip updating media store if write permission is missing. Maybe you should manually give permissions over android app detail and then permissions, because I don't output any warnings if I skip media store updates.


Maybe I can reduce the filesize of my own test picutes to trigger the bug even with my slow phone. How do you check for successfull uploads? Is there a "skip" notification anywhere, or do you need to download files from google and veryfi them with exif viwer to find skipped files?

photo
photo
1

1. Please ignore my last test. It was innacurate because google "knows" those photos even after deleting and ignores them in upload without _any_ notice (in app the photo looks exactly the same as uploaded, but is not shown in web interface) Argh!

2. Problematic photos (which cannot be uploaded) are usually marked by "cloud" icon in app. When you punch this icon it changes to "transfer", but does nothing. But first sign that some photos were not transfered is change in photos order - photos transfered have their time read from exif so they are treated by app as older then all problematic photos.

photo
1

I guess Google Photo does not support "Update Photos"- You need to delete the original fotos from cloud or you geotag photos before uploading to cloud.


Just one question: do you try to update google photos?

photo
1

update google photo app? yes, automatic updates every night. after last update (few days ago) nothing changed.

photo
1

I have to rephrase the question. Did you update jpg files which are already uploaded in cloud?

Google photos is mainly designed to handle only new photos.

photo
1

Exept last test, all test were made for new photos. Short trip around my house with recording track and shooting as many photos as possible - time consuming but I've tried to be accurate.

photo
1

Where did you store the new fotos? Outside of Google Photos or did these new photos get picked up by Google Photo before you start geotagging?


Because of googles dupplicate detection you need to adjust the photos before you upload them to google photos.

For example, store them in an folder which is excluded from google photos and then copy them to google photos folder or use the share functionality of my new success notification.

photo
1

OK, it makes sense. Quick test (only 6 photos) shows that this is a way to success.


Problem was when I geotagged photos in directory scanned by google. Now, when I geotagged it in another directory and then copy - all was correct.

It became a little more complicated than it might be, but still worth attention - I may prepare all photos just on my mobile phone, without even touching desktop computer.

Thank you!

photo
1

Did "Share xx Photos" work with google photos? I could implement a autoshare feature to open this share dialog automatially.


Otherwise you could automate the copy to google step with tasker.


You should amend your google photo support request to let them know this is an issue related to updating already uploaded photos

photo
photo
1

Yes, there is such feature (tested from Astro file manager), but seems to send images directly to google cloud (works slowly and refuses to work without network connection).

I use Locus on my trips almost all time offline - just to avoid huge roaming costs but also battery drainage. (usually I make only short connections to fetch weather forecast and push to Strava track recording with some, selected photos).  Before uploading to google cloud I need only possibility to preview photos - eg. for removing bad ones and maybe do some simple edits. But I can handle it - I have onother app for gallery.

Current state is OK for me. Thank you!

W dniu 21.06.2019 o 14:49, Locus Map pisze:

photo
1

The problem should disapper if you change your device or upgrade your os. I did test it with 3 devices:


S8 with Android Pie Stock

S4 mini with Anndroid Pie Custom

S4 mini with Android Oreo Custom


The S8 has blazing fast internal storage, it did write 14 photos in 1.4 second. All photos got automatically uploaded to google photo and each time I did manipulate the recordingtime+gps location by offset, I got a copy of these photos. No I have every photo 3 times in my google photo library.


Who did you enable dupplication detection?


As working folder I did use default the default camera folder.

photo
1

> Who did you enable dupplication detection?

Strange. I don't know. Maybe this is effect of paid account? Maybe long history of photos collection (started from Picassa) ? In the past Picassa made some duplicates, but now it seems to keep it clear. Too clear, as you may see.

But it doesn't matter - all works fine for me.

photo
photo
1

I can't find any more bugs and did include as many improvements as I could. Only minor things about android Q and P got adjusted.

Here is the release: https://play.google.com/store/apps/details?id=falcosc.locus.addon.tasker

I may should add a screenshot threre to show that it will be found inside track detail share menu.

photo
1

Geotagging worked fine! Thanks. But I've found one little problem: few photos were skipped without any rational reason. You may see this on https://www.strava.com/activities/2508789142 or on following listing.

What data do you need to digout this problem?

DSC00976.jpg|2019:06:27 08:59:38|37 deg 58' 19.13" N, 23 deg 43' 40.30" E

DSC00977.jpg|2019:06:27 08:59:48|37 deg 58' 19.13" N, 23 deg 43' 40.30" E

DSC00978.jpg|2019:06:27 09:01:02|37 deg 58' 18.60" N, 23 deg 43' 41.30" E

DSC00979.jpg|2019:06:27 09:01:06|37 deg 58' 18.60" N, 23 deg 43' 41.30" E

DSC00980.jpg|2019:06:27 09:01:11|37 deg 58' 18.54" N, 23 deg 43' 41.24" E

DSC00981.jpg|2019:06:27 09:01:34|

DSC00982.jpg|2019:06:27 09:07:24|

DSC00983.jpg|2019:06:27 09:07:36|

DSC00984.jpg|2019:06:27 09:10:18|

DSC00985.jpg|2019:06:27 09:10:32|

DSC00986.jpg|2019:06:27 09:10:45|

DSC00987.jpg|2019:06:27 09:10:49|

DSC00988.jpg|2019:06:27 09:10:53|

DSC00989.jpg|2019:06:27 09:11:05|

DSC00990.jpg|2019:06:27 09:12:03|

DSC00991.jpg|2019:06:27 09:12:13|

DSC00992.jpg|2019:06:27 09:12:18|37 deg 58' 16.28" N, 23 deg 43' 38.09" E

DSC00993.jpg|2019:06:27 09:13:54|37 deg 58' 16.29" N, 23 deg 43' 37.19" E

DSC00994.jpg|2019:06:27 09:14:02|37 deg 58' 16.27" N, 23 deg 43' 37.10" E

DSC00995.jpg|2019:06:27 09:16:38|37 deg 58' 16.07" N, 23 deg 43' 36.82" E

DSC00996.jpg|2019:06:27 09:16:53|37 deg 58' 15.95" N, 23 deg 43' 36.71" E

DSC00997.jpg|2019:06:27 09:18:37|37 deg 58' 15.90" N, 23 deg 43' 36.27" E

DSC00998.jpg|2019:06:27 09:18:45|37 deg 58' 16.04" N, 23 deg 43' 35.79" E

DSC00999.jpg|2019:06:27 09:21:26|37 deg 58' 16.62" N, 23 deg 43' 32.13" E

DSC01000.jpg|2019:06:27 09:21:32|37 deg 58' 16.73" N, 23 deg 43' 31.90" E

DSC01001.jpg|2019:06:27 09:21:37|37 deg 58' 16.73" N, 23 deg 43' 31.90" E

DSC01002.jpg|2019:06:27 09:21:45|37 deg 58' 16.78" N, 23 deg 43' 31.74" E

DSC01003.jpg|2019:06:27 09:24:14|37 deg 58' 18.00" N, 23 deg 43' 32.34" E

DSC01004.jpg|2019:06:27 09:24:44|37 deg 58' 18.32" N, 23 deg 43' 31.77" E

DSC01005.jpg|2019:06:27 09:24:50|37 deg 58' 18.24" N, 23 deg 43' 31.65" E

DSC01006.jpg|2019:06:27 09:24:55|37 deg 58' 18.24" N, 23 deg 43' 31.65" E

DSC01007.jpg|2019:06:27 09:25:34|37 deg 58' 18.23" N, 23 deg 43' 30.27" E

(just output of: for i in DSC*; do d=`exiftool $i|grep 'Create Date'|sed 's/^.* : //'`; g=`exiftool $i|grep 'GPS Position'|sed 's/^.* : //'`; echo "$i|$d|$g"; done)

photo
1

Which information are shown in the geotag notification? If you don't have a view details action there I would need your files and your gpx track to reproduce it.

photo
photo
1

please give me your mail (just send e-mail to jarstr@gmail.com) - I may share you all necessary files (including 7GB photos from last trip), but only in private.