darktable-org
Grouped image count should be reported as one
Is your feature request related to a problem? Please describe.
I am shooting in Raw+JPG mode. Even though the images are grouped automatically during import (which is nice), they are counted as two separate images, for example:
- In the collections overview (e.g. counting 872 images, even though it's only 436).
- In the quick filter on the top
- In every info box, e.g. "Applying rate 3 to 2 images" etc.
This is (imho) confusing because every operation, with the exception of expanding the group, treats these images as effectively one image:
- Darkroom mode only opens the group leader
- The thumbnails itself are only shown once
- The thumbnails in the bottom of the darkroom only display one image
- Exporting is only done from the group leader
Describe the solution you'd like
If the images have the same base filename, and one of them is a raw file and the other one is not a raw file (e.g. jpg, png, tiff etc), they should be counted as one image, instead of as two.
Alternatives
Don't enable this it as default, but have it in the configuration (even though that would make the configuration more cluttered)
Additional context
This would really be a great improvement.
Especially if I have some photos with RAW+JPG as well as some jpg-only in one folder, I have no idea how many photos there are (because I can't just divide by 2 here...)
So I think I identified the source for this (https://github.com/darktable-org/darktable/blob/master/src/common/collection.c#L380), but it somehow looks to me as if this was a deliberate design decision. For example, the comment is
/** get the count of query including the images hidden in groups */
uint32_t dt_collection_get_count_no_group(const dt_collection_t *collection);
So therefore I would like to open some discussion about it 😊
I guess it makes sense to report the ungrouped count when the pictures have been manually grouped, but I think for the raw+jpg-workflow it definitely does not make sense.
I guess it makes sense to report the ungrouped count when the pictures have been manually grouped, but I think for the raw+jpg-workflow it definitely does not make sense.
absolutely
In the collections overview (e.g. counting 872 images, even though it's only 436).
There are 872 physical images in 436 groups.
If the images have the same base filename, and one of them is a raw file and the other one is not a raw file (e.g. jpg, png, tiff etc), they should be counted as one image, instead of as two.
If I import a raw, then edit it in GIMP the result is a jpg|tiff|png|etc that is grouped with the raw. However, it is not a duplicate, it's the edited raw plus other edits in GIMP.
I'm trying to understand what misreporting the number of images does for your workflow. Why is the number of images significant and how are your using it?
I'm trying to understand how it fits into your workflow and what it does for you to see if there are alternatives.
Reporting incorrect information and representing it as correct is never a good idea. If you want the 872 imported images to show up as 436, then we need to build a collection that consists of the 436 images that you want to see (which I can't figure out from the above). Perhaps if you explain the (your) RAW+JPEG workflow, then it will make sense to me and I can figure out a solution.
Another thought. If you make a duplicate, how should that be handled?
First usecase: I import all my images I took on a trip (from my dslr, smartphone and drone) into darktable, so the first thing I want to know is: how many images did i take.
And I'm not interested in how many files there are, but how often did I press the shutter, so how many images are visible at the moment.
Second usecase: I'm culling, and want to know, how many 3-star images do I have at the moment (I don't want to show 100 images of one trip on my website).
The only moment I finally see, how many images are currently shown is when pressing export, because then it only exports the group-leader, and therefor only counts grouped-images as 1.
Maybe I have a very unique workflow, but even if I have a trip with dslr only, after some time I don't know if I took raw+jpg or jpg only or raw-only, so the number I see in darktable is not reliable, because I always have to think: what does it mean in this situation.
And even if I manually group different images, or group edited versions, or create duplicates: I want to know at any moment: how many images do I currently see, and how many images will be exported if I now click on export.
And if I want to know how many images there are in total, I can click on "expand grouped images" and then see all images and therefor see the number of all images.
This would also be consistent to exporting, because when expanded all files get exported, not only the group-leader.
This has already been discussed iirc. One reason of the current behavior is that we have to be really explicit for the user about the number of image really selected as this is the number of images we will act on for the vast majority of actions (ratings, deleting, etc).
Another difficulty is that grouping can be used for very different reasons : RAW+JPG, bracketing series, pano series, duplicates, etc, etc And each cases are different from from a workflow perspective...
Maybe one solution could be to implement a new filter "grouping state" to select only "group leaders, orphan images, all, etc, etc) So we avoid "hidden" images... But that will have the drawback that the "non-leader" images of a group won't be rated, tagged, etc with the group leader anymore (as they won't be part of the current collection anymore)
Another solution would be to resurrect https://github.com/darktable-org/darktable/issues/12611
There are 872 physical images in 436 groups.
Hmmm my question would be, whether the user thinks about "physical images" in this case. Or whether “groups” shouldn't better be called “images” in this case? I just find this extremely confusing because the lighttable itself does not, except if expanded, show 872 images. It shows 436.
If I import a raw, then edit it in GIMP the result is a jpg|tiff|png|etc that is grouped with the raw. However, it is not a duplicate, it's the edited raw plus other edits in GIMP.
That raises actually a good other point which I'm currently struggling a bit with. How do/should I organize the edited/exported picture? (this will be a bit offtopic, but just as background here)
So I have a raw file if I shoot with a “proper” camera, but don't necessarily have it when I shoot with a smartphone. Especially for vacation style photos I usually have a lot of pictures which are snapshots. I mostly do not even want to edit most of them. I only edit the ones which I want to print, put in a photobook, maybe upload somewhere etc. So only the ones which are "good". Therefore the lighttable organization is for me the primary use case of Darktable in this situation: I want to throw away really bad photos, otherwise just put some stars on them and mostly use tagging and setting some other metadata, gps position etc.
In this scenario, I am perfectly fine with using the in-camera jpgs because they are (at least for beginners in editing) much better than what I can even edit. But I anticipate that in the future I'll be better, then I want to have the option to also have the raw, for when I need it.
So I just put all my images of this vacation, jpgs + raws in one folder, impor them into Darktable, categorize and tag them etc. And then I select to edit a few of them. Where would I even put them? :D Currently I create a subfolder in this directory ("edited pictures") and export the edited raw file into there. But now I have basically 99% of the in-camera jpgs in the main folder and some edited ones in the other folder, even though in the end, they would have just been edit2 of the original image. So I then even wonder if that edit shouldn't be loaded into Darktable again?
For me this workflow is a bit like:
- I have one "photo", where there is a file with the most information available. This is usually a raw file, but also could be a jpg.
- And then based of this file, I can create multiple edits, which does not even have to be done with Darktable. The camera creates one edit for me, but I can also edit it in Gimp, Affinity Photo whereever. Or I just edit them with Darktable and export it.
- On the other hand, I might even be able to use one of the edited version to do edits. For example, if I only want to do cropping or perspective correction, I don't need to use the raw file and could just use the jpg file.
One reason of the current behavior is that we have to be really explicit for the user about the number of image really selected as this is the number of images we will act on for the vast majority of actions (ratings, deleting, etc).
Hmmmm but then it seems to me a bit that there is "just" a problem that the processing count is used as a display count.
Another difficulty is that grouping can be used for very different reasons : RAW+JPG, bracketing series, pano series, duplicates, etc, etc And each cases are different from from a workflow perspective...
Hmmm I understand. I guess it depends a bit also on priority: Which use case there is the "most used" and where is a "correct" display count best used.
It seems from all the discussion that what is really desired is a collection statistics display
- physical images
- paired images (RAW+JPEG or RAW+HEIC)
- Rejected
- Unrated
- 1 start
- 2 star
- 3 star
- 4 star
- 5 star
- bracket exposure groups - we can figure this out, but we have to read the images
- edited
- untouched
- duplicates
We could implement group types using tags which could then be leveraged for collection statistics
for me a statistic is fine, but does not solve my issue.
Maybe we have to differentiate between two main usages of the grouping: a) automatically grouped (raw+jpg / duplicates) b) manually grouped (pano series, ...)
For type a) the current image count does not make sense at all in my opinion.
I see the automatically grouped images as 1 image.
When editing (doubleclick) or exporting it's quite clear, that only the group-leader is relevant.
But even if I am rating / deleting / ..., it would be better to only count the visible images:
- I have collapsed raw+jpg grouping
- I manually select 2 different photos using ctrl-click
- the header says '4 images selected'
- I click 'remove' and dt says: 'do you really want to remove 4 images from darktable'
Both infos are not intuitive for me, because I want to be sure, that there are 2 images selected / deleted, if I want to select and delete 2 images (including duplicates / raws).
Another usecase: I only select 1 image.
If there are no groups involved, darktable tells me: 1 image (# 5) selected So it shows the number (# 5), which is a great feature.
If there are collapsed groups, there are always 2 images selected, so there is no # 5 shown.
small addition: the popup when deleting images could of course explain and add the "total" number of involved files:
for example: do you really want to remove 2 images from darktable? Attention: this will also delete the 2 corresponding images collapsed in groups
Maybe we have to differentiate between two main usages of the grouping: a) automatically grouped (raw+jpg / duplicates) b) manually grouped (pano series, ...)
For type a) the current image count does not make sense at all in my opinion.
I see the automatically grouped images as 1 image.
Just to show you another valid workflow, I would say that raw+jpg, pano series, etc could be considered as one image as the final goal is to produce one unique image, but duplicate is the opposite...
One solution (the most versatile and "easy" to implement imo) can be to change the selection text to something like : "6 images selected of 34 (3/17 shown)" or something like that.
We have to pay attention of 2 things :
- the perf cost (I expect it very low)
- the size of the text for small screen
Just to show you another valid workflow, I would say that raw+jpg, pano series, etc could be considered as one image as the final goal is to produce one unique image, but duplicate is the opposite...
hm, so maybe it's only the raw+jpg usecase which should be handled differently?
We have to pay attention of 2 things : ... * the size of the text for small screen
the length of the selection text is definetely an issue: On my 1920x1080px screen (with left- and right-panel), the text is already too long if the number of images has 4-digits: "1 image (# 861...lected of 1730" So I don't think it would work to add even more text
We could implement group types using tags which could then be leveraged for collection statistics
Hmm but then you probably have to open some statistics page which is probably not so straightforward, the main display in the UI is still misleading (imho) and I think then it's just again some additional feature, making the UI more unintuitive.
I think a general statistics overview/page is fine. I see often many photographers in the Internet doing stuff like "Which focal length did I use this year the most" or stuff like this. But imho that's a completely different usecase.
"6 images selected of 34 (3/17 shown)" or something like that.
I would say that's confusing. Do the users really want to see how many physical images are selected, even though the only place where this is really important is when deleting them? Just my personal opinion (Always the best argument :D) is that the users think of raw+jpg primarily always as one image. One further argument to my claim: The digital cameras also always just treat this as one image (at least on Canon and Sony, not sure about the others). If I have raw+jpg enabled in the camera, shoot one picture, the picture counter is 1 (and not 2). The images are also counted as e.g. DSC0001.{JPG,ARW} etc. (I don't know about Nikon etc., might be different). As most users probably have one of these cameras, why not make it consistent with them?
This seems to be one of those items (the selected images line) that attempts to satisfy everyone's workflow but probably satisfies no ones.
And, we are not hearing from the people that like the way it works or don't care as long as it doesn't change (because they are used to it).
the main display in the UI is still misleading (imho)
And if we change it so it works for you, then it doesn't work for me. And if we change it so that it works for someone else, then it doesn't work for either of us. There's too many opinions of what information should be displayed and how it should be displayed to fit in a 1/2 line (or less) of text.
What we need is some way to display a user configurable set of information about a collection and/or selection, such as:
- how many files
- how many images, if different from files :)
- how many groups
- how many images will be acted on (if you're hovering over a non selected image that counts as 1) for export, delete, rating, tagging, etc, etc, etc
- how many images in selected group
- etc, etc, etc
And then we need someone to code it, which will probably be a way bigger problem than trying to agree on what to display and how to display it.
And, we are not hearing from the people that like the way it works or don't care as long as it doesn't change (because they are used to it).
Well, that's always a possiblity. But then how to approach changes to the UI? In the end, every change request can be declined with “There's a silent minority which like it how it is currently”.
It can also be that there are many people who are not liking it, but just treat it in general as not important enough to complain, because, of course, after all it's just a display of number of counts. Other issues are more important.
But a software is of course also a collection of individual goodies, bugs etc, which make a software nice to work with - or not. There is such a thing as quality of life in a product.
And especially for this topic: My impression (I guess that's mostly the case for open source) is that somebody implemented it because it worked for the original developer (or there was some kind of deeper discussion about it, or it was already changed etc - that's exactly what I'm asking :D), and then the feature is there, and now there has to be some argument to change it - which is easily declinable because it's easy to decline every change request. But it could have also been built the other way round from the beginnig.
For me therefore, I wonder if there is a current workflow/procedure for this kind of change requests. I don't mind of course to be declined, but then, is there some way general workflow? :D I've started a (not anymore so) small spreadsheet with a list of (imho) worthwile improvements/annoying things in the Darktable UI, which are of course highly subjective.
And then we need someone to code it, which will probably be a way bigger problem than trying to agree on what to display and how to display it.
And that's is why I argue to "just" change the display. Imho it is currently confusing for many users, especially new users. And instead of building a super perfect solution which can be configured in every deail to make everyone happy (but will probably not be, because user's at first like a good default implementation), why not make it good for most users? Changing the display might be easier - or not, but cannot know until somebody tries (and yes, i'm volunteering, that's why I was already digging through the source code).
So then, how to solve this? Doing some kind of user survey on this specific feature is unrealistic. People here participating in Github is not representative. Maybe pixls.us? But then you of couse also find mostly the user's who have "endured" working with Darktable, but all the users who tried it and didn't like it, will not be reached there.
So then imho remaining is:
- Check what the competitors are doing and just copy shamelessly from them. Because the users are already used to that (Note: I did not check what the competitors are doing). If 80% of the competitors do it one way, maybe it's the better way, or at least it's what the users are probably used to.
- Get inspiration from similar projects (that's why I'm mentioning what the cameras are doing. Almost everyone who uses Darktable has a digital camera, they have mostly settled on a specific raw+jpg workflow - why do it different than what the device which everybody uses does?
- Just change and see if anybody complain, and in worst case change back.
I'm especially not only asking about this specific topic, but also about the 49 which i've already collected :D
Adobe Lightroom by default treats imported raw+jpgs as one file. It only displays one thumbnail but shows cr3+jpg as filetype. When deleting one photo, both raw and jpg file get deleted from the harddisk.
There is a preference: "treat jpeg files next to raw files as separate photos". This only affects new imports after changing the preference, and now shows two thumbnails per photo, so you can delete / handle only raw or only jpg.
My Canon Camera also counts raw+jpg files as one photo. When deleting one photo the default option is to delete raw+jpg, but there are alternative options to only delete the raw or only delete the jpg.
So for this specific topic it's very clear for me, that it is the expected behavior for the majority to treat raw+jpg as 1 image.
When deleting x images, I would explain in the popup that not only the selected x raw-files but also the corresponding y jpg-files will be deleted.
And to be consistent in my opinion this should also apply to manually created groups, because there is an easy way to group/ungroup, and a hint of affected number of files when deleting.
which is easily declinable because it's easy to decline every change request.
That's REALLY unfair and insulting! If that was the truth, then we wouldn't be having this discussion because I would have just ignored the change request in the first place.
the expected behavior for the majority
In this conversation.
Now I have a question.
If implementing the desired change to facilitate your workflow breaks my workflow then which should have priority?
This is the roadblock you're going to face every time you want to change the default behavior of darktable unless you can demonstrate a huge benefit for implementing it. Or, if you can figure out a way to implement it that can keep everyone happy.
The other issue with this change request is that there are multiple people who want multiple things, so if we change it then only a few people will be happy (depending on what it gets changed to).
What I've been trying to figure out during this is a way to make everyone happy. My proposal:
- Make the string a pattern like the thumbnail patterns that exist in lighttable preferences.
- We'd have to add some variables to get the specific numbers. Suggested variables are welcome.
- The default could be the current string, just as a pattern.
Here to support the idea, RAW/JPEG should be counted as one image.
But ultimately it still depends on whether any developers are willing to write the codes, don't have enough time, not a priority, or don't like the idea personally. Change requests could be delayed or declined in every reason. As I know, there is no standard procedure for change requests. Bugs report will be fixed quickly. As for feature requests, a [WIP] PR will catch more attention.
the expected behavior for the majority
In this conversation.
I did not mean the majoritiy "in this conversation" only, as a major camera-brand (Canon) and the leading raw-developer (lightroom) use this approach.
But I understand, that there is a valid and learned usecase of showing the number of files on which most actions get applied (rating, tagging, deleting, ...).
So as I don't think there can be one solution everybody is happy with, in my opinion there are two possibilities:
1. customizable string patterns (as suggested by wpferguson) 2. true/false preference how to count collapsed images in general (like adobe lightroom does)
Personally I love 1), because I could easily get my preferred workflow, and I can even shorten the wording for my small screen.
But in order to prevent confusion, I would prefer to change the wording "images" to "files" in other messages. for example: applying rating x to 4 files
And as deleting is a very critical usecase, it would be great to extend this message: do you really want to remove 4 files from darktable (thereof 2 currently collapsed)?
Here are suggestions for variables:
index.selected.image nr.files.selected nr.files.total
nr.thumbnails.selected nr.thumbnails.total
nr.collapsed.selected nr.collapsed.total
The default (=current) patterns would be: 1 image (# 15) selected of 62 1 image (#(index.selected.image)) selected of (nr.files.total)
4 images selected of 62 (nr.files.selected) images selected of (nr.files.total)
My alternative usecase would be:
# 15 selected #(index.selected.image) selected
2 / 42 selected (nr.thumbnails.selected) / (nr.thumbnails.total) selected
Other possible usages would be:
2/4 images/files selected of 42/62 (nr.thumbnails.selected)/(nr.files.selected) images/files selected of (nr.thumbnails.total)/(nr.files.total)
2 visible + 2 collapsed imgages selected (nr.thumbnails.selected) visible + (nr.collapsed.selected) collapsed images selected
@quovadit how did you get the separator?
EDIT: Never mind, figured it out. Really like it
Great to hear you figured it out! For anyone else interested, you can get the separator with 3 hyphens ---
Back on topic :grin:
The code handles 2 cases:
- no image or multiple images selected
- 1 image selected
Proposed variables:
- COLLECTION - top level
- IMAGE - category - any image
- IMAGES - category - any images
- IMAGE_PAIRS - category - a raw image and a non-raw image imported at the "same" time, same being within a second or two of each other
- UNPAIRED_IMAGES - category - images that don't meet the definition of IMAGE_PAIRS
- COUNT - number of category items
- SELECTED - specific category item
Proposed syntax:
- COLLECTION.IMAGE.SELECTED - the selected image or null
- COLLECTION.IMAGES.COUNT - the number of images in the collection
- COLLECTION.IMAGES.SELECTED - the number of images selected. If 1, COLLECTION.IMAGE.SELECTED is populated
- COLLECTION.IMAGE_PAIRS.COUNT - the number of image pairs (as defined above) in the collection
- COLLECTION.IMAGE_PAIRS.SELECTED - the number of image pairs selected. If 1 image_pair is selected, COLLECTION.IMAGE.SELECTED is populated the number of the first|visible image in the pair
- COLLECTION.UNPAIRED_IMAGES.COUNT = COLLECTION.IMAGES.COUNT - (COLLECTION.IMAGE_PAIRS.COUNT * 2)
Using the above the default patterns would be:
- $(COLLECTION.IMAGES.SELECTED) images selected of $(COLLECTION.IMAGES.COUNT)
- $(COLLECTION.IMAGES.SELECTED) image (#$(COLLECTION.IMAGE.SELECTED)) selected of $(COLLECTION.IMAGES.COUNT)
What would be an example to use the variables image_pairs and unpaired_images?
I often have grouped (raw+jpg) and ungrouped (jpg-only) files in one folder.
For example I have one photo taken with my canon (raw+jpg) and two photos from my smartphone (jpg-only):
- photo_01.cr3
- photo_01.jpg
- photo_02.jpg
- photo_03.jpg
If collapsed I only see three thumbnails:
- photo_01.cr3
- photo_02.jpg
- photo_03.jpg
If I select the first two thumbnails I would show: 2 / 3 selected (nr.thumbnails.selected) / (nr.thumbnails.total) selected
If expanded I see all 4 thumbnails, and I would show: 3 / 4 selected
So 'thumbnails' is the number used when exporting the selected images. (which is the same as the number of thumbnails currently visible)
How could this example be done with your variables?
an example to use the variables image_pairs
If your workflow is raw+[jpeg|hef] then it would be
- $(COLLECTION.IMAGE_PAIRS.SELECTED) images selected of $(COLLECTION.IMAGE_PAIRS.COUNT)
- $(COLLECTION.IMAGES_PAIR.SELECTED) image (#$(COLLECTION.IMAGE.SELECTED)) selected of $(COLLECTION.IMAGE_PAIRS.COUNT)
I'll have to think about a hybrid environment. It may involve adding another variable. I want to avoid adding math operations to the variable substitution
thanks for the examples, but this only affects groups AND is the same when collapsed or expanded.
If there are only raw/jpg-couples in one folder, it's easy even now to just divide by 2 to know how many different images there are currently.
But in most shootings I also have some smartphone and/or drone-photos (jpg-only).
And it's not only the "hybrid environment", I also have some folders with smartphone-only photos, or older folders with raw-only...
So in order to improve the current situation, I think it's essential to have a variable showing the number of thumbnails currently visible in the grid.
As said before: as soon as I click on export, darktable immediately knows how many different images are selected and therefor will be exported now.
That's the number I would love to have as a variable.
That's REALLY unfair and insulting! If that was the truth, then we wouldn't be having this discussion because I would have just ignored the change request in the first place.
Sorry, it came out wrong. I apologize. You are right, this was not good manners. Of course I did not want to insult you.
So as I don't think there can be one solution everybody is happy with, in my opinion there are two possibilities:
1. customizable string patterns (as suggested by wpferguson) 2. true/false preference how to count collapsed images in general (like adobe lightroom does)
Personally I love 1), because I could easily get my preferred workflow, and I can even shorten the wording for my small screen.
Okay, number 1 is probably okay, but how does this pick up all the non-software-dev audience?
Of course there are often string patterns used (I guess export filename mostly?) but you would still have the problem that you
- Have to find a place where to set this (confusing for beginner/new users)
- Even knowing that this can be changed
- And then you are struggling with finding a good pattern
So maybe some kind of dropdown with a list of common patterns and their effect would be nice, so that most users just need to select their favourite one.
Also keep in mind that variable names like COLLECTION.UNPAIRED_IMAGES.COUNT are in the beginning quite hard to read. I assume many non-SW-Devs are wondering there "Why does the software have to scream at me?". And for non-english languages it might be even worse to work with it. Maybe the words are not commonly understood, it's just harder to read if you are from a non-latin language etc.
And I still think a good default option (which imho is not the one which there currently is, otherwise I wouldn't have created this issue :D) would be good, which of course is the one which is also handled by the camera brands (Canon, Sony) or the competitors (Lightroom). Because that is what new users are knowing from their camera, where they just took the photos which they want to organize/edit.
"Why does the software have to scream at me?"
Because they wont RTFM. :rofl: On a serious note, the variables are all in caps so they stand out in the pattern and are easy to find.
Have to find a place where to set this (confusing for beginner/new users)
Preferences, just like all the other patterns
Even knowing that this can be changed
RTFM?
And then you are struggling with finding a good pattern
You make it what you want it to be, or just use the default and don't mess with it.
And I still think a good default option
You still haven't answered my question: If your workflow breaks my workflow, which one should prevail?
My answer is implement both and let the user choose the default. However the out of the box default should be the existing workflow because the user base is using it.
I built a test environment last night and loaded some RAW/nonRAW pairs to better understand what needed to be done. After playing with it for awhile I realized the following:
- This change would potentially change the way grouping works, possibly requiring group "types" to implement.
- This change definitely requires changes to images to act on, specifically selecting a collapsed "pair" and having it count as one versus selecting a different group and having it count as the number of members. Images to act on is currently a work in progress, #16850. Until that is complete, this can't move forward. I'll add this issue that issue so that it can be figured into the solution.
I agree that it's better to have the flexibility to define it the way you want it to be, compared to an easy-to-use toggle like lightroom.
In the manual there could be 2-3 examples of patterns you can just copy&paste.
Then I even don't have a problem if the current way is the default. Current users are not confused, and everybody who wants to change it can do it using the instruction in the manual.
But the main issue for me is how the implementation will work.
I don't think that this should change the way how grouping works, and it definitely should not have anything to do with the 'images to act on' topic!
I would not change the functionality which images will be acted on! If I select a collapsed group then of course all items should be rated / tagged / deleted.
I would just change the wording from 'images' to 'files' when applying rating to 4 files (although only 2 thumbnails are visible).
And I would add an explanation in the delete-dialog, to explain that also the not-visible collapsed files will be deleted.
And I would not differentiate between raw/jpg couples and other groups.
It's just an additional variable number-of-currently-visible-thumbnails, and this is relevant for all usecases (jpg-only, raw-only, raw+jpg-couples, manual-groupings, hybrid.