EXIF Copy: feature request

[DavidB]

Chris

BB Pro Help explains the logic of EXIF Copy as follows:


Normally EXIF data is only copied to similarly named files e.g. CRW_0001.CRW to CRW_0001.JPG. To allow EXIF data to be copied to HTML images it will also copy the data to files with the _std suffix e.g. CRW_0001.CRW to crw_0001_std.jpg
Please could the provision made for the _std suffix be optionally extended to cover any suffix to the source file name?

The reason for this request is that I name conversions of the same images made with different RAW converters with suffixes to identify the converter used. Converters which are not as well house-trained as BB Pro fail to copy some or all of the metadata from the RAW file to the conversion, and I have to use BB Pro to add the data to the converted file. At present, if I want to keep the identifier suffixes, this involves batch renaming the files twice, once in order to use EXIF Copy, and once to restore the suffix.

One way of implementing this feature would be to have a tick box option to allow partial file name matches in the EXIF Copy dialogue box.

Thanks for considering this.

David

[Chris Breeze]

I'll give it some thought and take a look at the code to see how easy it would be to add.

Do you have any suggestions as to how the option should be presented in the EXIF Copy dialog?

[DavidB]

Do you have any suggestions as to how the option should be presented in the EXIF Copy dialogue?

Chris

Thank you very much for considering the request.

Following on from what I said in my last post, I suggest that there is space in the dialogue (perhaps with only a very small increase in its height) to insert an additional check box between the directory name edit box and the 'Copy EXIF to TIFF files' check box. The new check box could be labelled 'Allow partial file name matches' or 'Copy to file names with suffixes', and would be unchecked by default.

There is also enough space at the lower left corner of the dialogue for an additional button, which could be used to call the relevant Help page, which would need corresponding amendment.

I hope this helps.

David

[Chris Breeze]

Unfortunately it is a little more difficult to add this than I first thought. Currently it iterates through the images in the source folder checking for exact matches in the destination folder. To check for filenames with suffixes it would have to check every file in the source folder against every file in the destination folder. You also get the problem where more than one source image may match the same destination image
e.g.
src folder: a.jpg, ab.jpg
dest folder: ab.jpg
a.jpg and ab.jpg would match ab.jpg in the dest folder.

[DavidB]

Unfortunately it is a little more difficult to add this than I first thought. Currently it iterates through the images in the source folder checking for exact matches in the destination folder. To check for filenames with suffixes it would have to check every file in the source folder against every file in the destination folder. You also get the problem where more than one source image may match the same destination image.
I quite understand; these issues do make it trickier than I had thought.

Presumably there is already code to check for the _std suffix of images generated for HTML. Is it possible to make this variable rather than constant, so that the user (admittedly at some risk, which would need to be the subject of a warning) could check for his or her own suffix? In that case, the check box would need to be supplemented with a small edit box (default values: check box unticked, and a 'greyed out' _std in the edit box).

I hope this alternative helps. Thank you again for giving it some thought.

[Chris Breeze]

I've found a simpler way to do this and will include it in the next release. To keep things simple it won't try to resolve cases where multiple source files match single destination files and will simply copy the EXIF data multiple times when this occurs.

[DavidB]

Chris.

Very many thanks. I think that your approach is sensible, and the level of risk inherent in it is acceptable. From my experience, I'd guess that copying one to many will happen more frequently than (the much more awkward and risky) copying many to one. Appropriate safeguards and advice in Help, as previously discussed, should reduce the risk even further.

David