[RFC] Replace compressed galleries with plain image folders

[ueaslsef]

ZIP files and other archive formats are great for simplicity, but have poor performance.
I would suggest we just allow another folder for images and then have subfolders for the galleries. Access and caching should be simpler this way.

[Leopere]

I think zip is a good value add but letting the app scan the directories and potentially pairing stock images from the directory the release is in or detecting a gallery and doing the correct thing with it would be nice.

[StashAppDev]

I actually make heavy use of zip files, so I'd rather not completely replace it. I'm all for having image folders as an additional option though.

[Leopere]

@StashAppDev is there potentially a way to support more compressed file formats?

[joyov]

I do have performance issues with galleries too:

But I suspected that reading the zip archive might not be the issue here. I think generating the thumbnail is what's causing this.

To test this I've installed this Chrome extension and created a redirect that removes the ?thumb=1 from all image includes.

^(https:\/\/stash\.example\.com:9999\/gallery\/[^\/]+\/[^\?]+)\?thumb=true$

And voila - now all images load successfully.

It's still not fast since now it's loading several dozen multi-megabyte images at once when opening a gallery, but now bandwidth seems to be the sole problem.

After adding the redirect, all preview images in the galleries overview were huge, so I had to add a bit of custom css as well:

img[src*="/gallery/"][src$="?thumb=true"] {
    max-width: 200px;
}

My proposal would be to pre-generate thumbnails like video thumbnails are pre-generated too. This should resolve performance issues.

I'd still like to have the option to use subfolders instead of zip archives for galleries. This probably won't fix the performance problem but I prefer it since I don't see any advantage when using zip archives. (And in fact it does have some disadvantages, for example many file explorers don't show thumbnails for files in archives.)

[WithoutPants]

I think this is largely met by #813 and can be closed.