[KPhotoAlbum] Importing Canon raw files

[Robert L Krawitz]

   From: jedd <jedd at progsoc.org>
   Date: Wed, 10 May 2006 03:52:04 +1000

    It's certainly a very complicated situation, and I don't imagine
    there'll be any one solution that'll satisfy everyone.

    I tend to use only JPG's and occasionally PNG's (mostly they're
    what I use to pull in scans of old photos), and the very
    occasional RAW (from my Minolta).  With my PNG's I tend to just
    leave them in their original, large, form -- but sometimes prefer
    to keep a smaller JPG around for browsing.  With RAW's, I
    definitely keep a smaller JPG around, partly because my preferred
    browser doesn't cope with them, but mostly because it's painful to
    work with such large files.

    I imagine that this is the same problem, just with slightly
    different permutations of file types and needs, that everyone else
    has.

    Robert, I think it was, a while back described his RAW collection
    as the 'drawer' that he will reach into when he needs a pristine
    copy of a file, but the rest of the time he'll use the JPG.  Up
    until Jesper got himself a shiny new camera, it was easy to keep
    RAW files in the same directory structure, as KPA just ignored
    them.

Basically, the RAWs are my "digital negatives" and the jpegs are my
test prints.

With the Rebel that workflow wasn't much of a problem since the JPEG
is embedded in the RAW file, and I could pick the size I wanted (well,
I could once I installed the Wasia firmware).  With the 20D it's a bit
more problematic with KPhotoAlbum.  The 20D seems to embed a 1.5
megapixel JPEG in the .cr2 file, but it's not quite the same as what
the Rebel did -- the embedded thumbnail is too low in resolution to be
of much use, and it's relatively low quality (about 500 KB, which is
the "normal" quality).  In addition, the embedded thumbnail doesn't
carry the EXIF data; it's stored in the .cr2 file (and in the
explictly saved JPEG).

I like to shoot both JPEG and RAW.  It's a lot easier to process
having the high quality JPEG around from the start, and the current
FOSS tools for RAW processing (dcraw, and my hacked up dcraw) still
have a ways to go.  However, it's a real pain having KPhotoAlbum
import both files, especially since it doesn't show the filename
extension so I can't tell which one I'm selecting.

The behavior I'd like is to import the JPEG file if it exists, and
otherwise fall back to the RAW file.  I'm tempted to hack my own
version of KPhotoAlbum to ignore .cr2 files altogether for now; my
wife and I are going to Alaska next month and I expect to take
thousands of shots (all of them will be RAW+large fine JPEG) and I
need my workflow to be efficient during the trip.  Hopefully not more
than 8000 or so; that's about the limit of my disk.

    It's a nice analogy, though.  I wonder how workable it would be to
    have designated directory names (configurable) that would NOT be
    searched or indexed by KPA -- for example ./drawer/ -- that you
    could keep things in that you don't want KPA to worry itself
    about, but would still allow you to keep everything in a similar
    directory structure to your current layout?

I prefer not to do that, but it would be a workable compromise.

    Any kind of wildcard system would also work, too, say by ignoring
    all *RAW, *raw files (f.e.) -- but I see that getting pretty
    confusing real fast, as the only way to dictate / discover what
    KPA will ignore in your collection is from within KPA -- unlike a
    directory-name ignoring parameter.

    As I say, though, I don't imagine there's going to be a
    universally ideal solution to this problem.

Actually, KPA itself has a list of RAW extensions in it somewhere;
it's making a conscious decision to import them.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton