[KimDaBa] KimDaBa 2.0 is released.

Robert L Krawitz rlk at alum.mit.edu
Fri Oct 22 01:41:38 BST 2004

   From: jedd <jedd at progsoc.org>
   Date: Fri, 22 Oct 2004 01:26:07 +1000

   On Wed, 20 Oct 2004 10:26 am, Robert L Krawitz wrote:
    ] My general attitude is that the raw file is the digital negative,
    ] while the JPEG is a print from that negative.

    Yeah, I get that .. but the number of times I go back to the image
    and mess with it is pretty small, statistically.  I suppose your
    point is that you batch convert to jpg, so you're basically
    reserving the right.  I'd probably follow the same path but for my
    camera's woeful speed at writing to CF card, even the new 40x one
    I got for the last trip.  I often take bunches of photos (20-30)
    for later panorama work, and the internal memory fills up after
    the first 8-10 shots even on super-fine, leaving me standing
    around trying to hold the right position for the next shot.

Tripod time...

Granted, the number of images I'm going to seriously do anything with
is small, but I don't know a priori which ones I'm going to want to,
and I can't go back afterwards and make raw files from jpegs.

    Aside: anyone know of a good panorama tool?  I try hugin
    periodically but it consistently core dumps and/or completely
    fails to produce any kind of output.

That program is an incredible pain to compile.

    ] I use a heavily hacked-up version of dcraw to do the conversion to
    ] 16-bit TIFF, which produces a 38 MB file from my 6.3 MP camera.  This
    ] version of dcraw mitigates the clipping problems that tend to happen
    ] when shooting high dynamic range subject matter.  For example, try
    ] shooting a sunset with a telephoto lens with the sun sinking to the
    ] horizon.  If you look carefully, the result will probably be very
    ] unnatural.  If you underexpose it by a couple of stops, and process
    ] the raw image correctly, you can get natural-looking results, better
    ] than slide film and probably almost as good as color print film.  I'm
    ] happy to send you my version of dcraw if you'd like to try it.

    My initial response is .. I need to do a lot more photography.

    I do lots of sunsets, but mostly reflected light, and get some
    pretty good results even on jpeg.  But how close they are to the
    'original' is anyone's guess.  I'll grab dcraw and its gimp plugin
    and have a go with some raw image files from my Minolta and see
    how I go.  I don't think many of my photos actually push the
    boundaries .. but it's all one big learning experience.

The stock version of dcraw handles sunsets very badly; I've done some
work that improves it.  The problem tends to be with things like the
sun actually setting; you see bands of yellow and red surrounding the
sun that look quite unnatural.

    What kind of unnaturalness should I look out for in that, and other,
    shots?  Are you feeding those changes upstream, or are they really
    specialized for the kind of shots you're taking?

I've offered the changes upstream; thus far Dave hasn't taken them.
He doesn't seem to want to add a lot of features to the program.  He
has offered to provide a link when I get around to creating a web site.

    ] Yes, it would require hierarchical groups to implement hierarchical
    ] folders.

    Do you have any idea how this would be handled?  I mean, they
    sound simple, but I can't get my head around the useability of
    them .. when and how you determine where a new category fits into
    the hierarchy, interconnectedness of it all could become a real
    mess.  (I mean useability in the sense of the GUI component needed
    to manage them.)

Hierarchical folders is a fairly standard paradigm, no?

    ] Yes, I do.  I use the JPEGS that I generate as index prints, since
    ] kimdaba can't index raw files (and it would be very slow, in any
    ] event).
    ] Again, with JPEG's you're losing a good bit of dynamic range, which is
    ] important in a lot of cases).

    [nod] Having thought about this the past day or so .. I'm inclined
    to adopt this approach myself for a while and see how it shapes
    up.  I'll have to re-read the bit in the manual about raw images
    -- I seem to recall that lots of things aren't done to them that
    you kind of expect should be at the time you're taking the photo.

Nothing should be done to raw images at all in the camera; in
principle they should strictly contain the CCD counts.

    ] It shouldn't have to involve manual work.  If the checksum changes,
    ] the image has changed.

    If the checksum changes, how do you know you've got the same file?
    You can trust the file's name and location only so far.

You know that you *don't* have the same file when the checksum changes.

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 Gimp Print   --    http://gimp-print.sourceforge.net

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

More information about the Kphotoalbum mailing list