[KPhotoAlbum] Raw workflow

[Miika Turkia]

On Tue, Aug 28, 2012 at 4:55 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:
> On Tue, 28 Aug 2012 16:46:30 +0300, Miika Turkia wrote:
>> On Tue, Aug 28, 2012 at 4:03 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:
>>>
>>> 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.
>
> Some people would want the RAW to be the top of the stack.

True. A current workaround is to search for RAW only. The disadvantage
is that the whole stack is not available in this case and thus you
cannot annotate the full stack. For me the developed JPG on top is
ideal and still gives me access to the RAW easily with the
open-raw.pl.

>> Anyway I think that currently also the handling of RAW+JPG import
>> simultaneously is not implemented and nothing is autostacked.
>
> That appears to be a bug?

Yep. I tried to put it nicely ;)

>>>> 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
>
> That's definitely not obvious from the description, and it doesn't match
> the example.

I hadn't seen a case like yours so I thought matching the suffix to be
sufficient. More examples and clearer explanation is definitely
needed. Basically we are talking about normal regexp like
s/\.raw/.jpg/ but instead of writing multiple regexes the latter part
can expanded automatically.
s/\.raw/.jpg/ and s/.\raw/.tif/ can be compressed into s/\.raw/.jpg;.tif/.

Of course everything becomes quite messy when you take the different
versions and sources into account and need to match suffix and prefix.

BTW did you get your problem solved?

miika