[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.
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
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
] 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."
More information about the Kphotoalbum