Add HD option which would send the original pictures to the slideshow

[oparoz]

From @oparoz on June 27, 2015 13:24

On mobile, most people would not want their 4000x4000 pictures to be used in the slideshow as is, but on desktop, some people would prefer to use those since they would be better fitted for the zoom feature.
I wouldn't want my slideshow to serve HD pics, as it would mean waiting longer for each picture, but I can understand the people who do.

So, the solution is to add an optional HD option to Gallery.

3 solutions:

• Global setting which the user can enable to get all his pictures in HD
• HD button in the slideshow for on demand originals
• Zooming in kicks in the download process of the HD picture and a huge, red cancel button flashes and bounces across the screen until the image is ready

Comments and sponsors welcome as it helps prioritise issues.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Copied from original issue: owncloud/gallery#193

[oparoz]

From @jospoortvliet on August 9, 2015 8:33

I have a thought on this, having just spend a while watching pics and occasionally downloading them to see the full one. I like the current behavior - these pics were 10MB or so and having to wait for that to be downloaded on each click on 'next' is not useful.

But sometimes, I wanted to zoom in on something, see some details and then - the limited resolution and jpeg artifacts become painfully visible. So I download the pic and use my image viewer - a workflow which feels awkward and unneeded.

What about lazily loading the high quality image when the user starts to zoom in and pan around? When the user zooms, he/she clearly wants to see more detail - how about giving it to them?

That way, loading pics is still fast and nice but you have quality when you want/need it, at the price of having to wait a few secs at most before the zoomed in image becomes clearer. But people will figure that out quick enough and it is nice and obvious... Andno need for options - it does the right thing when you need it. Also, it works just the same on mobile, I think.

But then don't limit it to 4000x4000 or so - no, start to download the full, original picture when the user starts to zoom in and replace what he/she is looking at when done. Then you have maximum clarity.

[oparoz]

Many thanks for the feedback :)

1. I don't think lazy loading will work, because users will be unaware of what is going on until they get a better preview and try to replicate the behaviour

2. Doing such things in the background could have adverse consequences for people on a mobile plan with limited data

3. The app would need to automatically abort and clean up every time the user clicks "next" or we could run into a protocol limit

This is taking into consideration the worst case scenario where a user is browsing pics taken with an 18+MP camera.

There is an elegant way of solving all these problems since Bigshot was designed to be able to zoom in like in any maps app, but this requires pre-processing all pictures, using a java applet... I don't think many people will use that feature, but it could be developed on request.

So I still think letting users be in control and letting them download the HD image, with a nice progress meter is a better solution.

[oparoz]

From @godfuture on August 14, 2015 9:39

Well, I guess reducing the picture quality is fine for previews, but for viewing a single picture (when clicking on it) or opening in slide show, it is a pity to get pictures presented in bad quality.

Therefore I suggest to add another setting in config.php that is meant to control the max pixel size when opening and showing in slide show. By this the user might decide how long to wait or what quality fits his needs.

[oparoz]

Well, they're not presented in bad quality if you use the default 2048x2048, but yes, it takes longer to generate all thumbnails of that size versus using 150x150. That value is too low btw, because this app needs 400x400 thumbnails to operate properly.

I've updated the OP to describe 2 different things we can do.

[oparoz]

From @jospoortvliet on August 22, 2015 10:35

@oparoz another option might be to show a progress bar when ppl zoom in, telling you're downloading the full quality image. With a cancel button... people will then understand quickly enough what, how and why and it avoids options and buttons ;-)

Not that a 'HD' button isn't an improvement over the current situation, but I'd be most delighted with it being automatic as much as possible.

I wonder what @jancborchardt thinks?

[oparoz]

@jospoortvliet - That could work since I don't expect people to zoom on every picture.

[oparoz]

From @jancborchardt on August 24, 2015 12:9

Yeah, I like @jospoortvliet’s suggestion too! :)

[oparoz]

From @jospoortvliet on August 25, 2015 7:53

OMG @jancborchardt likes something I said or did... Quick, somebody FedEx some proper clothes to the devil ;-)

[oparoz]

Hehe, his job is hard

[oparoz]

From @Spacefish on August 26, 2015 13:15

It would be nice if the gallery has some fixed sizes of images it uses. So for example for a 1024x768 screen a 1200x1200 version is used. Currently if you set your Browserwindow too 1000x500 an 500 height version of the image is generated.. if you set your window to 1000x499 a 499 Version is generated on so on.. However a 700px version could be used down to 200px or something like that.. Otherwise gallery need to regenerate all images for each user visiting the gallery, cause they have slightly different browser window sizes...

[oparoz]

From @jancborchardt on August 26, 2015 13:42

@oparoz @DeepDiver1975 does that make sense? ^

[oparoz]

We already round to the nearest hundred in order to not have too many previews, but the real solution is currently in core's backlog: owncloud/core#8196 has been abandonned by the core team

[oparoz]

From @beingalink on December 6, 2015 12:45

Looks like the real solution is off radar now. I'd suggest as an intermediate solution option #2 "HD button in the slideshow for on demand originals". An overlay button to load the original image would be a nice to have and it's currently not like the overlay interface would be overloaded with options.

My use case is images with extreme ar like snapshots from websites. The generated previews are useless in this case.

[oparoz]

My use case is images with extreme ar like snapshots from websites. The generated previews are useless in this case.

I see what you mean. If you can code the auto-download-on-zooming feature, it would probably also help others.

[oparoz]

From @beingalink on December 6, 2015 14:59

While the seamless zooming is fancy, it's not really a must-have feature to me (others might disagree of course). I think there's no need to re-invent the wheel if there's another library that is lean, without external dependencies and has a nice and clean zoom functionality integrated: photoswipe. A demo gallery is here. I know chances are bad that the official gallery app will change its basis because of my issue. But generally I like the look of the photoswipe gallery quite a lot better than how the gallery app in owncloud currently looks. It has a nice fullscreen feature. I guess that's not really helpful so I'll just cut it here. Thanks for your quick reaction though. 👍

[oparoz]

See my assessment about Photoswipe here: owncloud/gallery#158
And the features we currently support and want to support: https://github.com/owncloud/gallery/wiki/Slideshow

I'm not against replacing Bigshot, but it would probably be best to let people pick the slideshow they want to use.

[oparoz]

From @beingalink on December 6, 2015 15:43

Ah, I see. I didn't think that the required image dimensions would be a problem since owncloud touches the original files anyway to create previews. So I thought this is all available a priori. One thing I seem to have misunderstood is the fullscreen support which is in the list for the current gallery implementation: Where do I find this? Thanks for your support!

[oparoz]

Yes, ownCloud creates a 2048x2048 (configurable) max preview in order to process further thumbnail generation, but it doesn't store any information about the media file and it's stopping us from introducing some advanced features.
There is work in progress to change that, but no ETA.

Full screen-mode is available via the f or F11 keys (shortcuts), but the image will be at the same resolution since we use the screen dimension in our preview request.

[godfuture]

Hey guys,
I made my thoughts about this issue. I guess the real problem to solve is the screen size vs picture size. Keeping in mind that my impression of picture quality is completly different on desktop screen compared to mobile, a fixed resolution setting will never be satisfying. As there might be a huge difference in quality among all my pictures, the presented quality has to be decided for every object.

I do not know technical details, but the server should provide me the image in a size that fits to the screen I am currently using.

[oparoz]

I do not know technical details, but the server should provide me the image in a size that fits to the screen I am currently using.

That's exactly what it does. So all good as long as you don't zoom in. Once you do, quality degrades and that could be improved.

[lexo-mfleuti]

Should be customizable in config.php what max. resolution will be generated. Perfect solution would be: Initial image is rendered the way it's being done now. But as soon as the user zooms in, the system fetches and displays the full image. Should not be too hard to develop.

[jancborchardt]

Please note the slideshow component of the Gallery app will be replaced with the new Viewer app.