[KPhotoAlbum] Patch for loading only one version of a file into the DB.

Jesper K. Pedersen blackie at kde.org
Wed Dec 29 20:54:55 GMT 2010


Andreas, Jan,
Can you please let me know which if these patches are still pending to be 
applied.

Cheers

On Sunday 12 December 2010 21:38:30 Andreas Neustifter wrote:
> Hi all!
> 
> I'm sorry this EMail is so long, but I hope its worth the read...
> 
> I completely revised my patch and approached this in a whole different
> manner. The discussion on Aleksi's topics with file version regexes
> helped a lot with this.
> 
> I have split up the work into several patches since there are some
> changes that are useful in their own right:
> 
> 0003-Whitespace-fixes.patch:
> This fixes some whitespaces in the files for the following patches.
> 
> 0004-Moved-all-file-search-settings-to-single-page.patch:
> The settings on how new files are search for and how information is
> loaded for this files is intermingled. This patch separates the file
> searching and information loading settings onto properly separated
> tabs. I think this is useful in general because the settings are
> ordered more logically.
> 
> 0005-Cache-invariant-settings-so-they-are-only-loaded-onc.patch:
> There are some strings and regexes that are constant throughout the
> NewImageFinder::loadExtraFiles() loop, this patch pulls them out and
> creates them only once. As with 0004 useful on its own.
> 
> 0006-Support-multiple-replacement-regexes-for-file-versio.patch:
> This patch creates support for several regexes for the original file
> version detection. Those regexes are separated with semicolons and
> processes from left to right. The first regex that matches an existing
> file is used as original file.
> 
> When used with e.g. "(.*)/(.{8})(.*)" as modifiedFileComponent and
> "\\1/\\2.JPG;\\1/\\2.CR2;\\1/\\2.CRW" as originalFileComponent this
> stacks all files with the same 8 characters onto each other.
> 
> This does not prevent the loading of multiple files but merely stacks
> them on top of each other.
> 
> 
> This addresses most of the comments on the old patch and actually
> works better than my previous patch.
> 
> Comments?
> 
> Andi
> 
> On 10 December 2010 07:57, Miika Turkia <miika.turkia at gmail.com> wrote:
> > On Tue, Dec 7, 2010 at 8:51 AM, Andreas Neustifter
> > 
> > <andreas.neustifter at gmail.com> wrote:
> >> Hi!
> >> 
> >> On 6 December 2010 12:45, Jan Kundrát <jkt at gentoo.org> wrote:
> >> > On 12/01/10 22:38, Andreas Neustifter wrote:
> >> >> I wrote a patch that adds an option to only load one version of an
> >> >> image and skips all other files with same file name but different
> >> >> extensions.
> >> > 
> >> > Hi, considering that idea, wouldn't it make more sense to actually
> >> > replace
> >> > the reference to the RAW file with the JPEG one? That should give you
> >> > faster
> >> > access to the image as well as "better viewing experience" because the
> >> > JPEG
> >> > one presumably has stuff like color correction applied.
> >> 
> >> I don't know about the general case but my camera puts a JPG preview
> >> into the RAWs EXIF data. This preview looks almost identical to the
> >> developed RAW file , since KPA uses this JPG previews there is no
> >> difference between the JPEG and RAW viewing experiences. But I guess
> >> in the overall case this replacement would make sense.
> > 
> > I believe the intention here is to point to the developed jpeg version of
> > the raw not the embedded thumbnail.
> > 
> >> > Maybe enabling this functionality (the one you
> >> > just added) unconditionally when the "ignore raw files" option is set?
> >> 
> >> I don't like this idea since the user experience would be different
> >> than expected.
> >> 
> >> But maybe its possible to just throw out the "no RAW when JPEG" option
> >> and use the more general "only one image per extension" rule? Any
> >> comments from other users?
> > 
> > Jan's suggestion sounds good to me. However, looking at the patch I could
> > not see what determines the order on which files are searched for. Looks
> > like the first hit is what is used and that could be pretty much any file
> > extension? or do we have a specific order when going through files?
> > 
> > Anyway, I am looking forward to this functionality...
> > 
> > theBro

-- 
Having trouble finding a given image in your collection containing
thousands of images?

http://www.kphotoalbum.org might be the answer.



More information about the Kphotoalbum mailing list