You could try to persuade the people who formulated the IPTC specs— mostly photographers and news industry veterans with decades of experience — that they’ve got it all wrong.
Or you could take the time to try to understand why they formulated the spec the way they did, knowing that some of them probably maintain collections of millions of images from all over the world spanning many decades.
The same principle applies to the XMP specs, although the people involved are different and the XMP spec covers more than just photography.
Who, where? I’m not really involved into development of the industry standards or the software considered to be industry standard so I don’t really have the access to your contact. I think Adobe even moved away from XMP files afaik.
I see flawed and wrong as two different things. That it’s flawed - for certain use cases - there is no doubt. If you’re storing linked data, lack of uniqueness will quickly land you in trouble. But what I’m trying to do is come up with ways to work with the standard (that’s what the bullet points were supposed to be). I hope to see more ideas than I listed!
A semi silly one.
Camera Originals never get changed OR a sidecar added. If you want XMP sidecars you enforce unique new files containing original filenames with extensions. XMPs then are able to use file.xmp.
the original pair/tuple file.ext1 and file.ext2 become new-file-ext1.ext1 and new-file-ext2.ext2 with the respective sidecars new-file-ext1.xmp and new-file-ext2.xmp
it looks butt ugly, increases storage needs (some file systems allow virtual copies like this, no?) and seems overly complex for a file-versioning sidecar system. On top of that, I vaguely remember seeing files like this somewhere at some point…
Only under certain circumstances that one has to try hard to create, going way outside the norm, it seems to me.
I know of photographers who are annoyed that because DNG embeds XMP it means when they edit only the IPTC / XMP metadata the entire DNG has to be backed up (echoing a related point made by Mica).
But I don’t know of any working photographer on Windows or macOS who stores XMP data in a sidecar outside of a DNG, JPEG or TIFF. Who does that? Why would they when the everyday tools they use probably don’t even account for that scenario, because it’s so obscure? Is it even supported at all by any mainstream tool?
I guess they’d find the kinds of scenarios presented here in this discussion as rather foreign to them.
Wouldn’t anyone using Photomechanic to cull and tag end up with xmp sidecars, though?
…I might ask people on other photography fora I frequent whether they use xmp sidecars, whether they care about them, or indeed whether they even know of them.
Personally I use Photo Mechanic for metadata creation because it’s the best tool I ever saw for it, not culling. I imagine that’s the case for most photographers who use it.
It will create an XMP sidecar only for CR2, NEF etc. It will not create them for JPEG or DNG or TIFF. It embeds them in the file header for those files, as the spec says to do.
For example, I added identical metadata to the first pair of CR2+JPEG pairs, and as you can see there is only one XMP file on the file system because the other is embedded in the JPEG:
If you delete a file in Photo Mechanic it will delete the XMP that goes with it.
Hey! I have actually non-hard situation! In My actual images folder! I have “IMG_0724.CR2” and “IMG_0724.CR3” created by different cameras in diferent times etc… How standard deals with that?
Now this is silly and circular. The binary representations all have certain identifier in header area that is of various lenghts but allows libraries to determine if they are dealing with right file type…
Still my question remains: i have 2 different raws with valid unique filenames that differ in extension part. The hash of file names is different, files themselves are totally different in every aspect (apart from camera manufacturer)…
Well, this blew up. We could totally do a video debate series (or rap battles) on contentious discuss.pixls.us subjects. Personally, I don’t care for sidecars or metadata, only the raw files and what is in them, because all the issues discussed above and others drive me batshit crazy.
I don’t know how relevant is this but Lightroom generates this tag in their XMP file: photoshop:SidecarForExtension="CR2"
This could be what they use instead having the extension in the file name.
Do you actually care about metadata in your files? Do you tag and manage your metadata to ensure you can find and view the files? That’s a real question.
With that organisation I somehow doubt it. You are taking several steps with camera settings and file organisation to end up in that situation. All those steps are making it more difficult to handle your files. I mean even simple copy of all related files requires cherrypicking you can’t glob your way out of that one. I mean your output files can’t have the same name as the master when stored in the same location an actually meaningful (as in meaning) file organisation.
Again this isn’t about LR or C1 it’s about a huge world of meta data handling. It’s very useful to just follow standards and slot in when dealing with stuff like that. It’s used to be a free software speciality when commercial software insisted on creating their own solutions to maintain lock in.
As a sooc dng shooter I’d much prefer not writing to my raws at all. For the reasons you mention but also just avoiding bugs that ruin the master. Most software I’ve seen has setting how to handle sidecars vs writing to file.
It’s a feature not a bug.
If you look around for file naming practices you’ll find that it recommends patterns that avoid giving different content the same file name and that the extension signifies format or sequence. They only way to end up with the same filename for different content is if you don’t conciously manage your files and have a special setup for filename generation in cameras.
It can’t be avoided (without being an extra chore for the user). Just like in @johnny-bit example, it’s so easy to have two files with the same base name and different extension, even the same name and same extension but then the OS prevents you from putting them in the same directory.
It’s super easy to avoid. If you run foss software and tweak raw files naming your files is a skill you have. See my comment above the output file names will collide or loose their link to the master.
But now you have engineered a situation where the file name has no semantic meaning. It’s the worst possible way of organising your files. You won’t know from the names which output file belongs to which master. does _001 belong to .CR3 or and does _002 belong to dng and does _004 belong to PEF or is it the other way around completely.
It’s a very bad habit because it breaks the meaning of file names when you have multiple versions of the same content. Do you ever use find or other simpler search tools?
If you shoot two cameras simultaneously and like having them in the same folder (this is me) rename the files. I use Rapid photo downloader to do this.
If you shoot two cameras simultaneously and like having them in the same folder set your cameras up to give different names.
If you shoow two cameras simultaneously and can accept per camera folder (seems to be the common way but I dislike it as I like to see all my images and don’t care which camera was used) just add the camera to the folder name.
I don’t have that habit. Maybe that’s something I should change, to have more descriptive file names.
I store hundreds of thousands of images but I’ve never renamed a raw file in my life. I’ve always relied on the folder structure alone. I’ve never used RPD in my life. After reading RPD documentation now, I think I’m gonna change that and introduce RPD in my workflow.
It’s not a problem for the raw developers. It’s a problem because it breaks a huge machine of institutions software and people. It breaks the meaning of certain relationships. You can’t code your way around that. The standard i set up so that meaning and relationships are conveyed via file names. (which is the purpose of file names to begin with, inode…)
