[KPhotoAlbum] What does this mean?

Robert Krawitz rlk at alum.mit.edu
Sat Feb 1 19:10:39 GMT 2014 

On Sat, 1 Feb 2014 20:26:53 +0200, Miika Turkia wrote:
> --001a11351c9a4762ec04f15c6fe4
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.

That's not what I want.  I usually want either all of the JPEG files,
or all of the RAW files with JPEGs for missing RAW files, and then
batch process everything before uploading them or putting them on a
flash drive.  If I shot an event and have 1000 or 1500 frames, I need
something able to handle that.

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

That random ordering means that the ordering expressed in
originalFileComponent is useless (at least for RAW+JPEG workflows), it
appears.

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

So I'm still not quite sure what that error message means.  I can see
that I don't need to worry about it per se, but it's still mystifying.

>> > 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
>>
>
> --001a11351c9a4762ec04f15c6fe4
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 1, 2014 at 6:29 PM, Robert Krawitz <span dir="ltr"><<a href="mailto:rlk at alum.mit.edu" target="_blank">rlk at alum.mit.edu</a>></span> wrote:<br>
> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, 1 Feb 2014 18:01:47 +0200, Miika Turkia wrote:<br>
> > I am guessing that you shoot raw+jpg and KPA does not seem handle this<br>
> > situation properly when importing both on same go. Reading the error<br>
> > messages suggests that the logic is not really sound.<br>
> <br>
> </div>Yes, I do often shoot RAW+JEPG, and yes, I've had a lot of problems<br>
> with kpa over the years with this.  In particular, autostacking was a<br>
> real pain to set up correctly, and even with it set up, which image is<br>
> at the top of the stack is arbitrary (which means if I want to copy<br>
> out just the RAWs or just the JPEGs I have to commit some unnatural<br>
> acts -- and if I want the RAWs for frames that have them and JPEGs<br>
> otherwise, I have to do things that in some cultures would be<br>
> considered crimes against nature).<br></blockquote><div><br></div><div>A script included in KPA called <a href="http://open-raw.pl">open-raw.pl</a> 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.<br>
> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <div class="im"><br>
> > I just did a quick test with just two images in Picture directory<br>
> > (PC100178.ORF and PC100178.jpg). And I get the same error message. I<br>
> > suppose this means that KPA cannot copy data from one new image to the<br>
> > second new image (as there is none available). It is also possible that raw<br>
> > and jpg are not even recognized as different versions of same image...<br>
> > Anyway, if you are importing raw+jpg you can just ignore this error message<br>
> > (or better yet, improve the logic of KPA in this situation ;)<br>
> <br>
> </div>For starters, I don't understand what "modifiedFileComponent" and<br>
> "originalFileComponent" really mean and what they do.  And I don't<br>
> know what data it's trying to "copy" from A to B.  But it *is*<br>
> apparent to me that if the ordering within originalFileComponent is<br>
> supposed to be meaningful, and it's trying to do some kind of copying<br>
> at the time the file is read, and if the order in which files are read<br>
> is arbitrary (as it would be when using readdir), that there would be<br>
> a sequencing problem.<br></blockquote><div><br></div><div>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.<br>
> <br></div><div>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.<br>
> </div><div><br></div><div>miika<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <div class="im"><br>
> > On Mon, Jan 20, 2014 at 4:40 AM, Robert Krawitz <<a href="mailto:rlk at alum.mit.edu">rlk at alum.mit.edu</a>> wrote:<br>
> ><br>
> >> I have the following file version settings:<br>
> >><br>
> >> [FileVersionDetection]<br>
> >> autoStackNewFiles=true<br>
> </div>>> copyFileComponent> copyFileReplacementComponent> detectModifiedFiles=true<br>
> <div class="HOEnZb"><div class="h5">>> modifiedFileComponent=([a-z]{3}_[0-9]{4})\\.(jpg|cr2|crw|tif)<br>
> >> originalFileComponent=\\1.cr2;\\1.crw;\\1.tif;\\1.jpg<br>
> >><br>
> >> What do these messages mean?<br>
> >><br>
> >> Original info not found by name for<br>
> >>  "/home/rlk/images/7d2/dcim/100eos7d/img_3622.jpg" , trying by MD5 sum.<br>
> >> Substitute image  "/home/rlk/images/7d2/dcim/100eos7d/img_3622.jpg"  found.<br>
> >> How did that happen? We couldn't find info for the original image<br>
> >> /home/rlk/images/7d2/dcim/100eos7d/img_3622.jpg; can't copy the original<br>
> >> data to /home/rlk/images/7d2/dcim/100eos7d/img_3622.cr2<br>
> >> Original info not found by name for<br>
> >>  "/home/rlk/images/7d2/dcim/100eos7d/img_3978.cr2" , trying by MD5 sum.<br>
> >> Substitute image  "/home/rlk/images/7d2/dcim/100eos7d/img_3978.cr2"  found.<br>
> >> How did that happen? We couldn't find info for the original image<br>
> >> /home/rlk/images/7d2/dcim/100eos7d/img_3978.cr2; can't copy the original<br>
> >> data to /home/rlk/images/7d2/dcim/100eos7d/img_3978.jpg<br>
> <br>
> --<br>
> Robert Krawitz                                     <<a href="mailto:rlk at alum.mit.edu">rlk at alum.mit.edu</a>><br>
> <br>
> MIT VI-3 1987 - Congrats MIT Engineers 5 straight men's hoops tourney<br>
> Tall Clubs International  --  <a href="http://www.tall.org/" target="_blank">http://www.tall.org/</a> or 1-888-IM-TALL-2<br>
> Member of the League for Programming Freedom  --  <a href="http://ProgFree.org" target="_blank">http://ProgFree.org</a><br>
> Project lead for Gutenprint   --    <a href="http://gimp-print.sourceforge.net" target="_blank">http://gimp-print.sourceforge.net</a><br>
> <br>
> "Linux doesn't dictate how I work, I dictate how Linux works."<br>
> --Eric Crampton<br>
> </div></div></blockquote></div><br></div></div>
>
> --001a11351c9a4762ec04f15c6fe4--


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

More information about the Kphotoalbum mailing list