Image groups (NOT zip/cbz)

[thatfuckingbird]

Something like an extended version of the current "alternates" system.
To keep multipage galleries (like on pixiv), comics etc. together.

These should:

• optionally be treated as a single file in searches (so either all of the members of a group are found or none)
• optionally appear as a single file in pages (like collections now), sorting and other actions should keep groups together
• parsers should have a way to create groups (so I don't have to manually group every pixiv post with multiple images)
• the image viewer should have a way to quickly switch between members of a group, without otherwise messing up the image order (so besides the current next/previous buttons, there should be next in group/previous in group, and these should operate independently)
• maybe have group-level tags (like title)
• maybe have an order in the group (optionally, or just use page:num tags?)
• have it be possible for one file to appear multiple times in a group (typically the pure white and pure black pages often used in comics)

[Zweibach]

Like with parsers there should be a way to create a group like this from archive files, ex. zips and cbz.

* the image viewer should have a way to quickly switch between members of a group...

This should be easy-ish since the dupe filter already does something like this with the next file and next pair buttons.

* maybe have an order in the group (optionally, or just use page:num tags?)

I would vastly prefer the system to not rely on tags for this, that way it can't be messed up by tag pollution, but I don't know if it's really feasible to do it like I want it.

[Miliosian]

I actually brought up a similar request awhile back on Hydev's tumblr. The fix is a lot larger in scope than it may first appear. Tags are definitely not the answer, I've run into countless problems attempting to use them. Here's some snippets from Hydev with some insight.

I have been thinking about cbr/cbz support, I have been imagining a ‘perpendicular’ page-browsing, where the normal left/right browsing moves from one hydrus thumbnail to another, but a separate up/down would navigate internal pages inside the comic archive.
I generally prefer not to hardcode things like ‘page’ namespaces any more but instead build custom rules for this sort of thing. Some people will use ‘title’ to separate comics, but others may use artist-series-page, or use multiple ones at once.

I think the solution here is going to have to start with some sort of better file relationship system, so that when files do have an ordered relationship, hydrus has the ability to compact them together without having to go to awkward page: tags. The next iteration of the duplicates/alternates system is planned to have indexed (i.e. sorted) file grouping support.

Tumblr links: Post 1, Post 2, Related post from another anon.

[bbappserver]

I have specified this a few times in the discord, nice to haves would be:

• Ordered and unordered members
• Sub collections nesting( recursive definition, allows you to do series of series)
• Display a collection in the thumbnail view as a collapsable span with a different background color for the cell, and the first member as cover page thumbnail in collapsed view. (for collection nesting this background color should alternate back to whatever the default background color is (or maybe the same color but slightly darker, so it is clear there is a sub collection)
• PGR public group repository ( this sounds like a pain to implement )

Considerations:

• A PGR must exist to transmit tags which tag a group, but not its members.
• If a group and a group member are both tagged the same they will both be returned by a query and the user should be able to decide if only stray items should be shown separately.
• It is possible for multiple groups to share a member, this must be considered in the previous point.
• Sorting by file size has no meaning for collections, unless it considers aggregate size
• Several other sort keys such as dimension and duration are meaningless or semi meaningless to a collection and must either have a possible value of multiple or may produce a single number, or hydrus must have a setting for displaying collections sorting relative to other items (I imagine most people would want to see collections first or last, or separately all together, but not randomly strewn in the middle of other results.
• If groups can nest it is possible to create a cycle (nest infinitely). This probably wouldn't be possible from the GUI but may be as result of a parse or API access.

[bbappserver]

It would also be nice if parsers understood collections, so every single EH parse doesn't pollute the tagging.

[Zweibach]

I want the feature to support editing, adding to and removing from a group using parsers. Some danbooru series pools update with better versions as they become available or reorder pages and I sometimes want the group to reflect the state of the pool.

To avoid unwanted changes there should proably be some collection settings in the parser options, like "Mirror group [ ]" or whatever sounds good.

Adding some of my comments from Discord:

Zweibach: I'm hoping the feature will work with anything I want grouped somehow. With proper parser support so you can for example parse a danbooru pool and Hydrus will add to and remove from the group based on what the parser returns
Zweibach: Sure, but if you're gonna do series pools then you might as well do these collection pools too. I know of a few series pools where they swap out pages when a better version appear, which is primarily what I'd want the remove/add when parsing functionality for

[roachcord3]

When it comes to user interface, it may be possible to draw some inspiration from Grabber. The way it displays Pixiv posts that have multiple images is by putting the number of images in a red circle on the top right of the thumbnail in search results:

Upon clicking into one of those thumbnails, a new tab is opened that shows the images inside the post.