hi there damon or whoever might be able to answer this.
i have installed 0.9a7 specifically because of the mentioned support for .xmp sidecar files as i have a large number of files that already have sidecar files (named identically to the images but with added .xmp extension) with valuable information that i need to copy/rename to another location.
however, no matter what i do the sidecar files are not copied and renamed, they are just left in the original location with the original name…
is there some secret configuration option i need to enable to have the sidecar files be recognised?
yes, i use corel aftershot pro (used to be bibble a long time ago, it uses the orig_fname.orig_extn.xmp method, please note that this is not a linux spoecific problem as aftershot runs and is available on windows and mac too and it uses the same convention there.
the trouble with the adobe “standard” (how adobe loves proclaiming it’s own ideas as standards) is that it is perfectly valid to have a file named IMG_12345.CR2 AND a file named IMG_12345.JPG… in this case which file does the sidecar belong to?? bot the raw and the jpeg should be able to have their own sidecar files.
i can open a raw file in aftershot, named as above, and export it to a .JPG with the exact same basename, there’s no law against anyone doing this, so if the .xmp file replaces the extension of the raw file, how can the jpeg file then have it’s own sidecar file if it is edited independently??
aftershot uses this naming convention, on all platforms, because it solves this obvious problem with the adobe “standard”.
given that this is probably the only sensible variation from the adobe “standard”, can r.p.d not support this additional (sensible) naming convention for xmp sidecars?? it could be optional if for some reason you think it might be a problem.
The problem you mention is not a problem because the Adobe standard is to embed the XMP metadata in the jpeg file itself. The same goes with TIFF files. The specs are very clear about this.
but respectfully, damon, it is an actual problem for me now. aftershot always has and will continue to use sidecars for jpegs and tiffs in this way, on all platforms. i have tens of thousands of image files with these sidecars.
given that, as i said, this is really the only sensisble variation from adaobe’s standard, are you not prepared to enable r.p.d. to be useful users of aftershot (and other programs using this alternative “standard”)?
btw, believe me, i’m not trying to be a demanding freeloader here… i am an open source developer myself and understand all the caveats perfectly well. it’s just that r.p.d. seesm like a great toll and i’de love to see it be useable by folks in the case i mention.
i’ve had a quick look through the sources and i’d guess that a few additions to generatename.py and rpdfile.py might be what’s needed to cover this extra case.
as i said if you had some reason to think it might cause i problem for users without sidecar files name this way it could be an option, even a hidden option if you dislike the idea of supporting it that much.
would be worth a lot to folks in the same boat as me though.
if you are adamant you will not support this .xmp naming convention in rpd, then i have a couple of other ideas that might at least make what i want possible, but i’m not sure if this is the right place to discuss development ideas.
Rapid Photo Downloader to account for all departures from the industry standard by darktable, digiKam, Geeqie, and Bibble 5 / Aftershot, with a GUI preference option that accounts for all their variations from the standard now and into the foreseeable future.
Rapid Photo Downloader to act as a general purpose renaming tool for image and video files that are already on the file system and that have possibly been directly manipulated by the user, which then inevitably means renaming files that have had their metadata corrupted (it happens) or missing altogether (e.g. PNG files).
Option 1 complicates the program. As a developer it also means monitoring whatever deviations from the industry standard the developers of darktable etc. decide to do next.
Option 2 opens up a whole can of worms, which is why I don’t believe I’ve ever advocated using Rapid Photo Downloader for that purpose.
I suggest a specific tool that accounts for not only the use-case you present, but also one that allows users of darktable etc. to share metadata such as keywords and description with tools that do follow the industry standard. That way you cover not only your problem, but other problems that arise when the spec is not followed.
well, let me give you my thoughts on those two points. (they are free, and freely binnable ;))
the big rewrite of rpd seems to be your shot at making it a lot more modular and general purpose, so i’d stick with that approach. what would be needed is something like your current abstraction for filenames to be amended to allow abstraction of the handling of sidecar files.
you already seem to be doing this to a certain extent, with the handling of sidecars, related audio files etc.
if it’s abstracted into something configurable (even by editing the config file) then anyone can add a sidecar extension handling method. just like file paths or name it become something the user adds if they need to, not you.
(btw, i don’t think there are as many variations as you think.)
you will inevitably find (or not even realise) that your program will get used in all sorts of ways you didn’t anticipate, if it’s useful enough. but that isn’t in any way a problem for you to need to be concerned about, surely.
look, let me be frank. i’m guessing so much work has gone into 0.9 at this stage thet you are really loath to add something like another aspect of filename abstraction. you want to get it out there. you already done an enormous amount of work on this and suggestion something extra right now seems downright churlish. i understand.
provided you are not actually ideologically opposed to rpd being able to support a configurable sidecar naming scheme, then i have a couple of ideas how you could at least make it possible for it , or other things (extended functionality), to be addable.
if you want to take a technical discussion elsewhere i’ll give you my email address.
if you’re just not interested, i understand. just say so and i’ll take my non-existent non-business elsewhere.
in any case, extreme kudos for all the great work you’ve done on rpd so far. you are a gentleman and a scholar. cheers.
eh, while typing all that i see a reply came in from you. well, i think that would be exactly the kind of thing that would be worthwhile. what would be really great would be if rpd would support some concept of “plugins” for file handling, then i could write an optionally installable plugin that does just that from within rpd… are you interested in considering something like that?
Just highlight the text and the Quote button should pop up. Otherwise hit the speech bubble in the reply box while the text is highlighted.
I think the problem with your request is that rpd does on thing well now, and the author doesn’t want it to be a general purpose file move/rename tool.
I don’t mean to close the discussion on an interesting topic, but I have a 3 hour class to teach tomorrow for which I need to finish preparing for, among other responsibilities, so this discussion will need to wait until another day. Thanks for your ideas.
It may not be meant to do this, but this is exactly what I did with 15 years worth of photos, and it worked very well. For the old photos where the required minimum metadata was not present, the warning messages alerted me that there was a problem, which allowed me to manually reinvent history as necessary.
Having said that, this was (hopefully) a once in a lifetime effort, not something I would expect to use RPD for on an ongoing basis.
This is partly correct. Versions 0.4.x were already fairly modular. However their modularity was never sufficient to get around the core problem that Gtk+ 2.x is seriously out of date, which causes many problems for users – problems that will never be fixed.
I don’t want users to be in a situation where to change functionality they need to edit a config file. My goal is to have everything configurable through the program’s UI and/or command line switches.
That doesn’t concern me at all to be honest. The program will be out of alpha / beta when it’s ready and not before. What does concern me is the long-term implications of trying to keep up with how other programs go about handling XMP files in their own particular way, especially when one of them changes their approach (as someone is bound to at some point). Also, what happens when merely renaming the XMP is insufficient, and its contents need to be updated to reflect the file renaming changes?
What also concerns me, as I’ve said before, is that Rapid Photo Downloader is not a general purpose file renaming tool. It’s a downloader from cameras and other devices which renames files and backs them up. Sometimes people have used it to rename their existing files that they’ve already had on their computer for years, which is fine if it works for them. However It’s not written to do that. It doesn’t handle files with no metadata. It copies in place, rather than moving (i.e. cp vs mv on the command line). It doesn’t provide a friendly way to preview how all the files would be renamed, unlike dedicated file renaming tools. And that’s how I want to keep the program – focused, doing one thing as well as it possibly can.
The thing about a plugin system is that it’s not like anyone can plug into any one particular part of the program’s processing pipeline and be done with it. For example, it’s not like you can make changes to renaming XMP files in just the “copy files” process (see diagram):
In such a situation, changes need to be made in the scan device part of the code too. If that’s neglected then the UI won’t show the fact that XMP files will also be renamed, for instance. There are implications for the backup code too, and the program’s task tracking and time tracking algorithms. I could go on but the point is that although the program is somewhat modular, that doesn’t mean that a plugin system can work by only being attached into one of those modules. It would need to be attached to several, and in quite complex ways that would make an already complex program even more complicated.
There is no development mailing list because I’m the only developer. One gentleman expressed interest in working on the 0.4.x code a few years ago but then I never heard from him again. Maybe he looked at the code and thought the code sucked. Maybe he was right LOL
In any case I hope the code is in better in every respect than it was back in the 0.4.x days.
aftershot always has and will continue to use sidecars for jpegs and tiffs in this way, on all platforms. i have tens of thousands of image files with these sidecars.
