[KPhotoAlbum] What does this mean?

Miika Turkia miika.turkia at gmail.com
Sat Feb 1 18:26:53 GMT 2014

On Sat, Feb 1, 2014 at 6:29 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:

> On Sat, 1 Feb 2014 18:01:47 +0200, Miika Turkia wrote:
> > I am guessing that you shoot raw+jpg and KPA does not seem handle this
> > situation properly when importing both on same go. Reading the error
> > messages suggests that the logic is not really sound.
> Yes, I do often shoot RAW+JEPG, and yes, I've had a lot of problems
> with kpa over the years with this.  In particular, autostacking was a
> real pain to set up correctly, and even with it set up, which image is
> at the top of the stack is arbitrary (which means if I want to copy
> out just the RAWs or just the JPEGs I have to commit some unnatural
> acts -- and if I want the RAWs for frames that have them and JPEGs
> otherwise, I have to do things that in some cultures would be
> considered crimes against nature).

A script included in KPA called open-raw.pl might ease your pain. It is
intended for opening the raw files of selected images with a raw editor, or
the jpg if raw is not found. Should be available on KPA when right clicking
and selecting "Invoke External Program" - Current Item / All Selected Items
- Open in RAW editor. Depending on your use case, the script might need
some adjusting.

> > I just did a quick test with just two images in Picture directory
> > (PC100178.ORF and PC100178.jpg). And I get the same error message. I
> > suppose this means that KPA cannot copy data from one new image to the
> > second new image (as there is none available). It is also possible that
> raw
> > and jpg are not even recognized as different versions of same image...
> > Anyway, if you are importing raw+jpg you can just ignore this error
> message
> > (or better yet, improve the logic of KPA in this situation ;)
> For starters, I don't understand what "modifiedFileComponent" and
> "originalFileComponent" really mean and what they do.  And I don't
> know what data it's trying to "copy" from A to B.  But it *is*
> apparent to me that if the ordering within originalFileComponent is
> supposed to be meaningful, and it's trying to do some kind of copying
> at the time the file is read, and if the order in which files are read
> is arbitrary (as it would be when using readdir), that there would be
> a sequencing problem.

You get some help when configuring these fields when clicking on the label
and selecting "Waht's this?". The idea is that modifiedFileComponent is
used to detect the base name of an image file. The originalFileComponent is
used to add known extensions of original files to the base name. Then we
check if a file with this name is found on the same directory. Originals is
a semicolon separated list that is iterated through until a file is found
with the given name, or we run out of choices. So the order we have in
orginalFileComponent is the order we try to detect the original file.
However, the current drawback is that we read new files in "random" order
and thus end up with non-optimal stacking.

The copying from A to B is used to copy metadata that is inserted in KPA to
newly found images. This is only meaningful when you tag the images and
after that edit it with e.g. raw developer for the final image. After this
when the new pic is found and noticed to be derivative work of the
original, it is autostacked and tags associated with the new image are
copied from the original. (All this, of course, is dependent on your
configuration.) So the copying of tags is irrelevant in case one is
importing raw+jpg.


> > On Mon, Jan 20, 2014 at 4:40 AM, Robert Krawitz <rlk at alum.mit.edu>
> wrote:
> >
> >> I have the following file version settings:
> >>
> >> [FileVersionDetection]
> >> autoStackNewFiles=true
> >> copyFileComponent> copyFileReplacementComponent>
> detectModifiedFiles=true
> >> modifiedFileComponent=([a-z]{3}_[0-9]{4})\\.(jpg|cr2|crw|tif)
> >> originalFileComponent=\\1.cr2;\\1.crw;\\1.tif;\\1.jpg
> >>
> >> What do these messages mean?
> >>
> >> Original info not found by name for
> >>  "/home/rlk/images/7d2/dcim/100eos7d/img_3622.jpg" , trying by MD5 sum.
> >> Substitute image  "/home/rlk/images/7d2/dcim/100eos7d/img_3622.jpg"
>  found.
> >> How did that happen? We couldn't find info for the original image
> >> /home/rlk/images/7d2/dcim/100eos7d/img_3622.jpg; can't copy the original
> >> data to /home/rlk/images/7d2/dcim/100eos7d/img_3622.cr2
> >> Original info not found by name for
> >>  "/home/rlk/images/7d2/dcim/100eos7d/img_3978.cr2" , trying by MD5 sum.
> >> Substitute image  "/home/rlk/images/7d2/dcim/100eos7d/img_3978.cr2"
>  found.
> >> How did that happen? We couldn't find info for the original image
> >> /home/rlk/images/7d2/dcim/100eos7d/img_3978.cr2; can't copy the original
> >> data to /home/rlk/images/7d2/dcim/100eos7d/img_3978.jpg
> --
> Robert Krawitz                                     <rlk at alum.mit.edu>
> MIT VI-3 1987 - Congrats MIT Engineers 5 straight men's hoops tourney
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20140201/4ce6261f/attachment.htm>

More information about the Kphotoalbum mailing list