[KPhotoAlbum] Patch: file types as subcategories of media type
Michael J Gruber
michaeljgruber+gmane+kimdaba at fastmail.fm
Tue Jan 2 14:33:19 CET 2007
Robert L Krawitz venit, vidit, dixit 2007-01-02 14:12:
> From: Michael J Gruber <michaeljgruber+gmane+kimdaba at fastmail.fm>
> Date: Tue, 02 Jan 2007 13:32:20 +0100
> Robert L Krawitz venit, vidit, dixit 2007-01-02 12:44:
> > From: Michael J Gruber
> > <michaeljgruber+gmane+kimdaba at fastmail.fm>
> > Date: Tue, 02 Jan 2007 11:54:39 +0100
> > - As implemented, the file type is the last 3 letters of the file
> > name, converted to lower case. This is consistent with what KPA does
> > in other places and works with all files coming from 8+3 FAT file
> > systems (such as from a camera). It doesn't cover file endings like
> > "jpeg", "mpeg" or "tiff", but that's an easy fix if desired.
> > I think this should be done -- it's simply a matter of looking for
> > the rightmost `.'. Another question is case sensitivity -- should
> > this be case sensitive or not? I'd say probably not (as you've done
> > here).
> There are file types like ".xcf.bz2" also; that's why I didn't do the
> right search for "." right away. But I guess those are way less common.
> I don't think KPhotoAlbum handles these anyway, and they're really
> .xcf files that happen to be compressed.
Yes, I think going for the .* should be OK.
> > This is much better than "ignore raw files" -- depending upon what
> > I'm doing, sometimes I'd like to use the RAW images and sometimes I'd
> > like to use the JPEGs. It's not going to be very practical to use
> > this on large collections of images until subcategories are sped up,
> > though.
> I guess my collection isn't large enough ;)
> Seriously: Is it the initial loading/creation of the DB info which is
> slow, or the browsing by subcategory?
> Browsing by subcategory.
> There's another issue: suppose I have a collection of images some of
> which are shot RAW and some of which are JPEG (perhaps I ran low on
> space and backed off to JPEG). I'd like to select the RAW files where
> available and otherwise the JPEG's.
Oh yes, that's why I wrote "first step". I think what we really need is
the concept of a roll/collection/stack/exposure/you name it which
collects (semi-automatically) images which are "essentially the same
exposure", such as: a raw image and possibly several different jpeg's
developed from it; several images which result from editing a given base
image; a video and its edited and transcoded versions...
These rolls should (by default) share most attributes (location, person)
with the possibility of overriding the info individually (say, with
notes on the editing applied). For viewing purposes there should be a
default member of the roll, and one member would be designated as
"source" (raw if present, or original jpg/video...).
Well, this had been planned for a longer RFE mail after I would have
thought about the concept a little longer ;)
More information about the KPhotoAlbum