Closed profi248 closed 4 years ago
a simple solution, just serving full-sized picture
I don't understand why this isn't implemented by default.
A long time ago this feature was already discussed (https://github.com/nextcloud/gallery/issues/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.
I also, cannot fathom why none of the current image viewers I have tried have a button to show me the original photo. There is download, but that takes me to a file dialog. I don't want a file dialog. I just want the original, high quality photo in my browser. Why does this seem like a foreign concept to all of the nextcloud photo viewers? Gallery doesn't do it, the new (uesless) photos doesn't do it, the file viewer doesn't do it. For me, its the entire point of using nextcloud, to keep my photos handy, and yet, I can't view them worth a darn in any photo viewer. None of the slideshows even have a full screen option. I really don't understand the lack of these basic features in every single photo app.
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?
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.
the new (uesless) photos doesn't do it,
Please refrain yourself from posting comments like those in the future or think twice about phrasing so we actually get the will to read and help you. Thank you.
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! 👍
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.
I didn't say I was trying to preview a picture. I said I'm trying to view the picture. Your assumption that it makes "no sense" is rather flawed, and based on a use case that you assume, which isn't true for my deployment.
My nextcloud server is sitting 10' from the computer I'm browsing on, on a gig network. I have a 4K monitor hooked up to this computer, and, in any photo viewer currently available in nextcloud, I can't get anywhere near having a halfway decent photo viewing experience. In this deployment, the server is wasting resources generating midsize thumbnails I don't want, and refusing to give me an option to just view the file. The only thing I want from a photo viewer in my deplyment is small thumbnails for the folder view, and the ability to actually look at the photos in their proper resolution.
One would think those would be requirements 1 and 2 of a photo viewing app...
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.
Maybe you start to make those assumptions if the client is mobile, or at least least the administrator choose the behavior.
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.
Maybe you start to make those assumptions if the client is mobile, or at least least the administrator choose the behavior.
We need to cover all use cases. Having on-demand preview size of data is the best take we can do for this use case. If we start to say yes to every custom config switch we're receiving a request for, this is what our software will looks like at the end of the year. We won't do that.
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.
Like I said, my server is 10' from my computer I'm viewing on. My mobile phone already uploads the full size images to the server. And its configured to only upload on wifi, when I'm home.
The server just won't let me have them back (easily).
I'm not arguing there isn't more than one use case, but this is exactly why the administrator should be able to configure the server for THEIR deployment.
I'm not arguing there isn't more than one use case, but this is exactly why the administrator should be able to configure the server for THEIR deployment.
Feel free to edit Nextcloud's code and make it fit your need. We cannot supports everyone's setup. Sorry!
Maybe you start to make those assumptions if the client is mobile, or at least least the administrator choose the behavior.
We need to cover all use cases. Having on-demand preview size of data is the best take we can do for this use case. If we start to say yes to every custom config switch we're receiving a request for, this is what our software will looks like at the end of the year. We won't do that.
I hardly see why having an option either for the admin, or for the end-user viewer themselves to tick a box that says "show me the original photos" is anywhere near the end result you are leaping to.
And the fact that you argue so hard against providing basic functionality for "reasons" you assume, is part of the reason why people are so upset with the behavior of the devs and the photo viewers.
The fact is, right now, the file viewer currently takes a 4160x3120 image, and refuses to let me see it any higher resolution than 1024x768. That is NUTS.
the new (uesless) photos doesn't do it,
Please refrain yourself from posting comments like those in the future or think twice about phrasing so we actually get the will to read and help you. Thank you.
I understand, but do understand its hard to be patient when the developers discontinue something that was mostly working, replace it with something new entirely, that does 1/2 of what the old one does. The thread https://help.nextcloud.com/t/new-photo-app-in-nextcloud-18/69949/100 sort of speaks for itself.
It took what, only 8 months or so to get back another piece of basic functionality that was removed based on another flawed assumption? https://github.com/nextcloud/photos/issues/129
And then, that got released as 18.0.8 - and I'm still at 18.0.7, and the only option the updater now provides me is to go to 19. So I either have to manually update to 18.0.8, or jump to 19, and see what other random functionality has been removed in the sake of progress... or something....
Oh, and while you are arguing here about whether or not I'm "allowed" to send a 4 MB photo to myself instead of a 200K ruined versions of it, If I click on a video, I can watch a 1GB HD video in full screen. Served by nextcloud. With no mucking or reformatting by nextcloud.
But no, I might run out of bandwdith if you serve me an image? Give me a break.
Given your logic above, I think you really need to remove the ability to play or download your videos. Or, you know, start transcoding them down to something that can go across a mobile 3G network. Cause people obviously don't want to use bandwidth..... its just known to be true for all deployments.
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.
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 https://github.com/nextcloud/viewer/issues/88
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.
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.
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)
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.
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.
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)
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
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.)
@skjnldsv, why is this issue closed if it has not been fixed?
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.
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: https://github.com/nextcloud/viewer/blob/ff759ac0a48b2f5785e989f38323f790ddbebdac/src/mixins/PreviewUrl.js#L74
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()]);
// img.attr('src', OC.generateUrl('/apps/files_sharing/publicpreview/' + token + '?' + OC.buildQueryString(params)));
img.attr('src', $('#previewURL').val());
@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 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
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 🚀
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.
@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
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":
viewer_image_original
(default false
) that shows the end user a button to toogle between preview and original image.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 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:
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.
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
@timdah any fix for nextcloud 29+? Thanks