[KPhotoAlbum] Raw workflow

[Robert Krawitz]

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).

>> 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.

> This will change both the prefix and suffix from the existing file and
> use whatever is between the parentheses in the middle. Thus when a new
> file crw_1234.crw is found it will be changed to img_1234.jpg. And if
> this JPG file is found in KPA DB, autostacking will occur.
>
>>> BTW I do see the reference to the chapter describing these regexes in
>>> git - both on my clone and web version. In the workflows.docbook
>>> <xref linkend="opt-search-new" />
>>
>> Did you inspect the installed documentation in the KHelpCenter browser
>> (not just the source file)?
>
> Yes, I have inspected the KHelpCenter both from GUI and
> workflows.docbook files installed. (Systemwide 4.2 from Dominik's PPA
> repository and GIT version from my own compile.) Now the question is,
> how does the reference disappear in your version.

I'll have to look at that separately.  Right now, I want to get the
stacking working.
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton