[KPhotoAlbum] Feature Request: Handling of stacks during operations

[Martin Jost]

Hello,

Am 19.08.2012 08:23, schrieb Miika Turkia:
> On Sun, Aug 19, 2012 at 8:43 AM, Martin Jost <lists at majo.name>
> wrote:
>> 2. If I have stacks closed, then select all visible images and copy
>> images by drag and drop from KPA to a directory, I get all images
>> copied - even the "lower" ones in the stack. I would like to have
>> only the top image of a stack copied IF the stack is closed.
> 
> My compile works the way you want. Only the top-most image of a
> stack is copied over (this works for the drag-and-drop, generate HTML
> and KIPI plugins).

Then I might just need to wait for the new release.
Let me know, if there is a state, which makes sense to test.
(A RC or just "head of trunk" [SVN-speak] in GIT)

>> 2a. When I think of it, an operation in the context menu "Close
>> all (visible) stacks" and "Open all (visible) stacks)" would be
>> nice.
> 
> The collapse/expand all stacks under view menu has been enough for
> me. I do not really mind whether it is all or visible images that
> get treated. (For some reason it might not be always enabled.)

Haven't seen that ! Thanks !
Might have had the blinders on ... (Or tomatoes on my eyes to translate
the German expression)
(Or it's another of the kalbuminitrc issues - don't know)

>> So probably it's much too late for a feature request right now -
>> let me know if I should enter it in the bugtracker or wherever else
>> if the feature makes sense but is too late now... (Or if similar
>> features are already present (where ?) or planned)
> 
> Does this suffice or would you still need some tweaking on some of 
> these features? (I suppose the KPhotoAlbum manual should be updated 
> regarding the annotation of stacks.)

Sounds good. I will see in an RC. (Or be curious and get it from git)
Sounds like the things I would like are already there !

>> Regards and thanks for one of my favorite programs (*) !
> 
> hear hear

I mean it ! I have a small list of "discoveries of the year". This
contains (besides the obvious Linux/GNU/KDE):
- emacs
- firefox and thunderbird
- openoffice
- freemind
- KPA
- JAlbum
- AutopanoPro (see below)
- notepad++ (for Windows)

> This is something that should be addressed. As far as I know we use 
> KDE APIs to manage the settings but I might be wrong. Is it really
> the kphotoalbumrc that is preventing the autostack stuff from
> appearing or is it the kphotoalbumui.rc?

It seemed to be
./.kde4/share/config/kphotoalbumrc
BUT:
I later on tried, to just copy back my saved copy - and the entry was
still there. It also sticks out, because it is grayed, if no photos are
selected.
So it might be another case of tomatoes on my eyes. (I even knew where
to look and didn't see it) or there is another "trick" on top of
kphotoalbumrc !


> I have some images that should be stitched together but haven't done 
> that, nor am I sure what to use for it. (I have tried out
> AutopanoPro in the past. It seemed quite good to automatically stitch
> a panorama, but would need to be bought. Hugin was too much manual
> work a couple of years ago. I think devel version digikam has
> panorama features but haven't even checked whether this is true.)

I use AutopanoPro (currently 2.6.3)
I used hugin in the beginning, but always had the problem of how to get
the control points. I used autopano-SIFT, but this was painfully slow
(at least on my HW back then), required MONO and I had to fiddle after
an openSuSE-update to get it working at all.
So I had a look at AutopanoPro. You can get a free trialversion (but it
won't save the .pano-configuration files for the single pano and it
watermarks the output file.)
autopanoPro is amazingly fast. You can just hand it a whole directory of
images (last one ~~ 1000 images). It tries to find the panos by looking
at the timestamp. Then you can start the preview of the real stitching
process, which results in those "real" panos, where overlaps are found.
You can then go on to create the stitched images from these.
While older versions sometimes crashed on me, I didn't see a single
occurrence in 2.6.3
For me it is definitely worth the money. (I payed once (in 2009) for a
the 2.0 version. All up to the current 2.6.3 were included so far) The
company reacts to bug reports and fixes it - and also explains how to
not do stupid beginners mistakes ;-(

> What kind of workflow and tools you use for them? Would there be
> enough for writing a workflow chapter on KPA handbook?

There is only KPA and autopanoPro involved.
The workflow looks something like this:
1.
In KPA mark the fotos belonging to panos and tag them accordingly.
This is mainly to avoid throwing images away by accident, when I start
to sort out the garbage among the photos taken.
I even like to keep the images on the CF-card, until I'm through with
all the steps.
2.
Let autopanoPro find the panos and create the output.
3.
Sometimes I have cases, where a small part in the pano is missing. I
then try to "fake" it using gimp.
This works quite well, if there is enough "structure" in the part. (a
lane, even part of the interior of the dome in Cologne) but usually
fails awfully, if you have e.g. just blue sky. The sky doesn't have the
same blue twice and so far I wasn't able to fake this, without getting a
real gut visible "seam". (But I'm clearly no gimp-expert)
4.
Start KPA again and have it include the newly found panos.
5.
Sort the images by date, so the panos end up at their source images.
autopanoPro seems to write the EXIF info of the first image in the pano
to the pano output.
6.
Due to the naming the pano itself, it will end up as second image after
the first source image of the pano. Move it to correct this.
7.
Tag the pano and the source images (maybe together with all the other
"normal" images)
8.
Stack the pano and the source-images

Regards

Martin