- This topic has 3 replies, 2 voices, and was last updated 1 month, 1 week ago by
.
-
Posts
-
Hi all,
I’m switching from the seemingly-abandoned Exposure to Nitro and am trying to come up with a decent workflow for file management. I’m currently using XnView to import and organise files as it’s a bit more flexible than Nitro.The main issue I’m having is with XMP naming conventions for jpgs. My understanding was that Nitro would read/write {image}_jpg.xmp files for jpgs only when there were raw and jpg files with the same name – otherwise it would use {image}.xmp. What I’m seeing though is that Nitro always looks for and writes {image}_jpg.xmp, which makes interop difficult.
Have I just misunderstood how this is supposed to work?
I’d love a config option to be able to set the pattern for jpg xmp files. XnView allows you to choose between {image}.jpg.xmp and {image}.xmp but unfortunately not {image}_jpg.xmp.
As a workaround I’m toying with the idea of batch renaming files between {image}_jpg.xmp and {image}.jpg.xmp before moving between the apps, but that seems like a fragile and error-prone approach.
NB for raw files the workflow between XnView and Nitro is seamless.
Another customer mentioned the issue with file extensions. There are a few things going on here.
Nitro uses .xmp for all XMP files. If it’s a proprietary RAW (that is, not a DNG), then it writes with just the XMP extension. If it’s a JPEG, DNG, etc., then it uses the underscore.
It does that to ensure there cannot be a conflict between a proprietary RAW and a JPEG with the same base name. This can happen a couple of ways. One is RAW+JPEG. Another is a RAW + an exported JPEG stored in the same directory. Or, the JPEG is first imported and then the RAW from a R+J pair. Also, this makes it simpler for the app to know what file goes with which.
The terminology of “.jpg.xmp” is attempting to follow a convention of “two extensions”, but that is supposed to be used in a particular case – when the storage is “layered”. For example, TAR and GZIP. That is usually done as x.tar.gz because it’s a TAR file that has been gzipped. Once you unzip it, you have x.tar.
But that’s not true for a file named “.jpg.xmp.” The JPEG is not stored inside an XMP container – it’s not a layered model.
I will probably add a preference at some point to let sidecars be named with the double extension, though I don’t think it’s correct. If I do that, I would update the “Migrate Sidecar” feature to adjust the names of existing sidecars in a directory. I’m not inclined to have the app search for both files and try to figure out which one to use though. Having two files containing similar data always leads to problems.
Thanks Nik. I agree on the (in)correctness of .jpg.xmp – your approach makes more logical sense. It also makes sense now why you want to always include the extension in the filename for jpg and dng – thanks for the explanation.
It’s a shame that there’s no standardized naming convention across apps. I’ll adjust my workflow until either you (or XnView) allow control over the naming so that I can align them.
One thing I didn’t mention was that Image -> Reconnect XMP Sidecars does not seem to find either {image}.xmp or {image}.jpg.xmp. I was expecting it to at least find {image}.xmp and rename it to {image}_jpg.xmp. If I manually rename {image}.xmp to {image}_jpg.xmp, Nitro immediately recognizes and loads it – so it’s not an issue with the xmp file itself. Have I misunderstood what Reconnect XMP Sidecars does?
Cheers,
Ben
- You must be logged in to reply to this topic.