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

[Aleksi Halkola]

Hi Andi and others,

I applied the patches and from what I could see it works perfectly :). 
The versions were stacked correctly for both .nef and .jpg originals 
with the ; sperated list. I also like the unified settings page. Thanks 
a lot!

I have question regarding the stacking. I don't know if is a bug or a 
feature. I suppose it depends on ones logic. When new versions are found 
the tags are copied from the original (if that is chosen in the 
settings). In addition the new versions also get the untagged tag if 
that is also chosen in the settings. In my logic the images are no 
longer untagged since the tags are copied from the original and so at 
least I think that one should not add the untagged tag on top of all the 
other tags. I hope that made at least some sense. What do you think?

Cheers,

Aleksi


12.12.2010 21:38, Andreas Neustifter kirjoitti:
> 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
>>
>>
>>
>> _______________________________________________
>> KPhotoAlbum mailing list
>> KPhotoAlbum at mail.kdab.com
>> http://mail.kdab.com/mailman/listinfo/kphotoalbum