Allow loading larger preview or full-sized images in image viewer

[profi248]

I have major problems with performance of image folders (external storage, on spinny drive). Loading thumbnails takes a lot of time or even, when there's a lot of pictures (>1000) in the folder, it completely overwhelms the CPU and RAM, rendering previews almost unusable. To improve this situation, I turned down preview size significantly and loading is a lot faster and actually usable now. The problem is that when you open that image, just the tiny thumbnail loads (and takes a long time to load as well, even though it's already generated).

I don't see a reason not to add an option to enable more tiers of thumbnails, with the larger one only being generated on demand, when the photo is opened. Or alternatively, a simple solution, just serving full-sized picture, as bandwidth is (at least for me), not a big concern on a computer.

Ideally, I would imagine small thumbnails generating in the background automatically, with larger previews generating as user opens the photos, which would be ideal in terms of speed as the server won't be overwhelmed by so many thumbnail requests, and disk space trade-off is small.

I know about https://github.com/rullzer/previewgenerator, but it's not a great solution as those large previews take up a ton of disk space, for nothing. And it didn't work for me, but that's a different issue. File loading is slow in general, at least in external storages, which is the only storage that fits my needs.

I am aware that this has been discussed already (#1968), but this issue is very old and without much interest.

[edenhaus]

A long time ago this feature was already discussed (nextcloud/gallery#38).
In my opinion option 2 (button on the preview to get the full sized image) would be perfectly.
The most of the time the preview image is enough and the few times, where you want for example to zoom in, you can click and wait for the full sized image.

[SimplyCorbett]

cc @skjnldsv

Is the ability to direct download a image when going through the slideshow viewer or the photos app an overlooked feature or is it not possible to implement in nextcloud for some reason?

Have to agree with @darmbrust that browsing thousands of images over the slideshow or photos app and then having to hunt them down in the file listing or share them for a direct download link is painful.

Why isn't there a direct download option?

[skjnldsv]

Is the ability to direct download a image when going through the slideshow viewer or the photos app an overlooked feature or is it not possible to implement in nextcloud for some reason?

Because we need a proper fileActions API so we can implement the file actions into viewer. Hardcoding actions is something I don't want to do.

a simple solution, just serving full-sized picture

I don't understand why this isn't implemented by default.

Because downloading a 22MB jpeg makes no sense when you want to preview a picture.

[SimplyCorbett]

Because we need a proper fileActions API so we can implement the file actions into viewer. Hardcoding actions is something I don't want to do.

Thanks! So it is a technical issue. It's not a big deal then. I just wish it was easier to direct download images on those applications.

Well, you're not wrong about the 22MB JPEG. But I think it's a waste to generate preview images on large albums if the nextcloud instance is on a LAN setup with no bandwidth limitation. But that's personal preference. Thumbnails would still have to be generated regardless.

Appreciate the response! 👍

[jospoortvliet]

Quite honestly, I think that the entire point of nextcloud - self hosting content - should be more along the lines of making the assumption that you ARE on a close, fast network, and bandwidth is far cheaper than bending over backwards to try to generate the smallest, least objectionable copy of the photo.

You already mention mobile... And I share my photos with family, so the slow upload I have as private user is a huge bottleneck. Google and such have way stronger bandwidth than most private users - and thus I'd rather argue the absolute opposite of you: Nextcloud should be MORE frugal with bandwidth as the upload speeds of most home networks is tiny compared to data center solutions.

[jospoortvliet]

Well, mr @darmbrust if you want something else than what we are building, you can modify it. But We make Nextcloud for everyone, not just for you. Please change your tone a bit, as this is not constructive at all and you are a guest here.

In any case, from my side on this issue - the mobile apps I believe use the preview and then download the full image when you start to zoom in, the previous Gallery I think did something similar, so I think we could consider doing that, too. Perhaps then we could even consider making the default preview smaller (like, 2000x2000 pixels or even 1000x1000) because the full image will be there soon enough.

I'm not sure how urgent this is, though, but perhaps if somebody wants to work on this @skjnldsv would be willing to review and merge it.

[jancborchardt]

Well, we just need to do it automatically, and adjust to serve what is proper for the screen size of whichever device is connected.

No matter if someone is browsing Photos from a small smartphone or a 4k screen, it should display the photo in the appropriate size. Of course initially it can be a bit pixelated, while it loads the more proper resolution photo.

Additionally, as @jospoortvliet said:

the mobile apps I believe use the preview and then download the full image when you start to zoom in

---

For the download action, see the separate issue at #88

[darmbrust]

That still makes assumptions about what the user is doing with the photo. If I upload a super hi-res photo to nextcloud, it shouldn't (only) assume that I only want to view it at the resolution of the screen I've put the browser in.

There should be a way to get the native photo, with no resizing. A download button is part of that, but not all of it - because that takes me to a file prompt (one usecase). The other use case, is to just give me the full res photo, whatever it is, in the browser, so I can zoom in on details in a non-pixelated version, without jumping through hoops. Ideally, a user could set that "full res" option once, and it would be honored as you continue browsing, because now, the server could stop wasting cycles resizing images - just do thumbnails, and full res. In my use case, on a local network, it would be far better performing that what I see now, with nextcloud spending tons of time generating previews, and then doing it again when I move the browser to a larger monitor because I want to see the image at a non-pixelated resolution.

The old photos app did have a download button, but at least in the last versions of it, it was very confusing, because while it gave you a download, and used the native files name when it provided the file, it didn't actually serve the native file - it served a (much smaller) resized version. That is definitely not what I expect "download" to mean in the context of a file.

It appears that in the current Photos app, if one clicks on "View Image" in the browser (Firefox in my case) it prompts me to save the file - which is not what I would expect. I'd expect that behavior to be in a download button - and if I right click and say view image, the server would send the proper metadata so that the browser just showed the photo directly as an image, instead of prompting to save it.

[jancborchardt]

The other use case, is to just give me the full res photo, whatever it is, in the browser, so I can zoom in on details in a non-pixelated version, without jumping through hoops.

This is exactly what will be solved by

the mobile apps I believe use the preview and then download the full image when you start to zoom in

How and when exactly that downloading of the full image is to be done can be optimized as well. E.g. already preload when you start zooming just the slightest bit etc. Bottom line: Can all be automated, doesn’t need any setting.

---

while it gave you a download, and used the native files name when it provided the file, it didn't actually serve the native file - it served a (much smaller) resized version.

As said: For the download action, see the separate issue at #88

---

It appears that in the current Photos app, if one clicks on "View Image" in the browser (Firefox in my case) it prompts me to save the file - which is not what I would expect.

Good point. Mind opening a separate issue about that? Thanks.

[profi248]

Part of the problem is that Nextcloud's way of generating the thumbnails (GD) is slow. It would be awesome to see libjpeg-turbo (or a different more efficient library) implemented.

(oops, that's in a different repo, so maybe it doesn't really fit here)

[darmbrust]

The other use case, is to just give me the full res photo, whatever it is, in the browser, so I can zoom in on details in a non-pixelated version, without jumping through hoops.

This is exactly what will be solved by

the mobile apps I believe use the preview and then download the full image when you start to zoom in

How and when exactly that downloading of the full image is to be done can be optimized as well. E.g. already preload when you start zooming just the slightest bit etc. Bottom line: Can all be automated, doesn’t need any setting.

Is there currently a feature request opened for that? I've seen it mentioned, but didn't track if there was a specific tracker for it.
I've seen various trackers opened and closed over the last 4+ years of people asking for a way to get a high res photo on their screen, and they always end up closed....

Though I still think it would be nice to have an option to not generate the (larger) scaled image at all. In local deployments like mine, the time cost of generating scaled images is greater than just sending the larger file. My client computer has far more horsepower than my webserver, so it can do the scaling far faster on the client...

It appears that in the current Photos app, if one clicks on "View Image" in the browser (Firefox in my case) it prompts me to save the file - which is not what I would expect.

Good point. Mind opening a separate issue about that? Thanks.

sure :) - #579

[SimplyCorbett]

My issue with the lack of ability to download the original image is that I have my previews set to a low quality to save space. I can find the location and go through the file listing to download it but that takes a lot of time and it's frustrating for me.

Perhaps as a compromise there could be a button to open the correct folder to where the image is located?

This would be extremely useful in the photos app as there is no way to tell what folder a image is in on the default page other then a tiny URL when hovering over it on the bottom of your screen. Which IMO most of my family and regular people won't understand.

Alternatively we could use something other then GD or ImageMagick to generate previews. Something like @kostaldavid8 suggested. I understand there are security issues that would need to be worked around but somehow google photos can create high quality JPEG images with minimal loss of quality with very small filesizes.

[skjnldsv]

Part of the problem is that Nextcloud's way of generating the thumbnails (GD) is slow

You can enable imagick and it will be faster btw

Closing now, #579 have its own issue and is closed.
The download button have its own issue too.

We also optimized the loading and rendering of photos for 21.
You will significantly see a difference (we tried and ran tests on a 1k images set ~2.4Gio)

[someone755]

Slightly off-topic:

somehow google photos can create high quality JPEG images with minimal loss of quality with very small filesizes.

I know this is closed, but I've already had this debate on both the support forums and reddit; I use Flow to launch a script whenever an image is uploaded. This script calls convert to downscale the images to 12MP (Google Photos used to downscale to 12MP, then it was increased to 16MP), and then run jpeg-archive (basically mozjpeg). On average, compared to the original photos from various smartphones, this saves >50% of space, and the changes are nearly imperceptible (similar to Google Photos and Guetzli). Most of my images are <1MB, many are just a few hundred kB. (For proof, this was a compression run of images from a Mi A2 Lite: https://pastebin.com/raw/tfPRhwGZ showing the size before, size after, and % saved).

Given the above, it makes no sense to me that I have to choose between

• visible thumbnails in Gallery/Files, but a very bad image gets shown to the user (arbitrarily chosen dimensions and arbitrarily chosen JPG quality), OR
• the original image gets shown to the user (because bandwidth isn't a problem for me, and besides my images are small enough as is), but I have to guess which image I'm clicking on because there are no thumbnails

I understand you don't want to add options everywhere, but this hard either-or choice is banal in my eyes. I don't mind the preview image getting generated, I just don't want it to be shown to the end user. (I understand it is used as a source image for thumbnail generation? Though I don't see why they couldn't be generated from the original file.)

[zylstra]

@skjnldsv, why is this issue closed if it has not been fixed?

[darmbrust]

From what I can see, the maintainers of the image apps in nextcloud have a very small view of the use cases for images in nextcloud, and they refuse to introduce anything that is outside of their usecase. Combine that with replacing the image viewer every 3 or 4 years with a new one that is missing half of the features the old one had, and we get where we are today.

The unfortunate reality of opensource projects.

The authors of the new viewer in nextcloud 18, I'm sure, did a lot of work, and made a lot of improvements for their use cases.

But then, rather than introducing it as an optional (unfinished) beta photo viewer to try out, and get feedback, as the future replacement for the existing viewer.... they just put it in as the new viewer in 18. And they didn't release the old one as compatible with 18.

As soon as people upgraded to 18, with any sort of variety of use cases, everyone was pissed at them, because they broke the world in about 10 different ways that they hadn't even thought of or tested for. "Fixes" for the worst of the ways they broke the world trickled in over the next year... but some things, like this issue, still aren't resolved. And everyone on both sides is upset, because the users that had all of their usecases broken are upset with the developers, and the developers are upset that it appears people don't appreciate their work to maintain the app.

So, we still have an image viewer that can't even do the basic function of allowing you to download the original file. (Which is maybe finally fixed in the most recent release of 21, according to the change logs)... And it is incredibly slow, because it wastes resources trying to convert pictures on request to who-knows how many sizes, rather than having the ability to just serve the file.

In my use case, everything would perform better if I simply had thumbnails for the grid view, and native images. But I've been informed, repeatedly, that my use case isn't valid.

They also seem to hold the religious opinion that any option is too hard for an administrator to understand, so options to configure the behavior for your deployment are verboten.

But yet, a complicated, error prone, broken tool like the thumbnail generator add on is the way to go, to attempt to fix the issue. Which in practice, doesn't really work any more. At least, not for doing anything other that wasting more disk space.

I'm sure this reply will be marked as off topic as well. But the the only real solution I see is to build a new photo viewer with different maintainers, unfortunately. This history of this thread, and the way 18 was rolled out speak for themselves.

Personally, I'd like to see the photo app feature of nextcloud simply "outsource" to something like https://github.com/photoprism/photoprism

No idea on the feasibility of something like that.

[BotoX]

This issue has been driving me crazy for a while now, finally got around to fixing it.
Nextcloud has become sooo much more usable and snappy with this simple three lines of code change.
Also I went from 209G disk used to 147G.

Make sure only one size (256x256) of previews are generated and used:
https://github.com/nextcloud/server/blob/952acd4d276b3190d23e0597c5e01b1dfc4d72bc/lib/private/Preview/Generator.php#L171

$width = 256;//$specification['width'] ?? -1;
$height = 256;//$specification['height'] ?? -1;

can be patched in place in lib/private/Preview/Generator.php on your nextcloud install.

Make the viewer display the full resolution image instead of a preview:

viewer/src/mixins/PreviewUrl.js

Line 74 in ff759ac

if (hasPreview) {

if (hasPreview && !hasPreview) {

You have to build the viewer (make) and copy the result from js/viewer-main.js to apps/viewer/js/viewer-main.js.

Would the nextcloud developers appreciate a pull request for this, configurable with three variables?
E.g. preview_force_x, preview_force_y and viewer_image_original ?

Edit: needs two more files edited (no recompile) to work properly on public shares too:
https://github.com/nextcloud/server/blob/952acd4d276b3190d23e0597c5e01b1dfc4d72bc/apps/files_sharing/lib/Controller/PublicPreviewController.php#L169

// $f = $this->previewManager->getPreview($node, -1, -1, false);
$response = new FileDisplayResponse($node, Http::STATUS_OK, ['Content-Type' => $node->getMimeType()]);

https://github.com/nextcloud/server/blob/952acd4d276b3190d23e0597c5e01b1dfc4d72bc/apps/files_sharing/js/public.js#L183

// img.attr('src', OC.generateUrl('/apps/files_sharing/publicpreview/' + token + '?' + OC.buildQueryString(params)));
img.attr('src', $('#previewURL').val());

[JasSuri]

@BotoX what does this do to the user experience?

And how to do this?

You have to build the viewer (make) and copy the result from js/viewer-main.js to apps/viewer/js/viewer-main.js.

[BotoX]

@BotoX what does this do to the user experience?

What do you mean? You see originals instead of previews now when opening images.
So pictures load slower over a slow internet connection.

And how to do this?

You have to build the viewer (make) and copy the result from js/viewer-main.js to apps/viewer/js/viewer-main.js.

https://github.com/nextcloud/viewer#-development-setup
Or just download the finished thing from my nextcloud: https://cloud.botox.bz/apps/viewer/js/viewer-main.js

Here's an example album from my nextcloud:
https://cloud.botox.bz/s/zwC5iHqDbzMS65p
And a single image: https://cloud.botox.bz/s/45k6j8HNxcMqdMQ

[mlemainque]

Thank you so much @BotoX for sharing this!

I host nextcloud on a RPi on my local network and was looking for an alternative to nextcloud because of the impossible tradeoff between browsing thumbnails and loading the full image in the viewer. I don't use public sharing so just modifying viewer/src/mixins/PreviewUrl.js made the user experience perfect now 🙏

It would be great to re-open this issue and have this as an option in nextcloud 🚀

[laurensbl]

Would it be hard to make a button in the upper right corner of the photo viewer that allows the user to toggle between full size image and preview image?

I'm no coder so just asking.

[shoaib42]

@BotoX

if (hasPreview && !hasPreview) {

A bit confused here, reads to me as

if(false) {

I think we can have this simpler (hacky, as in strictly fetching full image)

getPreviewIfAny({ fileid, filename, hasPreview, davPath }) {
    return davPath;
},

What would be sweet is some flag that gets checked before the getPReviewIfAny is called. Now if we can get the "showFullSize" flag from NC as a user preference, that sure should give each user what they want. While on the "backend", the admin decides the max resolution for Photo thumbnail/tiles.

The flag "showFullSize" being set by the user will have to be persisted. Adding to what @laurensbl suggested. Otherwise the user logging in the next time will have to flip the switch again.

if(showFullSize || !hasPreview) {
   //show fullsize
} else {
  //call getPreviewIfAny -> we will be passing hasPreview = true all the time
}

An even sweeter stuff will be "showFullSizeIfLT = x kb" that each user maintains (with an admin hammer of max x kb [to help metered networks]), will fetch unmolested full size images if size is less than x KB.

PS - php and JS are the languages that I've never touched :/ . I wish I could help here but it will be a few weeks before I can get familiar with them

[Pilzinsel64]

Would it be hard to make a button in the upper right corner of the photo viewer that allows the user to toggle between full size image and preview image?

Would the nextcloud developers appreciate a pull request for this, configurable with three variables?
E.g. preview_force_x, preview_force_y and viewer_image_original ?

Summary for the feature "toggle original image":

• Add config value viewer_image_original (default false) that shows the end user a button to toogle between preview and original image.
• Add config value viewer_image_original_default (default false) that enables the original image for end user by default.

Would that be an idea?

(Why I want this: Save space on the disk with preview_max_x/y + low hardware performance.)

[ristein]

I would too love a way to be able to zoom into pictures without having to download them first.

Another option I see instead of a user toggle:

• Create previews around 1000x1000 to show them first if a user opens an image
• If the user stays on that image for more than one sec or starts to zoom, download the full size image to replace the preview in place (like when searching images on duckduckgo)
• there might be limits needed for pixel count or file size a browser can display, maybe the user or admin can set this limit above which a bigger preview would be generated on the fly, like 4000x4000, according to system performance and link speed

Advantages would be that a user is still able to quickly skip through big photos and does not need to understand the usage of a switch.

[timdah]

Would it be hard to make a button in the upper right corner of the photo viewer that allows the user to toggle between full size image and preview image?

Would the nextcloud developers appreciate a pull request for this, configurable with three variables?
E.g. preview_force_x, preview_force_y and viewer_image_original ?

Summary for the feature "toggle original image":

* Add config value `viewer_image_original` (default `false`) that shows the end user a button to toogle between preview and original image.

* Add config value `viewer_image_original_default` (default `false`) that enables the original image for end user by default.

Would that be an idea?

(Why I want this: Save space on the disk with preview_max_x/y + low hardware performance.)

I second this. IMHO a small preview config is a legitimate use case where the viewer is not usable. Completely deactivating previews so that the viewer loads the original image is not a solution, since it's not possible to see which image it is in the overview.

Inspired from @BotoX s comment I wrote a little patch script that can be executed automatically after nextcloud updates (as long as these lines aren't changed).

sed -i "s/img\.attr('src', OC\.generateUrl('\/apps\/files_sharing\/publicpreview\/' + token + '?' + OC\.buildQueryString(params)));/img.attr('src', \$('#previewURL').val());/g" /var/www/html/apps/files_sharing/js/public.js
sed -i 's/new FileDisplayResponse($f/new FileDisplayResponse($node/g' /var/www/html/apps/files_sharing/lib/Controller/PublicPreviewController.php
sed -i 's/getPreviewIfAny:function(e){var/getPreviewIfAny:function(e){return e.devPath;var/g' /var/www/html/apps/viewer/js/viewer-main.js

[romkazor]

@timdah any fix for nextcloud 29+? Thanks

[nenatap]

@BotoX I found this issue as I was searching solution for the very same issue that you were facing: Too many and too big previews. Rather have small preview files and have nextcloud show the original when requesting files larger than the max preview size.
Looked at your example album in nextcloud and would love to have same funtionality on mine. Just that current versions (at least from NC ver 29 onwards, which I currently have) have split viewer-main.js to two parts (viewer-init.mjs and viewer-main.mjs), thus using the linked viewer-main.js is not a solution.

Though I'm definately not a developer, I installed npm + stuff, cloned stuff from git and went by the instructions on modifying the source and building the stuff. Got something out of that, but not having the deep knowledge of developing things, nothing functional came out. Ie. modified the code, built the stuff, replaced viewer-init.mjs and viewer-main.mjs with new versions. That just resulted to files not being shown but instead sent as attachment (ie. browser file save dialog opens) :(

Me and most likely many others too would appreciate it a lot if you can make available an updated version (for nextcloud 30.x) of the viewer which functions like the one you have on your own setup.

Ps. I can't understand why NC (as product) insists on showing the previews and not having option to show small previews and larger originals. the preview generation kills my system and eats all available filespace.

[BotoX]

@nenatap I've since switched to immich for photos.
It's soooo much better for photos, can not recommend it enough.
There are only two previews generated, configurable in the settings.
When you open a photo the optimized preview is shown first, if you zoom in the original will load in the background.

Upgraded to NC 30 today and applied the patches by hand one final time.
Since my previous links are dead:
Example folder/album: https://cloud.botox.bz/s/MoKoW5kHiJdDtoE
Example single photo: https://cloud.botox.bz/s/EazYn7WWD6m6CGZ

Here's a git diff file for the changes made on nextcloud 30.0.4-1 from the archlinux repo.
nc_30.diff.gz

Modified files:
apps/files_pdfviewer/js/files_pdfviewer-public.js
apps/files_sharing/js/public.js
apps/files_sharing/lib/Controller/PublicPreviewController.php
apps/viewer/js/logger-Ba6Q6YnM.chunk.mjs
core/Controller/PreviewController.php
dist/9918-9918.js
lib/private/Preview/Generator.php
lib/public/AppFramework/Http/FileDisplayResponse.php

The change in FileDisplayResponse.php only makes sense with the following line in your nginx config:

    location ^~ /xaccel {
        internal;
        add_header X-Accelerated "TRUE" always;
        alias /home/nextcloud;
    }

Adjust the alias path obviously.
This way files are not served by PHP anymore but by nginx:
curl -I https://cloud.botox.bz/s/EazYn7WWD6m6CGZ/preview
-> x-accelerated: TRUE

[nenatap]

Thank you. I'll have a go with the diff.
My setup contains of nextcloud in a container with apache and nginx as reverse proxy in front of those two. Haven't looked too deep into how the apache+nextcloud solution is built, but I assume it's to overcome the php ineffiency of sending (large) files. But I'm sure there are people who will find the FileDisplayResponse.php + nginx conf mod useful.

I'll need to have a look at immich, looks nice. Perhaps I'll might modify my setup to have my media on Immich and leave other boring data (everything except photos and videos) in my nextcloud.

Anyway, major thumbs up for your reply! few gallons of positive karma sent your way :)

[nenatap]

Additional comments after very tiny testing.
@timdah Have a look, there is updated fix which you were asking some time earlier

For others:
In the diff, there is a patch for Generator.php. What the patch does, is to make every preview file generated to be 256x256 in size, even though the system thinks it's going to generate for example 1024x2048.
Instead of the patch, just update your config.php and set
'preview_max_x' => 256, 'preview_max_y' => 256,
That will result to NC not even trying to start generating previews larger than 256x256, thus saves resources.
I've included here a version of the diff which doesn't update the Generator.php

For those who are not that fluent with developing, here is how you can apply the change (at your own risk, take backups etc):

• see the Nextcloud instructions for applying patch
• Unpack the attached file from here, use the .diff file as our patch, following the nextcloud instructions.
  nc_30_rev1.diff.gz