Expand/Collapse all stacks in file window

[Carlo Didier]

Is there a simple way to expand and collapse all stacks visible in the file window?
I want to run a check script for all images and Ctrl-A won't select images hidden in stacks.

[Carlo Didier]

Ok, found it https://www.photools.com/community/index.php?topic=2684.msg17430#msg17430
But I have to Ctrl-A, Ctrl-E and then Ctrl-A again.
And Ctrl-E doesn't work reliably after Ctrl-A. Sometimes Ctrl-RightArrow works, but Ctrl-E not.

[Carlo Didier]

Forget it, it's Shift-E. Strangely enough, Ctrl-E sometimes works too ...

[Mario]

These commands, like most commands applicable in the file window, work on the current selection. This allows you to collapse one stack, several or even all with just a key press or a mouse command. I see that as a real advantage. Separate "collapse all stacks", "collapse all version stacks" etc. commands are neither needed nor helpful.

<Ctrl>+<E> is not linked to any command. Except for a command in the Map Panel in the Italian language version of IMatch.

[scw2wi]

Hi Carlo,

are you sure that expanding all Stacks is really needed to run your check script also over stacked images?

You could check, if it's easier to select only the topmost image,
and add all other images in stack to the selection via looping thru the IMStack Class.

I was thinking about this solution for my check script
but since I'm not using manuall stacks as of now
I have shifted my solution to a later time.
That's why I cannot post a proper code here.

Walter

[Carlo Didier]

@Walter: Yes. If not expanded, the "hidden" images in the stack are ignored an can not be selected. For the checks, I usually don't just select on stack, but a whole folder or folder hierarchy.

[scw2wi]

Hi Carlo,

I know that hidden images in Stack cannot be selected.
But you had written, that you are starting a script looping thru the selected files,
and that script can query for all hidden files related to every select file.

I did not really check that but I'm pretty sure that it should work.

With file.Stack you can check, if a file is part of a stack
(since it will be the selected one, this should be the top of stack),
and with stack.Files you can get all files in stack even if they were not selected.

Did you had a look at the IMStack sample script?

Walter

[Carlo Didier]

Hi Walter,
yes I know about the IMStack, but as this check script is only run unfrequently and manually, I didn't want to complicate the script too much. Automatically looking for stacked images easily doubles the number of code lines in that script and adds a lot of complexity ...
I may go there eventually, but right now I don't want to invest that time.

[Mario]

In many cases the auto stack command can be used to stack files, without the need for custom scripts.
It usually works very well for image sequences, by analyzing the timestamp or some other metadata that links the images.

[sinus]

In many cases the auto stack command can be used to stack files, without the need for custom scripts.
It usually works very well for image sequences, by analyzing the timestamp or some other metadata that links the images.

Yep, I can stress this. I use auto-stack a lot and it works great.
In my case I use a metadata-field to stack them. Means, if the Metadatafield is the same (what I do fill with a metadata-template), these files will be stacked.
Really great.

[Carlo Didier]

That's also a workable idea. But as my file names can provide all the necessary information for my small script, I don't need anything else. Once a new file is added to iMatch (auto-detected), the event script does it all automatically:
- detect that it's a composite image (pano or HDR or focus stack or ...)
- assign it to a corresponding category
- calculate the component images
- assign component images to corresponding categories (part_of_pano, part_of_HDR,...)
- create stack with composite on top (well, if I get around the zero-stack problem/bug ...)
No need for extra attributes or manual script runs.

[sinus]

That's also a workable idea. But as my file names can provide all the necessary information for my small script, I don't need anything else. Once a new file is added to iMatch (auto-detected), the event script does it all automatically:
- detect that it's a composite image (pano or HDR or focus stack or ...)
- assign it to a corresponding category
- calculate the component images
- assign component images to corresponding categories (part_of_pano, part_of_HDR,...)
- create stack with composite on top (well, if I get around the zero-stack problem/bug ...)
No need for extra attributes or manual script runs.

I see, fine! And you managed, that your scripts works now, super!

To be honest, I personally likes to have all stuff in the image itself or in the xmp-files.
I did this in 3.6 and do it now. The same reason is, that I prefere long filenames.

In my case I have a metadata-field, and all members of the stack, will get the same value in this field.
This gives me a good feeling for additional "securaty".

I can see exactly with help of this field, what images are in the same stack. I could even find all stack-members, if the stack would somehow, a user-error or whatever, with a simple searching for this field and would get all original members of a stack.

Of course, this is not necessary, as I said, it gives me simply a good feeling. 

[Carlo Didier]

Which proves the old saying "Alle Wege führen nach ROM" 

[sinus]