#18 Original / Derived images handling

open
nobody
None
5
2011-05-01
2011-05-01
Anonymous
No

As of Rev. 163 originals are announced along with a file as soon as a file with an identical name shows up within a given subfolder of the images own folder. This is a _very nice_ feature, indeed.

However, it seems advisable to split derived files and original files in their directory structure, instead of using subfolders within the original files. E.g. a file structure like this might come to mind (R for Raw, though it doesn't impose to be NEF, could also be JPG):

R/R001/Shooting1
filename1.jpg
filename2.jpg
filename3.jpg
R/R001/Shooting2
filename4.jpg
filename5.jpg
filename6.jpg
R/R002/Shooting4
filename7.jpg
filename8.jpg
R/R002/Shooting5
filename9.jpg
[...]

In my current workflow I split the R* folders such, that they are compatible with my "offline backup medium", say ~4GB for a DVD Rom, while I keep shootings together.

In postprocessing one might come up with derived files like

D/D001/Shooting1
filename1.jpg
filename3.jpg
D/D002/Shooting5
filename9.jpg

A splitting like this would greatly reduce the risk of accidentially working on the original files instead of derived copies (most critical in a JPG workflow), it simplify offline backup strategies like the one outlined above and makes it easy to dump down a "client copy" of the images by using the D/ structure.

Currently, I do it by hand, though as the "originals" folder goes right into some automatisation of this process, I'd like to suggest it here. So if Mapivi could come up with path handling like "Target Folder fixed part" and "variable part" as it's done in the import wizard for this cross checking one would already be there.

BTW: This directory layout is heavily inspired by Kroghs "DAM Book" (http://gso.gbv.de/DB=2.1/PPNSET?PPN=581078365, or for the German edition http://gso.gbv.de/DB=2.1/PPNSET?PPN=523589875\). Though he's always talking about quite expensive commercial tools Mapivi makes a very good substitute in many places. IMHO the main difficulty is currently the integration of "real raw". (Feaseble though as well.)

Discussion

  • Building upon the above procedure I came up with a simple plugin for mapivi that does actually the derivation of files resulting in the above directory layout.

    Additionally, finding that The Gimp isn't too careful with my metadata the script also learned to copy metadata from the original file to the target file by means of exiftool-library.

    The plugin works as follows:
    - Select images where derivatives should be created
    - Call Derive files
    - All files get copied to a parallel structure with D instead of R as outlined above
    - If a D-file already exists it is not overwritten by the contents of the R-file but instead only the metadata get propagated.

    Here is the essence of the code required.

    #!/usr/bin/perl -w

    use strict;
    use warnings;
    use diagnostics;

    use File::Basename;
    use File::Path;
    use File::Copy;
    use Image::ExifTool qw(:Public);

    my $nr = @ARGV;
    my $dir = $ARGV[0];
    if (-d $dir) {
    print "Error: first argument ($dir) is a valid directory.\nThis Mapivi Plug-In is developed for Mapivi version >= 0.7.5\n";
    exit();
    }

    for (0 .. ($nr-1)) {
    my $srcname = $ARGV[$_];
    my $dstname = $srcname;
    $dstname =~ s#/R#/D#g;
    my $srcdir = dirname($srcname);
    my $dstdir = dirname($dstname);
    mkpath($dstdir);
    if (-e $dstname) {
    my $exifTool = new Image::ExifTool;
    my $info = $exifTool->SetNewValuesFromFile($srcname);
    my $result = $exifTool->WriteInfo($dstname);
    }
    else {
    copy($srcname, $dstname);
    }
    }
    exit();