Support individual images about stash

[WithoutPants]

Design considerations

• some users may have preview image files alongside their video files. These will want to be excluded from the image library
• exclusion patterns for images may differ to those for video files
• image files are smaller than video files - oshash will be unsuitable for hashing
• folders containing images may not necessarily be galleries
• clicking on an image should be for viewing primarily, metadata viewing/manipulation secondarily

Design decisions

• maintain a single library folder list, but allow selecting inclusion of video and images for each folder entry
  • alternative 1: separate video and image library fields
• add separate exclusion pattern field for images
• use MD5 for hashing of image files
• only zip files will automatically generate galleries
• images in zip files should be added in the same way as images outside of zip files, to allow metadata manipulation
• galleries can be created manually and images may be associated with one or more galleries
• images will have the following fields:
  • title (defaults to filename)
  • path (readonly)
  • performers
  • tags
  • studio
  • galleries
  • rating
  • o-counter
  • size (readonly)
  • width (readonly)
  • height (readonly)
• galleries will have the following additional fields:
  • title (defaults to zip path for generated galleries)
  • URL
  • performers
  • tags
  • studio
  • rating
• scan and clean tasks will include image processing
• gallery thumbnail generation will be extended to include individual images
• an images page will be added, allowing querying, filtering and sorting of individual images
  • should include grid and wall views
• there will not be an individual image page. Instead, clicking an image will show the image in a lightbox style overlay, with metadata viewing/manipulation available in a sidebar on larger screens, or below (with scrolling) on smaller devices
• the performer page will include an images sub-section, similar to the scenes sub-section
• images and galleries will be able to be deleted like scenes, with the option to remove generated files
• multi-edit functionality should be included for individual images

[QxxxGit]

Looking forward to this feature!

I suggest an o_counter field as well for the images, if possible. I could see this being requested often.

[Leopere]

If images found adjacent to a scene could also be added as related media or a side gallery that would be awesome.

[bnkai]

A couple of points from my use case.

• Galleries should have the ability to be created easily by images in folders. If i have images organized in folders i would like the ability to create a gallery from the specific images. This could be done either from the UI from a path selector or maybe using the plugin functionality, when that is merged. I wouldn't want to recreate manually all galleries that i already have sorted by directories.
• A cover image field should also be present. Either as a foreign key to an image or as a blob.

[bnkai]

#123 lists a lot of what we already mentioned in details

[yoshnopa]

Great that this got implemented! From my testing, some suggestions:
The image section should probably be able to filter out gallery-related images, so that only singular images are shown. These are only available via this page and should therefore be available in an easier way. (so basically some gallery IS NULL)
Another thing is the gallery in its new form. Although better for handling metadata, the way its implemented now the viewer is not really useful for at least two reasons:
When your showing the image as a wall, clicking on an image is leading to the images page. this is expected. However, it is probably useful to have a way implemented to go to the next image from there without going back to the gallery screen.
In grid, the viewer is triggered on click, however, the arrow keys are not working for navigation here. Instead, the next gallery or results page (in the image tab) is loaded. This seems to be a bug.
You can however click on the arrows to advance in the viewer, but only to the end of the loaded images. This means, if a gallery has more images than shown on one (result or gallery) page, it skips the second page (and the third and so on) in favor of starting from the beginning again. This also does not seem intended. Maybe this is something an infinite load implementation could fix?

[WithoutPants]

The image section should probably be able to filter out gallery-related images, so that only singular images are shown. These are only available via this page and should therefore be available in an easier way. (so basically some gallery IS NULL)

This can be done with "is missing -> galleries".

You got your terminology reversed regarding grid and wall, but these are reasonable assessments. I'm not super happy with the image viewing in general, so it's something that I will work on.

[WithoutPants]

I'm satisified that the implementation pretty much meets the requirements outlined here, so I'll close this. Further refinements can be opened as new issues.