Ok, that is bad.
I gave it a thumbs up on github. I hope this is something not too difficult to implement …
bb77:
In case I’m wrong with this, and it indeed shows you the original image in that case, you could of course write some script that regurarly deletes the larger preview files.
Yeah, I checked it with using the browser’s “developer tools”. When the preview file has been deleted, nextcloud shows the original file with DAV.
For example: https://test-myhost.invalid/remote.php/dav/files/57rrm5ue4z/Photos/20180826-161628.jpg
Nightly deletion would be a solution, but I just need to be sure nothing triggers the re-pregeneration of those already once deleted items. Aside of the fact that I’d love to see the original file when it’s been clicked on, the other problem is that previews are on local storage. Local storage is way more expensive than the S3 storage. But naturally, accessing local storage does not generate billable data transfer, which can start piling up if the images are downloaded several times a month due to re-doing the previews.
I understand the idea with previews. It has it’s positives, like: lets not transfer bigger images than which the client can display, thus save resources. Yet it does not always cause resource saving, just switches the resource consumption from one place to another (download bandwith → server storage).
Btw. looking at the browser console, I see the following:
viewer-init.mjs?v=ce59c294-0:4788 Loading of file preview 20180826-161628.jpg failed, falling back to original file
onFail @ viewer-init.mjs?v=ce59c294-0:4788
Perhaps I can do a personal hack (which I need to redo after every nextcloud update) and modify the viewer-init.mjs to always go for the original. Though it’s very possible, the modification may change the small thumbnails on file listing also to be shown on original size. Now that would not be very nice :).
If you already know the code and how the things work, I’d rather try to implement an official solution…
I don’t code for profession, not that familiar with javascript in general. Went to the chatgpt and asked it to give me code which would switch to the fallback method if image size is more than 300x300 px (yes, hardcoded to start experimenting). Got the updated code, but didn’t get results I wanted. Clicking on a image filename, will result the original image to be downloaded, not displayed. 
Almost got it, but not quite…
The update was in file viewer-init.mjs at line 4788
(Which is some 13000 characters long btw). The update was done in method updateImgSize
But as said, I didn’t get it right.
Heres the updated code just in case anyone is interested. Naturally I removed the comment and put all in one line, replacing the current method code.
updateImgSize() {
if (this.$refs.image) {
this.naturalHeight = this.$refs.image.naturalHeight;
this.naturalWidth = this.$refs.image.naturalWidth;// Check if resolution exceeds 300x300 and activate fallback if it does if (this.naturalWidth > 300 || this.naturalHeight > 300) { console.warn(`Image resolution ${this.naturalWidth}x${this.naturalHeight} exceeds 300x300. Activating fallback.`); this.fallback = true; }} else if (this.$refs.video) {
this.naturalHeight = this.$refs.video.videoHeight;
this.naturalWidth = this.$refs.video.videoWidth;
}this.updateHeightWidth();
this.doneLoading();
}
HEUREKA!!!
Chatgpt didn’t know his stuff. I gave the long code another look and I figured where to make the change.
In the file /var/www/html/apps/viewer/js/viewer-init.mjs
On the last line (line number 4788)
Replace following:
livePhotoSrc(){return this.livePhoto?.source??this.livePhotoDavPath}
with
livePhotoSrc() { return (this.livePhoto?.source && (this.naturalWidth < 300 && this.naturalHeight < 300)) ? this.livePhoto.source : this.livePhotoDavPath}
And you’ll be served with actual photos if any of the dimension is larger than 300px.
If anyone has any idea on how to access the configuration variables, please let me know what do I need to put instead of 300 to compare against the preview_max_y and preview_max_x that are set in config.php.
With this, it’s easy personal hack (until some NC version update breaks it):
Set preview_max_x and preview_max_y to reasonably small figure. Make the above code update. Result: you have thumbnails, but only small ones. Everything above that size will be served the original image using DAV.
Not sure how efficient or inefficient this is, but I doubt it will cause the server to DOS itself the same way currently happens without this modification. And it will save a ton of diskspace. And no need for deleting the previews every now and then.
Update 17th Dec:
I tried this with clean install just to be sure. Darn it, that made a difference. Apparently my earlier tinkering had affected things. Doing the change to pristine 30.0.2-apache (docker version), resulted to same unwanted behaviour than couple of messages earlier. That is, clicking the filename resulted to the file being downloaded, not shown in the viewer.
Well, back to the drawing board as one says…
SOLUTION FOUND:
@spyro @bb77
Available in comment made on 20th December 2024 Allow loading larger preview or full-sized images in image viewer · Issue #578 · nextcloud/viewer · GitHub
Hey, thanks for replying, and it sounds great - just to clarify, exactly what steps did you take to apply the change to your NC ?
Also there is some confusion in the GH thread you linked as to exactly what people thought the patch does. There is no documentation / explanation, and it touches files which seem to have been autogenerated? (I can’t see how any human wrote those incredibly long lines?)
PS. Can confirm your existing one liner does not work on NC 30.0.4
What is it for then?
I don’t want to be awkward, but the point of a file browser is browsing files.
During browsing, only thumbnails are needed. (I’m fine with 256x256 max, and have put that in my config).
When I click on one, I am no longer browsing, I am viewing. I now want the original file, or at least, one that is of equal or higher scale compared to my viewport (browser window).
I don’t see why this is not only possible, but the default behaviour. It is and has always been the default behaviour on every single file or image browser I have ever used.
Or to ask it another way - “Why does nextcloud do it differently than everything else?”
To be clear - the only logic that makes sense for this is:
Whilst browsing -
- Try to select the preview that is equal or greater in size than the desired thumbnail, if it exists
- Try to select the preview that is smaller in size if 1) does not exist
- (configurable) Display an image-file icon or autogenerate a preview if 2) does not exist
- If all else fails, display an image-file icon.
When viewing -
- Scale the selected preview up to the viewer size (so it can be displayed promptly)
- Select the nearest (larger or equal) preview size to the viewport, scale, and display it
- If no preview of at least the viewport size exists, display the largest preview, scaled up, and then download and display the full size image in the background.
This is really the only sensible behaviour. It accounts for users with small / low powered instances, who probably only want one small preview size, AND it also accounts for users with 64MB+ photos in 24k resolution, allowing for multiple levels of preview scale, to improve performance, whilst still not limiting them to only viewing the largest preview if zooming in.
The only completely unacceptable solution is what NC does at present, which is to completely deny the user the ability to view any image above the max preview size.
My gut feeling is that previews should (space and performance permitting) be generated on an x, x^2, x^3… series, rather than linearly, but this is already confgurable anyway, and thus a non-issue. There is clearly no point in generating a preview for … 3999x3999 and 4000x4000 - it’d take almost as long to load as the original anyway.