search

woelper / oculante

A fast and simple image viewer / editor for many operating systems
https://github.com/woelper/oculante
MIT License
889 stars 42 forks source link

Redesign proposal for recent images #363

Open Stoppedpuma opened 3 months ago

Stoppedpuma commented 3 months ago

Is your feature request related to a problem? Please describe. Recent images tab is very lacklustre to the point of where its almost useless, it also includes annoyances such as hovering over it requires you to move your mouse around it since it blocks the rest of the context menus. Example here:

1718221723

Describe the solution you'd like

A redesign to make the interface more intuitive.

Additional context I've created a redesign which makes this menu actually useful and not as in the way, it's pleasant to look at too! I can't implement this because I have a grand total of zero experience with rust but think it could be at least a good point in the right direction for improving areas of oculantes UI.

Below are some of the designs I've made which try to follow the current design of oculantes UI but with some of my own improvements. There's explanations written above the images to explain changes as well.

Redesign Proposal:

Shows 12 of the most recent images, there is a scrollbar to show more images if there are more than 12 (The maximum amount should be configurable in settings). The hovered image shows the name and date it was last accessed as well as applying a small amount of blur and dim to make the text more readable.

1718220832

Now what if there's less than 12 images, say only 8? Well the scrollbar should disappear to save horizontal room and show only 8 images to save vertical space as well:

1718221061

What if the user has limited horizontal space? The menu should change to be more vertical instead of horizontal, the scrollbar and amount of images shown vertically of course applies to the same rules above:

1718221249

Lastly, how it looks from a full perspective (the text of course needs to be scaled properly):

oculante_recent_redesign

woelper commented 3 months ago

VERY nice. I don't like the menu either right now, and it is the result of the egui menu just being default.

I like the visual representation in the mockups - what would be hard is to show thumbnails unless they have been previously cached or are in some trivial format. If some of the images are 10000x10000 HDR images, we would not like to load them dynamically I guess. Egui (the ui library I am using) does have loaders for the most common formats - so we could display thumbnails for jpg / png etc at least.

Stoppedpuma commented 3 months ago

Depending on performance overheads we can get file sizes under 25kb for most situations using jxl with a quality between 1-3 without any resizing, since these images are so small I highly doubt anyone is going to tell a difference in quality from the preview image. Combine with resizing and around 2kb seems reasonable in most cases.

Example of original png (2.16MB) vs q 1 jxl (19.7KB) both kept at the original 1440p size:

1718224257

unless they have been previously cached

The idea for how many show in the recents tab is to be configured using "Number of images to cache" in settings.

I'll remake these on figma so they are easily accessible for you to play around with, the example I made in inkscape is a bit of a mess...

Stoppedpuma commented 3 months ago

@woelper I've put this onto figma here, please feel free to suggest changes as necessary.

woelper commented 3 months ago

I am more concerned about the added complexity when using cached thumbnails:

For this reason I am leaning towards generating thumbnails on the fly for common formats (jpeg, png...) rather than having cached thumbnails.

Stoppedpuma commented 3 months ago
Regarding cached thumbnails > They need to be stored somewhere. This implies using a temporary directory on all platforms (Mac, Windows, Linux, *BSD... Linux and I think BSD use ~/.cache/thumbnails, Mac I believe is just ~/.thumbnails and windows I couldn't remember for the life of me. > This probably needs to be configurable, so entry in settings and UI Assuming you mean location, I don't think this would be necessary since I think everyone just expects cache to be in the same location that other applications use. Assuming you mean the number to keep, this should follow the already existing option of number of images to cache. > The cache can't just grow indefinitely, so cache management needs to be done Number to keep should be addressed by what I said above, should be fine to just delete any outside of that number? > The resizing needs to happen, and asynchronously. This is a bit complex since it should not disrupt loading speeds. Resizing a very large image is not free and can cause quite some CPU usage. This is a tricky one, I would say start caching _after_ the image has been loaded in order to prevent additional load times but this becomes an issue with switching fast between large images. > Either you recreate the thumbnail on every open (expensive) or you find out if the thumbnail needs to be updated in case the original image has changed. Otherwise you have to look at modification times and store it with the thumbnail etc. If dates don't work for some reason, storing a small checksum in the metadata of the images cache could be an option? If it doesn't match the image when it's loaded by directory or the file directly then recreate the cache? Not too sure about this one either.

For this reason I am leaning towards generating thumbnails on the fly for common formats (jpeg, png...) rather than having cached thumbnails.

Doesn't this lead to large performance issues in the case of lots of large images being rendered? Misread. Besides that my only concern is handling more "uncommon" formats such as AVIF and JPEG-XL, is the plan for these to just show the files name with no image?

woelper commented 3 months ago

Besides that my only concern is handling more "uncommon" formats such as AVIF and JPEG-XL, is the plan for these to just show the files name with no image?

That could indeed be one option. Also there would always be the option to extend the preview later with more "exotic" formats.

I need to think a bit more, but there may be a simpler way to store the thumbnail data directly in a data structure instead of individual files which could eliminate some of the above problems.