Geotagging underwater

[richardy]

I apologise for the delay, but I have finally tried this out. I'm afraid your syntax did not work for me with three types of file (ORF JPG ans XMP) available in the same folder:-

Code Select Expand

C:\Program Files (x86)\Metadata++>exiftool PB071875.xmp xmp:waterdepth=20
======== PB071875.xmp
ExifTool Version Number        : 12.09
File Name                      : PB071875.xmp
Directory                      : .
File Size                      : 520 bytes
File Modification Date/Time    : 2022:11:21 10:32:20+00:00
File Access Date/Time          : 2023:10:01 14:12:06+01:00
File Creation Date/Time        : 2022:11:21 10:32:18+00:00
File Permissions               : rw-rw-rw-
File Type                      : XMP
File Type Extension            : xmp
MIME Type                      : application/rdf+xml
XMP Toolkit                    : XMP Core 5.6.0
Sidecar For Extension          : JPG
Metadata Date                  : 2022:11:21 10:32:18Z
Label                          : Yellow
Error: File not found - xmp:waterdepth=20
    1 image files read
    1 files could not be read
However I found this did work:-

Code Select Expand

C:\Program Files (x86)\Metadata++>exiftool -waterdepth=20 PB071875.xmp
    1 image files updated

C:\Program Files (x86)\Metadata++>
If I specified xmp it added a value of 20 to waterdepth in the xmp file.
If I specified jpg it added a value of 20 to waterdepth within the jpg file
If I specified ORF (my RAW file) it added a value of 20 to waterdepth within the ORF file

In all cases a backup was created, so potential corruption is avoided. I carried out all commands in the same folder to avoid getting paths mixed up, but the basic principle works and I can easily choose where to write the value to see which works best in future workflows. The next step seems to be to work out how to connect your perl script to this to provide the value to be written to whichever file is chosen.

Thanks again for your time :-)

[Alan Clifford]

Sorry, I left out the - before xmp: 

[Alan Clifford]

There are another decisions to be made.

In jpg files, you can use exif tags and there is an exif:waterdepth.  Which you choose to use really depends on if you are using other software to view it and does that software see the value.

For raw files, do you want to update the raw file or an xmp sidecar file.  If the latter, is the sidecar in the same directory as the raw file or in a subdirectory.  Does the sidecar file have a naming scheme or is it just same_name_as_raw_file.xmp.

A script can be told to make these decisions based on the type of file but it needs to know the rules.

[richardy]

As is so often the problem, at the outset of a project like this the extent of its far reaching implications are not fully understood! As progress is made the extent of these becomes more obvious and decisions need to be made regarding priorities. The project can be split into three sections. Calculation of the depth, storage of the calculated depth and finally retrieval of the data. You seem to have solved the calculation successfully and the inevitable errors due to the frequency of data collection are acceptable.

The storage can be done, but has several decisions that need making. The first is where to put it, which partly depends on the final 'how to access it' problem, in that that has an effect on where is practical to store them. It is the 'how' that is more of a problem. Most of my pictures have details imported into the Lightroom catalogue when they are added, however a few, edited elsewhere before importing have XMP files. It would be more efficient to add the depth value to the RAW file itself, but this introduces the risk of corruption as the general principle of RAW files is that they are not changed. ExifTool gets round this by creating backups but, unless these are removed once the new file is shown to be sound, storage space doubles.

Retrieval of the data depends on what is being used to look for it. Lightroom would be simplest as that is where they already are, it also has options to read EXIF data, but not all of it. Probably the most obvious that can be read by Lightroom is altitude (waterdepth does not appear to be available). A simple positive value would be fine if I just referred to it in my head as depth rather than hight.

It seems the process of writing the data is the biggest problem as automated error checking seems very hard https://photo.stackexchange.com/questions/46919/is-there-a-tool-to-check-the-file-integrity-of-a-series-of-images so it seems the use of XMP sidecar files would be the way to move forward, but some means of creating one if it is not there would be needed. I suspect that afterwards the information might even be able to be incorporated into the catalogue and the XMP removed again, there is a 'read metadata from file' command, but that is a step too far at this stage, and in any case, they are only small files compared to a duplicate image!

I am off to Scotland for a week of diving next week so I will leave exploring these questions further until after I return, as I currently need to prepare.

[richardy]

What a week!! Part of the group got stuck for 2 nights by floods and landslips on the way, and then Covid hit. Only 2 of us dived every day (I was one of them). Then a road accident (not involving them) caused delays getting home. However we are all home and gear sorted. The next 3 days will be taken up visiting my son but I will then be free to spend more time on this project.

[richardy]

I'm afraid this project seems to have gone very cold. However, I think I have learnt enough to at least be able to apply the principle to individual pictures, which is probably all it will really be needed for, though the initial idea of running batches through would be even better. However to do anything myself I need to have the Perl script in #11 if that would be at all possible, as my newly gained knowledge does not stretch to writing those myself yet.

[Alan Clifford]

Sorry I seemed to have missed this.  I haven't been looking at the forum for some time.