allow for taking lens-related metadata from sidecar file

[v923z]

Is your feature request related to a problem? Please describe.

Without wanting to cross-post, I'm including the link to the related discussion on pixls.us.

The issue I'm facing is that lens information can't be added in darktable. This is a problem in all cases, where this piece of information is not inserted in the EXIF by the camera, so all manual lenses are automatically excluded. While I understand that I could, in principle, add this as a standard tag, that approach has several drawbacks. First, having f-numbers or focal lengths in tags is not standard practice. Second, lighttable allows for filtering on all kinds of lens metadata, but only, if it comes from the EXIF, so using tags will just not cut it.

Describe the solution you'd like

One suggestion on the above-mentioned thread was to modify the EXIF data via exiftool, but the poster also pointed out that that might corrupt the file. This is why I'd like to propose a solution, where such data could be added to the sidecar file, and could be retrieved from there, if a particular field is missing from the raw file. This approach would leave the raw file alone, and would simply be a logical extension of what is already there, namely, the sidecar already contains tags and other metadata, e.g., copyright note, title, comments and the like.

Since the sidecar file could be written to by means of an appropriate lua script, the only thing missing from the executable is the option to read and make use of such metadata, if the EXIF is incomplete. I don't know how much effort this would require, but I'd like to explore the idea in this issue.

Alternatives

A possible alternative is writing into the raw file and modifying its EXIF fields through exiftool.

[wpferguson]

duplicate of #11111

The EXIF information is pulled from the image on import and stored in the database.

The database information can be changed using a Lua script. There's already an issue to do this (above), but I haven't got to it yet.

Trying to input data into darktable using the sidecar files is really not a good idea for numerous reasons.

[v923z]

duplicate of #11111

The EXIF information is pulled from the image on import and stored in the database.

The database information can be changed using a Lua script. There's already an issue to do this (above), but I haven't got to it yet.

Trying to input data into darktable using the sidecar files is really not a good idea for numerous reasons.

I'm a bit confused: the issue that you linked to would do exactly that. " The changes will only exist in the database/xmp files and no changes to the image files will be made."

I would also argue that such pieces of information, just as the copyright note, the title, or the author, are an integral part of the image, so it would make perfect sense to store them in the sidecar file, if editing the raw file is out of the question.

[wpferguson]

lightroom reads information from XMP files on startup or image load.

darktable does not read information from XMP files on startup or image load.

You want to solve a darktable issue with a lightroom solution, and it wont work.

I would also argue that such pieces of information, just as the copyright note, the title, or the author, are an integral part of the image, so it would make perfect sense to store them in the sidecar file, if editing the raw file is out of the question.

They are. The information is taken from the image on import and stored to the database. It's also written to the XMP file, if XMP files are enabled.

#11111 asks for an EXIF information editor, which is why darktable-org/lua-scripts#414 exists

[v923z]

lightroom reads information from XMP files on startup or image load.

darktable does not read information from XMP files on startup or image load.

I beg to disagree: the tag manager loads entries in the darkroom. It might very well be that these entries are taken from the data base, and not from the sidecar file, but that is an immaterial point in this regard.

You want to solve a darktable issue with a lightroom solution, and it wont work.

I understand the first part of the statement, but clearly, there is a problem at hand (and this is not only my problem, others have also run into it), where the current solution shows its limitations. I might also understand the principle that darktable shouldn't modify the raw file, and that's why I was advocating the idea of storing such information in the sidecar file. Given that the sidecar file is flexibly extendible, I feel that the distinction between e.g. copyright note and f-number is rather arbitrary. One can be written to the sidecar, the other one can't.

I might completely misunderstand something here, but as #11111 also points out, there are cases, where darktable is, in effect, downgraded, because even, if the information is supplied by hand, the software won't/can't make use of it. And this is not only about quickly filtering images. lensfun might have the corrections for a particular lens, but it's of no use, if the information doesn't come through the EXIF. This rules out all manual lenses.

#11111 asks for an EXIF information editor, which is why darktable-org/lua-scripts#414 exists

That's clear, but I have the feeling that that's only half of the equation: one still has to decide, what should happen to the data entered into the EXIF editor. If, e.g., the f-number is written into the data base, then files can't easily be copied from one computer to another. On the other hand, if the f-number is written into the sidecar, then copying the raw file and the sidecar to a different computer takes all information there is.

[ptilopteri]

* Zoltán Vörös ***@***.***> [09-16-24 09:24]:

> lightroom reads information from XMP files on startup or image load. > > darktable does not read information from XMP files on startup or image load. > I beg to disagree: the tag manager loads entries in the `darkroom`. It might very well be that these entries are taken from the data base, and not from the sidecar file, but that is an immaterial point in this regard. > You want to solve a darktable issue with a lightroom solution, and it wont work. > I understand the first part of the statement, but clearly, there is a problem at hand (and this is not only my problem, others have also run into it), where the current solution shows its limitations. I might also understand the principle that `darktable` shouldn't modify the raw file, and that's why I was advocating the idea of storing such information in the sidecar file. Given that the sidecar file is flexibly extendible, I feel that the distinction between e.g. copyright note and f-number is rather arbitrary. One can be written to the sidecar, the other one can't. I might completely misunderstand something here, but as #11111 also points out, there are cases, where `darktable` is, in effect, downgraded, because even, if the information is supplied by hand, the software won't/can't make use of it. And this is not only about quickly filtering images. `lensfun` might have the corrections for a particular lens, but it's of no use, if the information doesn't come through the EXIF. This rules out all manual lenses. > #11111 asks for an EXIF information editor, which is why [darktable-org/lua-scripts#414](darktable-org/lua-scripts#414) exists That's clear, but I have the feeling that that's only half of the equation: one still has to decide, what should happen to the data entered into the EXIF editor. If, e.g., the f-number is written into the data base, then files can't easily be copied from one computer to another. On the other hand, if the f-number is written into the sidecar, then copying the raw file and the sidecar to a different computer takes all information there is.

copying the "raw" file from one place to another will allways have the f-number without any xmp file as the f-number is contained in the raw file exif data. since it is already there, putting it into the xmp file is superfluous.

…

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[v923z]

copying the "raw" file from one place to another will allways have the f-number without any xmp file as the f-number is contained in the raw file exif data. since it is already there, putting it into the xmp file is superfluous.

No! That was exactly my point. The f-number will be there, only, if the camera can talk to the lens. That's not the case for manual lenses, or for lenses that are attached to the camera through an adapter that can't handle electronic communication. I use manual lenses, and I also use automatic Sony lenses on a Canon camera. In both cases the information is lost.

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.