[KPhotoAlbum] Raw workflow

[Miika Turkia]

On Tue, Aug 28, 2012 at 4:03 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:
> On Tue, 28 Aug 2012 07:15:12 +0300, Miika Turkia wrote:
>> On Mon, Aug 27, 2012 at 10:02 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:
>>> On Mon, 27 Aug 2012 20:58:16 +0300, Miika Turkia wrote:
>>>> On Mon, Aug 27, 2012 at 6:59 PM, Robert Krawitz <rlk at speakeasy.net> wrote:
>>>>> On Mon, 27 Aug 2012 07:48:22 +0300, Miika Turkia wrote:
>>>>>> On Sun, Aug 26, 2012 at 10:43 PM, Robert Krawitz <rlk at speakeasy.net> wrote:
>>>>>>> The kpa manual states:
>>>>>>>
>>>>>>> "A few settings are recommended for a RAW workflow. First is to enable
>>>>>>> the using of the embedded thumbnail. This will give a tremendous speed
>>>>>>> boost over decoding each raw file each time they are viewed (check also
>>>>>>> the minimum dimension configuration to ensure decent quality). Second
>>>>>>> one is for the New Image Finder to automatically stack the developed
>>>>>>> versions over the RAW file (developed image must be on same directory as
>>>>>>> the original). This requires regular expressions as described in ."
>>>>>>>
>>>>>>> The last is obviously a reference to the new image finder settings, but
>>>>>>> it doesn't explain clearly what the search regexp and file replacement
>>>>>>> texts should be.  This would benefit greatly from an example (I haven't
>>>>>>> figured out what they need to be myself!").
>>>>>>
>>>>>> The reference points to chapter "New Image Finder Settings" where the
>>>>>> regular expressions I used at the time of writing are shown. Is the
>>>>>> link missing from your manual? It is working on HTML and PDF version
>>>>>> from docs.kde.org. Anyway, what I currently have is:
>>>>>>
>>>>>> Search: (_(v){0,1}([0-9]){1,2}){0,1}\.(jpg|JPG|tif|TIF|png|PNG)
>>>>>> Orig: .NEF;.CR2;.JPG;.jpg;.ORF
>>>>>
>>>>> I currently have
>>>>>
>>>>> Search: _[0-9]{4}\.(jpg)
>>>>>
>>>>> Orig: .cr2;.crw;.jpg
>>>>>
>>>>> but still get two copies of each image.
>>>>
>>>> _1234.jpg is the suffix that matches your regex and should be replaced
>>>> with cr2, crw or jpg. If you have the JPGs already in the database and
>>>> try to match RAWs you need to add the raw into the regex. Following is
>>>> my guess of what you need as search:
>>>> (_[0-9]{4}){0,1}\.(jpg|cr2|CR2|crw|CRW)
>>>
>>> OK, I guess I'll know in a few hour, when it's done importing
>>> everything.
>>>
>>> Evidently I don't understand what the Orig and Search are supposed to be
>>> fore.  I didn't see .NEF or .CR2 in the Search, so it wasn't evident to
>>> me that they should have been in there.
>>
>> This is because I work on RAW. Thus there is no such case for me that
>> JPG exists in KPA and RAW should be found.
>>
>> There are at least two places to get the information regarding this feature:
>> - Right click on the "File version search regexp:" or "Original file
>> replacementtext:" and select "What's this?"
>> - The manual that is available in Khelpcenter and as PDF/HTML from KDE docs
>>
>> Seems that this is not clear enough currently and all the help in
>> improving these is appreciated.
>
> It isn't very clear.  I'd be happy to suggest better wording, if I
> myself knew what they meant.
>
>>> The stacking is complex enough that I think a few examples and use cases
>>> would be appropriate.  RAW+JPEG is common enough (specifically, most
>>> cameras that provide RAW files provide the option for RAW only,
>>> RAW+JPEG, or JPEG only) that that example should be provided.
>>
>> I optimistically introduced the workflows chapter to describe
>> different workflows for different needs. Currently there is only one
>> and another (panorama workflow) in the works. So if you or anyone else
>> is interested in writing a flow, I'll be just happy to include it.
>
> Again, I'd be happy to, but I need to first understand how to get
> stacking to work.
>
>>>> This works so that for each new image found, whatever matches the
>>>> search regex is replaced with the original replacement text (in your
>>>> case first cr2, if not found with crw, and finally with jpg). So in
>>>> your current regex only the files ending with _1234.jpg are matched
>>>> and this part is replaced with e.g. .cr2
>>>
>>> This still isn't clear.  If I want the JPEG files to be at the top of
>>> the stack, what do I need to have in the orig box?
>>
>> The newly found image goes to the top of the stack (IIRC). I don't
>> think there is any way to have the specific image automatically on the
>> top.
>
> Consider it an RFE that it be possible to specify stacking order,
> somehow.  I'm not sure precisely what that should consist of -- perhaps
> a list of regular expressions, and each image name in the stack is
> matched against the list, and the stack order matches the order of the
> regexp list.  For example:
>
> .*\.(cr2|crw|nef)
> .*_modified\.jpg
> .*.jpg
>
> Suppose we have the following files:
>
> img_0000.cr2
> img_0000_modified1.jpg
> img_0000_modified2.jpg
> img_0000_xxx.jpg
> img_0000.jpg
>
> We match each of those filenames against each regular expression in the
> list, resulting in the following (image,index) pairs:
>
> img_0000.cr2              0
> img_0000_modified1.jpg    1
> img_0000_modified2.jpg    1
> img_0000_xxx.jpg          N/A
> img_0000.jpg              2
>
> The following rules then define the stacking order:
>
> 1) Images with lower indices stack above images with higher indices.
>
> 2) Images that do not match any of the regular expressions stack at the
> bottom.
>
> 3) If there is more than one image with the same index, they are sorted
> in lexicographic order (in whatever locale is most appropriate in this
> case).

In my workflow the current model to stack the latest find to the top
works fine. However, it really sounds that it does not support new
users for the autostacking feature. Of course small "errors" can be
fixed manually but your case really sounds like there should be at
least an option to select that the top image should not be RAW.

Anyway I think that currently also the handling of RAW+JPG import
simultaneously is not implemented and nothing is autostacked.

>>> Also, some cameras (like the original Rebel, and others that used the
>>> .crw format) named the files differently: crw_xxxx.crw for the RAW,
>>> img_xxxx.jpg for the JPEG.  I assume (since I didn't specify crw or img
>>> in the regexp) that that would do the right thing, since it won't try to
>>> match those prefixes?
>>
>> The prefix should also changed. Following example should handle the
>> case you describe above properly. However, combining this with your
>> other renaming convention will also have to be figured out. BTW for
>> testing purposes I suggest you set up a test directory with a few
>> images only and start KPA with -c <test-dir> parameter. This way it'll
>> take only a few seconds to see whether the config works or not.
>> Search regex: crw_([0-9]*)\.crw
>> Replace text: img_\1.jpg
>
> Ah.  I see.  I missed that about the prefix.  The documentation didn't
> give any examples of using replacement text like this -- I'm familiar
> enough with it (I've done quite a bit of programming work with regular
> expressions), but it didn't occur to me that that would work in this
> context.  That's also something a good example would make clear (but
> perhaps the usage could be explained briefly here)
>
> From this, I believe that the following would work:
>
> Search: (crw|img)_([0-9]{4})\.(crw|cr2)
> Replace: \1_\2.jpg
>
> However, that doesn't square with the documentation that it's a *string*
> that is used to replace *the match*, and can be a list that is tried in
> order.  In this case, there are four possible matches (\0 is the whole
> string, \1 is (crw|img), \2 is ([0-9]{4}), and \3 is (crw|cr2)).  So I'm
> still not clear.

The replace text is tried in order if there is multiple strings
separated with semicolon. Thus .jpg;.crw would first try to replace
the regex match with .jpg and if not found with .crw. It looks to me
that your suggestion would not work as you have to change the prefix,
and not keep it intact. I believe you should use following when using
the search regex as you defined it:
Replace: img_\2.jpg;crw_\2.crw;crw_\2.cr2

> I'll have to look at that separately.  Right now, I want to get the
> stacking working.

ack

miika