Modifying EXIF GPS coordinate
Implemented
Hello,
I would like to change the GPS coordinates of my images inside C1 without using other extra tools. A drag and drop from google map or equivalent could be great. This is a very simple feature I miss from lightroom.
Thank you
-
Official comment
Hi Jean-Michel,
Thank you for your feedback on Capture One - we appreciate the time you've taken to contribute to the development of the software.
I have forwarded your suggestions to our Product Management team as something to consider in a future release. Hopefully, your feedback contributes towards a future version of Capture One.
Though we cannot comment on future releases and the features to be added, we recommend keeping an eye on this article - click Follow next to the title of the article to stay up to date with new features and improvements. -
Given that a principle of C1 is that the original file is never altered the best (and most flexible) way to achieve provision of Geodata that is not stored or is different to that held in an original file would be to create additional entries in the IPTC data (assuming that there are fields defined for such a purpose in the IPTC standards) and allow the user to define some usage rules or their purposes, including, if required, the presentation of both the embedded data from the original file and the user data as added.
0 -
>SFA: ...assuming that there are fields defined for such a purpose in the IPTC standards
https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata , see section 11.9 Location structure
0 -
Thanks OddS!
That reminds me that, for Photographic purposes, there are 2 possible Geo Locations references that might be desireable.
The location of the camera (as recorded by a mobile device) and the location of the subject.
Providing the option to use the IPTC fields and populate them with either the camera derived data (if any) or via an external source to an external field set that does not break the "never change the original" principle would seem to be possible.
0 -
>SFA: ...The location of the camera (as recorded by a mobile device) and the location of the subject
Photo Mechanic uses "Locations Taken and Shown". There is one set of metadata fields (location, sub location, city, region...) and multiple sets for location shown. An image may show multiple locations, thus multiple sets. As far as I know, image GPS coordinates are normally associated with location "taken", the camera location.
0 -
@EtMRS
The thing about the location of the subject is that it is certainly often a variable that is independent of anything the camera could provide. This is why it would be good to have more than one set of fields available to store the data. Especially for Landscapes.
The XMP sidecar file is a method for transferring data but not so good, in my opinion, for archiving it. Therefore activating the IPTC fields seems appropriate and using them during output processing would be a cleaner solution for consistency.
@OddS
It sounds like Photo Mechanic has set a good and practical standard.
However, I do wonder how far a RAW convertor with catalogue available needs to carry functionality that gets close to an agency archival application. I can see the potential appeal but, speaking personally, I'm not sure I would really have a need for it and if I did I could satisfy that need using an "output" files catalog or gallery application with all the useful geo searching and location tools found for it.
One might end up with multiple applications all supporting the same rarely used activity and data storage in slightly different ways and using none of them. There would be costs associated with that. I'm not a believer in Free software, although it has its uses sometimes. Any feature built into any application will have some sort of cost to the consumer associated with it, and so duplicating functionality, especially for occasional use, is not an enticing option as far as I am concerned.
However, I do understand that others may see it as being far more important for their use purposes than I do for mine.
0 -
Adding GPS coordinates to a picture is not so easy and usually requires an external device, as adding GPS hardware implies extra certification that has an impact on the price, so it is usually not included in the camera.
I synchronize my Fuji with my phone that provides the coordinates each time I take a picture. The problem with that is that it doesn't always work, or provides sometimes unprecise information that I would like to change in C1.
By The way, this is still possible in LR6, but with a complicated workround that requires to create a Google Map API account. No cost at all.
0 -
>SFA: However, I do wonder how far a RAW convertor with catalogue available needs to carry functionality that gets close to an agency archival application.
We may all have different needs and expectations. C1 is supposed to be a tool for professionals.
>SFA: ...I'm not a believer in Free software, although it has its uses sometimes.
I use Open Source and free software for a lot of things. C1 includes SQLite3 database software, for example.
0 -
Hello everybody, thank you for this interesting discussion. I agree that the most important for the C1 developper team is to focus on RAW development. But classifying and organizing thousands of pictures is also an important job that C1 does quite good, but that can still be improved. Editable GPS coordinates fields in C1 is one of these suggested improvment, another one could be to improve the key word management.
Regarding my primary question: it seems to me (but I am not a developper) that making the GPS fields in C1 just "editable" should not be so complicated to do. Could be done in the original RAW file or beside and written in the exif data when exporting the picture.
0 -
> Jean-Michel: classifying and organizing thousands of pictures is also an important job that C1 does quite good, but that can still be improved.
Sure. I had used Photo Mechanic (PM) as the front end and back end of my workflows for many years before I got my first Capture One when thy released version 7. Note plural "workflows", I have used quite a few raw image applications in parallel, and I still do. PM is always first and last in the chain. I connected GPS hardware to my Nikons almost two decades ago, the first was a hand held Garmin using serial cable before I moved on to dedicated camera units. I think I understand your request.
PM is a metadata power tool, I find C1 is not even close. When it comes to setting or adjusting coordinates, PM lets me type them in or adjust a marker on a map. I think PM has a 30 day evaluation in case you want to try it. If you only need to type in coordinates, I would go for Exiftool, it is world class software and it is free (a lot of photograpers owe Phil Harvey a beer :-) If you are not into scripting, you may want to include a Exiftool GUI.
0 -
@EtMRS
"Why is XMP sidecar not good for archiving?"
It's basically a data exchange mechanism that requires, as the transfer catalyst, an extra file and a decision about how to use that file - i.e. one-way or two-way synchronization.
In some situations, the synchronization alone can become messy.
From an archiving perspective, it is one more file to store in the right place at the right time and I am not sure that is a good archival practice when in theory a "finished" archived image will have all adjustments applied and embedded - including Metadata. At that point, the XMP becomes completely redundant. It is also unlikely that the original XPM file will now have a clear relationship with the output file.
I think that is the point at which a full-blown Library system makes clear sense. Preferably an application that has a "life" of its own and can be used independently of any and all image manipulation applications when necessary.
The problem these days is that the mass market developers offer functionality that provides the mass-market with enough for its purposes (e.g. Apple, Google and Microsoft building simple and functional "Gallery" type applications into their core offerings) and since it is likely that 99% of photos taken these days are created on phones and similar use devices with most potential users kept happy using them, the market for any alternative approach, outside a corporate world or commercial photo-library sales operation, is probably rather small.
And then we have the AI "promise" of asking an online application to analyse an image and tell us what or where it is. On-demand as required rather than assuming someone somewhere will actually care. Bear in mind the image taking device, using any available location coordinates data, can only tell us where it is (approximately) and that is not always where the subject is located.
So I see the use of the XMP file in an archival sense as of marginal benefit and an additional complication. given that it is not something that all workflows might require and therefore workflows and any automated process that people might create to run them (e.g. Applescript routines) may become more challenging than they really should be. It would probably be a better investment to buy in to a respected application that can do all that one needs for Library and archival purposes and hopefully not have the plug pulled on it at some future point.
If the data required is embedded in the "final" output version of the image the chances are that offers the best long term archival option since all sorts of applications can find and make use of that data and provide basic selective viewing facilities for "libraries" of photos without any great need to manage them so long as the files presented to the applications have embedded data they can use. I can't think of any that, currently, expect to find an XMP file in connection with their activities. Of course there may be some but recent offerings in the mass market seem to expect the work to have been done externally or offer the option to make changes internally. A simplified offering.
0 -
> SFA: ...the AI "promise" of asking an online application to analyse an image and tell us what or where it is. On-demand as required..
For some kind of images. Last week I shot a closeup of a viper's head, out in the field. I do not expect it possible to determine the location by looking at the pixels, with or without AI.
> SFA: ...Bear in mind the image taking device, using any available location coordinates data, can only tell us where it is (approximately) and that is not always where the subject is located
Sure. That is what IPTC "locations shown" is for, but I can't tell if those IPTC field sets (note the plural) exist in version 21 of C1's metadata universe. Even when locations shown are known from textual metadata, I find the camera location useful.
0 -
@OddS
You have a good point about your viper shot related to AI.
However, I would guess that AI analysis of the mass of data on the Internet might be able to provide guidance about where Viper might be found anywhere in the world and that such information may be of as much value to the person viewing the image (assuming global access to the image).
If, on the other hand, this is something either unusual or of specific interest (to you or you and others with a special interest) then as the creator of the image one might indeed wish to tag it with precise location information. I rather suspect that 99.9% of users have no such need and 99.99% have little desire above and beyond what their smartphone (possibly also the only camera they use) may allow them to record.
As for the AI situation ... if the image capture date and time are included in the final version of the image and if you had a mobile device with you that was recording your location for its own purposes It might not be very complicated to put the two events together using minimal data record joining.
Some years a US University was assessing the potential for GPU-based processing to augment computing power. This was in the relatively early days of almost affordable add-on GPUs.
They obtained about 15 months' worth of (IIRC) Twitter posts, provided a search engine, and created an online GPU driver facility to search a very large number of Twitter posts (as I recall about 1.3 billion but that may be an incorrect number) to demonstrate the capabilities.
If one picked a particular Twitter user a click would list all of their posts and that list could be filtered to a specific date and time range. Or point.
One could also discover where the poster was located at the time the post was made. And therefore where they were most often located when they made a post. Another click and one could see that location on an aerial map. A quick zoom and one might have discovered where they lived with the mapping system providing an address.
It's not a big stretch of the imagination to conclude that, if one did not take steps to try to break identity connections or perhaps try to live entirely "off-grid", the potential for AI-backed data analysis to record and connect a location to an image via some shared data source, even if the share is quite indirect to our way of understanding things, certainly exists. It might not pin your viper to an exact square meter of the ground as a surveyor might desire but could well be accurate enough to record something that moves as part of its day-to-day life!
If you are close enough to the subject for reasonable accuracy and if the image file contains sufficient appropriate "camera" data (focus distance for example) and enough image information to assess the direction the camera was facing as the time (time of day and shadow direction for example) it should be possible to calculate a suitable adjustment to the coordinates to provide a "good enough" positional reference allowing for the accuracy constraints of publically available GPS systems.
Even without GPS, regular cellphone triangulation (where enough connectivity to transmitters exists) might provide an adequate result.
Maybe it is something the "What three words" application could offer as a potentially easier means of geo-tagging things for mass access.
But I digress.
I agree with your observations about the IPTC fieldsets. Maybe there is some clarification and a new assessment required?
0 -
> SFA: I agree with your observations about the IPTC fieldsets. Maybe there is some clarification and a new assessment required?
As in "C1 management is not aware of the IPTC" ?
Obsessive sidecar XMP file usage is arguably a product of proprietary raw files. Back in the day, new/changed metadata used to go into the original raw file. At one point Nikon software garbled .NEFs to the extent that Nikon software failed to read them. No wonder the sidecar doctrine caught on in the third party image application camp. Even Nikon's new software use sidecars, proprietary of course.
I can not find the old documents I once collected on the NEF corruption subject, but here is a link to a 2013 exchange between Dennis Walker (Photo Mechanic) and Phil Harvey (Exiftools) when Nikon's NX-ware fiddled with the Exif Maker Note endianess in NEFs: https://exiftool.org/forum/index.php?topic=4954.0 .
Adobe launced DNG, good idea with potential, except large camera makers did not adopt it. Guess what: Applications are supposed to update metadata in the DNG file (read the spec). No sidecar. The same actually goes for other image file types, JPG for one. No sidecar. We both know C1's position, and I happen to think C1 got it wrong.
A decade+ ago, IPTC launched a campaign to keep metadata embedded in image files. It is still active and known as "The Embedded Metadata Manifesto" (see https://iptc.org/standards/photo-metadata/initiatives/ ). It is hard to pull off with proprietary files.
0 -
> EtMRS: Phil Harvey do a really good job with exiftool
He is one of the deep diggers who share their work. Dave Coffin is another, but you probably need to appreciate C code to investigate his findings and tricks (dcraw.c). Here is a link to a 2005 interview that may perhaps shed more light on .NEF issues and why third party image application builders opted for sidecar files: https://www.dpreview.com/articles/0616201150/davecoffininterview The name Thomas Knoll appears in the text, search for it if his name is unfamiliar to you.
0 -
@OddS
"As in "C1 management is not aware of the IPTC" ?"
No. It's more nuanced than that, or at least it was the last time I spent some time looking at it in detail. (Some years ago.)
Not all IPTC fields are especially relevant to a RAW converter and some seemed not to have been widely adopted or were not adopted for the purpose originally intended or, in some cases, seemed to have been superseded since introduction.
And then, of course, there was the Nikon issue you have described and, if I recall correctly, some other anomalies related to metadata adoption and use by other manufacturers. Things may be more consistent now.
There has also been the problem of changing original images as reported related to news media use and the potential for "misrepresenting" the content of an image and therefore the accuracy of what it represents. That could apply to both the visual content and the related metadata in a commercial environment.
So whilst for happy leisure shooters making retrospective changes to an original file is entirely their decision in other areas it is less acceptable or even unacceptable and one might understand why C1 or anyone else would decide to disallow any ready opportunity to change a "source" file.
However, if someone wishes to make changes to the file and then present it as an "original" there is not much they can do about it. By ensuring that their software cannot make such changes they should be able to eliminate any chance of legal action being taken against them as co-defendants in some sort of image misrepresentation case or similar. When countries like the US provide a significant percentage of one's business taking such precautions is probably very wise. Especially as a Corporation. Going after an individual is much less likely to happen unless they are thought to have enough financial resources to make the legal effort pay well.
Just my opinion of course.
0 -
> SFA: However, if someone wishes to make changes to the file and then present it as an "original" there is not much they can do about it. By ensuring that their software cannot make such changes they should be able to eliminate any chance of legal action being taken against them as co-defendants in some sort of image misrepresentation case or similar.
I doubt any of that stops C1 from letting the user set/adjust image location coordinates and potentially write it to a file C1 creates or already has created. This closes the circle, we are back at the opening post. I fully support the OP's request, though I will likely never use it myself.
0
Post is closed for comments.
Comments
17 comments