Thumbnails size in file list doesn't match requested preview size

[bazuchan]

Steps to reproduce

Open folder containing images. It shows thumbnails in 64x64 size. But requests images of size 500x500 to display this thumbnails.

Expected behaviour

Images of size 64x64 are requested to display 64x64 thumbnails.

Actual behaviour

Images of size 500x500 are requested to display 64x64 thumbnails.

Server configuration

Operating system:
Ubuntu 18.10

Web server:
nginx + php-fpm

Database:
mysql

PHP version:
7.2

Nextcloud version: (see Nextcloud admin page)
15.0.2

Updated from an older Nextcloud/ownCloud or fresh install:
Updated

[skjnldsv]

Hello! This is on purpose for a compatibility with the grid view :)
We had a discussion about it (performance wise) and decided it was still very decent.

[bazuchan]

(performance wise) and decided it was still very decent.

Well, it is not for me. I can't scroll folder containing several thousand of images with 500x500 previews, it will stop showing previews at all after showing around 50-100 first ones (looks like because server timings to get image gets up to 10 seconds). And I do have pregenerated 512x512 previews. If I change to 64x64 previews scroling works fine. This is on 8-core VM on top of 2xE5-2620v1 server.

Also, 500x500 previews are 50-100kb in size, just loading folder with 100 images requires ~10MB of data transfered.

[skjnldsv]

Actually we fetch 250px images and they're about 20KB

[bazuchan]

I see https://xxx/index.php/core/preview?fileId=332354&c=1b49252159ee603963dd872140f8ab11&x=500&y=500&forceIcon=0 urls requested in developer tools.

[skjnldsv]

server/apps/files/templates/list.php

Line 34 in 6a3f4e4

<table id="filestable" class="list-container <?php p($_['showgridview'] ? 'view-grid' : '') ?>" data-allow-public-upload="<?php p($_['publicUploadEnabled'])?>" data-preview-x="250" data-preview-y="250">

data-preview-x="250" data-preview-y="250" :)

[bazuchan]

server/apps/files/js/filelist.js

Line 2106 in 0c8a000

urlSpec.x *= window.devicePixelRatio;

and I do have HiDPI monitor both on laptop and mobile.

[skjnldsv]

Nice catch! I guess it's then a bit too much! Thanks :)
@jancborchardt shall we revert?

[jancborchardt]

This is the first report we get about this, so not sure it warrants reverting?

Also, at this stage the grid view is not default yet, but it might be with Nextcloud 17 if we polish it more. And then we need the big thumbnails anyway. So I would say we should leave it as is.

[dgtlmoon]

I can confirm this at current 17.0.1 master my head is 51d3f98bfb83b632be6223a5d928d57e8e52e942

The thumbnail according to chrome inspector is 150x150 pixels.

the background url is http://172.18.0.1/core/preview?fileId=446&c=80c49cc440c54e05493e75f064aaa36e&x=325&y=325&forceIcon=0&asdfasd=adsfasdf23

however the response gives me a 1024x1024 image, considering i may have thousands - really saturating my network IO

1024-1024-crop.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 96x96, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 90", baseline, precision 8, 1024x1024, frames 3

Digging deeper I , when I access that URL see that Generator\getPreview() $width and $height are called with a value of 325 but when it reaches

		// Calculate the preview size
		list($width, $height) = $this->calculateSize($width, $height, $crop, $mode, $maxWidth, $maxHeight);

$width and $height become 1024 inside of calculateSize()

because in ce10f8b

This resulted still in a lot of possible images. Generating a lot of
server load and taking up a lot of space.
This moves it to previews to be powers of 4: 64, 256, 1024 and 4096
Also the first two powers are always skipped (4, 16) as it doesn't make
sense to generate previews for that.
We cache preview pretty agressively and I feel this is a better
tradeoff.

essentially - it gets rounded up to 1024 because it is not 325 and not near 256

In other words - whatever is setting the thubnail size preference is TOTALLY incompatible with the backend's ability to use scaled image sizing, the backend is limiting to a select size of thumbnails! either 256 or 1024 !!

I set in config.php ..

  'preview_max_x' => 325,
  'preview_max_y' => 325

but

		list($maxWidth, $maxHeight) = $this->getPreviewSize($maxPreview, $previewVersion);

still returns 4092, 3072

so the thumbnail sizing is a big steamy pile :/

.... This moves it to previews to be powers of 4: 64, 256, 1024 and 4096

at ce10f8b it is changed from rounding to a size of powers of 2 to powers of 4...

reverting that commit atleast gives me a 245 pixel image, instead of a 1024 image, although it's still loaded in a 130x130 pixel box......

in Drupal and Wordpress you just define an image size for the thumbnails, and then it's created once when required. no one cares if they get a slightly lower or slightly higher resolution thumbnail.

Whatever is doing the fancy JS for detecting DPI etc and then requesting a certain size thumbnail , in my opinion is a total waste of time, it should just dish up a general thumbnail FAST, this would entirely remove the all this wierd code about setting power of 2 or power of 4 pixel sized limit images, cut down on CPU and Disk IO just use a default size.

then on image request just get the one size.

there, fast, and you have less data to worry about

https://github.com/nextcloud/server/blame/0c8a0007a98d4b8df4b53298451d822292605be6/apps/files/js/filelist.js#L2106

this concept of caring about the DPI for thumbnails is 6 years old! I really think it needs to be thrown out, no one cares about getting exactly an amazing thumbnail at the tradeoff of having dozens of open issues here on github about slow thumbnail generation because it's making 6 useless thumbnails per image

• remove the DPI stuff for thumbnails, I have never seen this in other systems, it adds too much complexity and dependencies on different thumbnail sizes
• have a default thumbnail size which is clearly documented and configurable, 1 size will fit 85% of people, and the others can just tweak a well defined setting.
• stop all the pain with people running cron scripts to pregenerate thumbnails and gallery images which are never used!

total madness! simpler is better!