Thanks for this hint, this would work for me.
I have a Sony ILCE-7M2, lenses are “Sony FE 28-70mm F3.5-5.6 OSS” and “TAMRON 70-300mm F4.5-6.3 Di”. Images are in .JPG and .ARW.
In the RT Metadata Filter, the camera is detected correctly.
For the .JPG images, the lenses are showing up as “FE 28-70mm F3.3-5.6 OSS” and “E 70-300 F4.5-6.3 A047”. That’s correct.
The same images in .ARW format, the lenses all show up as “Manual lens”. That’s not correct.
Looking into the .ARW image data with exiftool show the correct lenses.
Probably off topic:
I have an Olympus Tough TG-4 with a fixed mounted lens.
The camera is detected correctly, but the lens is reported as “Unknown”, but should be “Olympus Tough TG-4 & compatibles”.
Exiftool reports no lens information from the image data, but since the lens is a fixed mounted combination with the camera: is there some hard coded mapping existing in RT or is this an issue with the Olypus generated metadata and not related to RT?
Additional information:
The .ARW files have an .xpm sidecar, these don’t contain the lens information.
The .JPG files might (unintentionally) refer to the same sidecar, but does not seem to have a problem.
For the future I might to move to .ARW.xmp, which is supported by digiKam as well.
Sample ARWs would be nice 
Sorry, I screwed up the upload and had no access to my PC the last days.
Here are the images.
The problem does not occur with RT 5.9 and not with the development Appimage.
The existence of xpm sidecars does not change the behavior
DSC01714.ARW (23.8 MB)
DSC01713.ARW (23.9 MB)
.
How do you deal with ambiguous sitecar files?
My images have the naming conventions .ARW, .JPG and .xmp. The .xmp file is only related to the .ARW image. The digikam setting is:
- Write Metadata into File
- Don’t write into Raw Files (this enforces generation of .xmp for ARW files)
- Name of sitecar is compatible with other programs (this causes ambiguity for the .JPG file)
I can change the .xmp to .ARW.xmp, but would like to know whether RT provides some magic for this.
Is that a statement of intent or a description of behaviour? The xmp file is supposed to provide metadata for all files with the same base name. If that’s not your intention you should consider a different file structure (sooc jpegs in sub folder?)
It’s a description of current situation with my images. Since RT as wall as DigiKam both are supporting .xmp and .ARW.xmp, I will switch to .ARW.xmp file structure to avoid the ambiguity.
Thanks, Jens
Update:
- Fix for lens incorrectly showing up as “Manual lens” for Sony ILCE and NEX cameras.
- Support for Exiv2 v0.28.0.
2 Likes
It works nice even with phone camera, only “complain” I have is that Im quite positive there is noise/denoise map, but its not used. Unsure what it needs to make that used. Also its most likely for phones only part?
2x2 binning would be also great, but thats asking too much I guess. Altho I think RT is actually great for raw files from phones (DNGs).
Hi @Corwin_Black, glad to hear it is working for you. The two features you mentioned are not tied to Exiv2 adoption, so they can be implemented separately. I have to ask what the noise map is. I have never heard of such a thing and I don’t see anything like that in the metadata tags.
Noise/gain maps are results of computational photography. Not necessarily metadata, but separate sub-images inside a DNG, although could sometimes be implemented as DNG OpCode.
Probably separate sub-image, but Im just guessing there.
Altho there is possibility that most of noise just vanishes after pixel binning. Sadly not after regular downsize.
I notice that in the IPTC tab nothing is shown for some of my images. Yet there is more than one type of IPTC information. The tab might be more useful if it contained both Iptc and Xmp.iptc.
exiv2 -v -p a -g iptc IMG_4387.CR3 File 1/1: IMG_4387.CR3 Xmp.iptc.CreatorContactInfo XmpText 0 type="Struct" Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrExtadr XmpText 17 Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrCity XmpText 6 Norman Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrCtry XmpText 3 USA Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiEmailWork XmpText 12 Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrPcode XmpText 5 Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrRegion XmpText 8 Oklahoma Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiUrlWork XmpText 26 https://www.rsok.com/~jrm/ IMG_4387.CR3: No IPTC data found in the file
exiv2 -v -p a 2023jun21_wildflower_IMG_4337c.jpg | tail -24 Iptc.Application2.Copyright String 41 Copyright John Moyer, all rights reserved Iptc.Application2.RecordVersion Short 1 4 Xmp.iptc.CreatorContactInfo XmpText 0 type="Struct" Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrCity XmpText 6 Norman Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrCtry XmpText 3 USA Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrExtadr XmpText 17 Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrPcode XmpText 5 Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiAdrRegion XmpText 8 Oklahoma Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiEmailWork XmpText 12 Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:CiUrlWork XmpText 26 https://www.rsok.com/~jrm/ Xmp.iptcExt.LocationShown XmpText 0 type="Bag" Xmp.iptcExt.LocationShown[1] XmpText 0 type="Struct" Xmp.iptcExt.LocationShown[1]/Iptc4xmpExt:City XmpText 6 Norman Xmp.iptcExt.LocationShown[1]/Iptc4xmpExt:CountryName XmpText 13 United States Xmp.iptcExt.LocationShown[1]/Iptc4xmpExt:ProvinceState XmpText 8 Oklahoma Xmp.dc.creator XmpSeq 1 John Moyer Xmp.dc.description LangAlt 1 lang="x-default" Gaillardia pulchella wildflower (also called Indian Blanket, Firewheel, Girasol Rojo) blooming in Norman, Oklahoma, United States on June 21, 2023 Xmp.dc.rights LangAlt 1 lang="x-default" https://www.rsok.com/copyright.html Copyright John Moyer, all rights reserved Xmp.plus.Licensor XmpText 0 type="Seq" Xmp.plus.Licensor[1] XmpText 0 type="Struct" Xmp.plus.Licensor[1]/plus:LicensorURL XmpText 35 https://www.rsok.com/copyright.html Xmp.xmp.Rating XmpText 1 0 Xmp.xmpRights.UsageTerms LangAlt 1 lang="x-default" https://www.rsok.com/copyright.html Copyright John Moyer, all rights reserved Xmp.xmpRights.WebStatement XmpText 36 https://www.rsok.com/copyright.html
Thanks.
John
I notice that there is a choice between unsharp mask and Richardson/Lucy deconvolution in the detail tab. I might have gotten this wrong, so please comment.
It seems to me that unsharp mask should be used after R/L. As an initial guess, the radius of the central peak of the Airy disk might be estimated from the photosite pitch on the sensor chip and the F number. I would expect a previous unsharp mask to confound the R/L deconvolution and create artifacts. The R/L deconvolution will also sharpen other sources of blur that are nearly gaussian.
I am using the metadata-exiv2 branch which I compiled recently.
Thanks
That’s an old feature not unique to current development versions. I think capture sharpening (raw tab) is a RL type sharpening that comes early in the pipeline. More knowledgeable people may correct me if I’m wrong. If I need further sharpening after capture sharpening, which is rarely, I get better results using unsharp mask.
1 Like
If I’m not mistaken, XMP IPTC data isn’t read in 5.9 either. It can be addressed in an independent feature request.
Could the exiv2 branch potentially help with lcp profiles? I’ve noticed that for at least one of my lenses the distortion correction varies hugely between LR (which I have at work) and RT. It was suggested that RT don’t match focus distance correctly. I’ve tested the exiv2 branch and it’s not solved in it’s current state.
So could exiv2 branch help with determining focus distance for the lcp module?
Not really. Reading the focus distance is simple with or without Exiv2. The main issue is actually using and interpreting the value.
had no idea XMP files were of any use in RT