Image slideshow supported by a LRU-cache of reduced-size images

[tobiasKaminsky]

I want to make a "new" suggestion, how to handle images and the storage of them. This is a summarized version of my ideas in #588 and #429. I will update this "user story" according to our discussion in this thread.

IDEA: When the user opens a file he will get a reduced version of the image. This will be adapted to his screen (and 75% compress rate). Therefore we have no visual quality loss, but have to transfer a much smaller file (3,1MB --> 83,8Kb). This file will be cached and re-used. Caching system is already implemented. The cache should be adjustable in the settings (default to 100Mb). If the user wants to use the file (share, open with another app) he will get prompted:

• use reduced size (e.g. 1024x768 [shows real image dimension])
• Download & use original file Also there is a new option on long-press for images and in options in the slideshow: Download original file.

EXPLANATION: A cache is used to have a specific amount of storage our app will use for "background operations". If the user manually downloads a file he wants to have it and cannot complain about the big file. But in all other cases the user should not get the idea that owncloud is flooding his storage.

Prompting the user to use reduced/full size is also very useful as Whatsapp/Facebook... always shrink the images by themself, even if one uploads a full sized image. Also for sending an image via email it is useful to have this option.

Offering the option to download the full sized image is mandatory as it is the current behaviour and there might be (a few) user who want to do image processing or see a very small detail of the image and therefore have to zoom in.

I think this is a good compromise regarding storage size and data traffic.

Later on, as @davivel suggested, we can try to implement different user profiles.

Mention all user that have posted on #588 #429: @davivel @jancborchardt @Nowaker @NetAction @enoch85 @stefan-niedermann @LukeOwncloud @LukasReschke

[enoch85]

Good one @tobiasKaminsky!

[LukeOwlclaw]

Sounds great! Just a few questions to clarify things: Do you also plan a setting for clearing the cache? There is just one cache, right (not one per owncloud account or one for each folder)? What else will be stored there next to resized images (i.e., what other "background operations" could there be)?

[netAction]

Nice idea. Which resolutions will be used? 420p, 1080p and 4K?

The only service I know that offers multiple resolutions is YouTube. They switch resolution depending on bandwidth and Wifi status rather than screen size.

How would you determine the right resolution? Browsers have a virtual screen size in so called pixels. Something like this could be an indication.

For fast moving through directories it would be great if 420p would be always loaded first, even one or two images in advance. It is just 80kB and doesn't hurt. Loading 1080p afterwards should be good in most cases too.

[tobiasKaminsky]

@LukeOwncloud

Do you also plan a setting for clearing the cache?

I assume that the current cache is auto-cleaning. Which means that the oldest entries are automatically overwritten if the cache is full.

There is just one cache?

Right. The cache size should be adjustable. And with the "right" cache cleaning strategy there should not be need of multiple caches.

What else will be stored there next to resized images?

Thumbnails: small icons used for image grid #239

@netAction

Which resolutions will be used?

Android can determinate the resolution in width and height. These values will be passed to the server thumbnail API and generate a matching image that will be fullscreen on this specific device. This should be a good tradeoff between visual quality and file size.

As these reduced images are kept until the cache is full or the file has been changed I think it is no problem to wait a second longer. So I do not think we need to preload a 420p version and then load a bigger version. Remember: Currently we are waiting much longer to always get the original image with maybe 5Mb.

[jancborchardt]

Sounds positive! @davivel @MTRichards what do you think?

[MTRichards]

Sounds like a very useful update to the system for image handling and performance improcements. @davivel you know the inner workings, what do you think?

[joeplus]

I think this sounds like an very viable solution!

Will those resized images also be used for the grid view in #239 or will there be separate images to be generated by the server and downloaded to the app. Or will the thumbnails used in list view have a resolution which is sufficient enough to display them in a grid as well?

[netAction]

@tobiasKaminsky

Android can determinate the resolution in width and height.

What do you mean with “the resolution”? Does this, whatever it is, really matter?

[tobiasKaminsky]

@joeplus These are two different things: Image grid/file list shows thumbnails of files even if they are not stored on the device. They are fetched via thumbnail API. So the thumbnails are always there and up to date.

"Reduced images" are only downloaded when the user clicks on an image. They are used only for the slideshow and are replaced if the user downloads the full size image.

@netAction

What do you mean with “the resolution”?

It is the resolution of the screen device, e.g. 320x480 or full HD. It does matter as it is useless to download a full HD image to display it on an very old device. It would just consume too much traffic.

[joeplus]

Okay, thanks for clarifying!

[davivel]

The proposal seems really fine.

Probably the easiest way to develop this would be adding a new cache for the "reduced images", separate from the thumbnails cache.

@tobiasKaminsky said:

They are used only for the slideshow and are replaced if the user downloads the full size image.

I wouldn't replace. Maybe remove from the cache and use the downloaded file instead, but not replacing one for other in the cache. At least not with the kind of cache we are using now.

The thumbnails cache is built using a single file in the filesystem, The cache component takes care of inserting and retriving files into and from it. No problem to handle it programatically. But the files in the cache are not visible for other apps. They cannot be browsed with your regular file navigator, for instance.

That is one of the features of our current app. The downloaded files are not only there to access through the OC app, but with any other app that may access the public part of the file system. Putting thumbnails or "reduced images" in an * opaque * cache seems fine to me; but "hiding" the full files inside is not so cool.

Other possible issue:

f the user wants to use the file (share, open with another app) he will get prompted:

It's something to test, but if a user regularly shares or open images to edit them, the extra dialog may be bothering. Maybe an automatic policy would be better; for instance. share "reduced images" but open full images.

Very important: this could be started right now, but it's not something to finish in a couple of days. Probably will need a lot of testing, and a lot of fine tuning to keep the current details in the UI working consistently (state-badges updates).

[davivel]

Let me edit the title to something more specific.

[tobiasKaminsky]

Putting thumbnails or "reduced images" in an * opaque * cache seems fine to me; but "hiding" the full files inside is not so cool.

I think you have misunderstood me. I never wanted to put full files inside a cache. I meant that the small thumbnails in the cache are replaced by the reduced images when the user opens the file in the slideshow. Two different caches will be more work if an image is changed remotely.

Maybe an automatic policy would be better; for instance. share "reduced images" but open full images.

This depends on the purpose of the user. I could find arguments for pro and contro of this idea and still do not know which way I would prefer. Maybe we should just implement it with the selection and see how user really use it?

[tobiasKaminsky]

@davivel Is your question solved by my last comment? If so and everybodys like the idea, I will start to implement it.

[tobiasKaminsky]

An update: This is working for me right now. Problem remaining is to share a cached file and https://github.com/owncloud/core/issues/16250

But I am getting closer to it :)

[tobiasKaminsky]

I cannot create a PR since https://github.com/owncloud/core/issues/16250 is still not solved. @davivel can you vote for this to get this implemented soon?

[davivel]

I'm afraid that won't be so easy. Is there a PR for this? Is the code in a branch in this repo or in your fork?

[tobiasKaminsky]

@davivel A PR is done in #1044. The branch is in this repo.

Looking forward to have this feature included :)