Thumbnails: Check <oc:has-preview> property

[guruz]

...instead of assuming it from the mime type to be an image. This fixes (for example) preview for .txt files.

Found this thanks to this iOS(!) issue: opencloud-eu/ios#72

Introduced by @micbar in opencloud-eu/reva#214

[guruz]

@zerox80 Aren't those x and y way too big?

Sample URL:

https://demo.opencloud.eu/dav/spaces/d21381aa-01dc-45cb-a5b8-e6880c47c954$4a67caa3-cff0-4899-a69d-816848d23b9d/Neue%20Datei.txt?x=1024&y=1024&c=dbf4efd4e5454eaa002f1434df768b2b&preview=1

Comes from buildPreviewUri function.

web UI also uses high values though: &x=1000&y=1000

TODO: Find out why web UI uses &processor=fit

Are we potentially wasting bandwidth here both in App and Web UI @micbar ?

[wernrab]

Looks consistent (besides the big x and y values discussed)

[guruz]

web UI also uses high values though: &x=1000&y=1000
Are we potentially wasting bandwidth here both in (Android) App and Web UI @micbar ?

It looks like the vaues changed last time since I used it, now it's 320 320

https://demo.opencloud.eu/dav/spaces/d21381aa-01dc-45cb-a5b8-e6880c47c954%24baf1910c-04be-41bd-9c24-685871975b18/OpenCloud_UI-Tabelle_Web_2400px.jpg?scalingup=0&preview=1&a=1&processor=fit&c=fa75f3cd21ef3f204d446f813d306a3b&x=320&y=320

iOS app 120 120:
https://demo.opencloud.eu/dav/spaces/d21381aa-01dc-45cb-a5b8-e6880c47c954$baf1910c-04be-41bd-9c24-685871975b18/blabla.txt?y=120&preview=1&scalingup=0&x=120&c=%228ece9c818bfcbed71b7a438d4bfd3596%22&a=1

@butonic @micbar @dschmidt Does the preview generating thingy on the backend pre create certain sizes we can request so they are more aligned/cached/whatever?
Shall the Android app also use 320 320 like the web one?

OK there is documentation here.
https://docs.opencloud.eu/de/docs/next/dev/server/services/thumbnails/information/#thumbnail-resolution
https://docs.opencloud.eu/de/docs/next/dev/server/services/thumbnails/environment-variables#environment-variables-for-the-thumbnails-service THUMBNAILS_RESOLUTIONS

[kulmann]

web UI also uses high values though: &x=1000&y=1000
Are we potentially wasting bandwidth here both in (Android) App and Web UI @micbar ?

It looks like the vaues changed last time since I used it, now it's 320 320

Yes, web has introduced some more resolutions and also adjusted the backend side defaults (see below).

OK there is documentation here. https://docs.opencloud.eu/de/docs/next/dev/server/services/thumbnails/information/#thumbnail-resolution https://docs.opencloud.eu/de/docs/next/dev/server/services/thumbnails/environment-variables#environment-variables-for-the-thumbnails-service THUMBNAILS_RESOLUTIONS

No matter what sizes you request, you will only ever get one of the predefined resolutions back. At the moment that's the following list of resolutions:
"[16x16 32x32 64x64 128x128 500x280 280x500 1000x560 560x1000 512x2048 1080x1920 1920x1080 2160x3840 3840x2160 4320x7680 7680x4320]"
The thumbnail service will pick the resolution that's closed to your requested resolution.

[dschmidt]

They are not pregenerated but they are cached after viewing a resolution for the first time.
IMHO, yes, you should probably stick to THUMBNAILS_RESOLUTIONS (if you request something not in the list, you'll get the next bigger one that satisfies your request - that can be quite a performance killer ... I know for reasons :))

That being said, I think we should add more sizes to the default thumbnails_resolutions.. the existing ones don't really provide anything suitable for my upcoming Photos app opencloud-eu/web-extensions#529

[dschmidt]

Ah, I wasn't aware we already had the new resolutions in the default config - those help, yeah :)

[kulmann]

Ah, I wasn't aware we already had the new resolutions in the default config - those help, yeah :)

Yeah we also had the issue in web, that for "normal sized tiles in the tiles view" the images returned from the backend were ridiculously large. 😅

[guruz]

@JammingBen Regarding https://github.com/opencloud-eu/opencloud/pull/3386/changes ...

iOS is requesting either 120x120 or 180x180 depending on device pixels. (might even be 60x60 on old phones!?)
Android right now (wrongly) requests 1000x1000 (I'll change this)

Do you have a proposal how to align this?
Should defaultconfig.go be extendded more to have something matching the 180x180? (I guess the 120x120 goes to 128x128 and iOS scales it down?)

Which processor= shall I use? I guess 'fit' like in webinterface, right now iOS and Android specify neither and images just display part of it.

[JammingBen]

iOS is requesting either 120x120 or 180x180 depending on device pixels. (might even be 60x60 on old phones!?)
Android right now (wrongly) requests 1000x1000 (I'll change this)

You can keep requesting those sizes, the server will pick one of the next entries from the list. Which one depends on if the image is portrait or landscape. The server matches the longer side I believe (though there are times where I don't quite understand the matching exactly).

So requesting 120x120 with processor: fit will return 128x... or ...x128 depending on the image format, while matching your original image's aspect ratio. Requesting it with processor: thumbnail will make it square and return 128x128.

Requesting 180x180 should return 280x... or ...x280 with processor: fit.

Should defaultconfig.go be extendded more to have something matching the 180x180? (I guess the 120x120 goes to 128x128 and iOS scales it down?)

I'd rather not introduce more small steps if there is not a good reason to do so. It's not meant to have one exact matching config for each requested size. You can maybe look at it as "quality steps". More config options would offer more granular quality (and therefore size) control, but also less efficient caching.

Which processor= shall I use? I guess 'fit' like in webinterface, right now iOS and Android specify neither and images just display part of it.

It depends on the use case, fit keeps your original image's aspect ratio. Also see https://docs.opencloud.eu/docs/dev/server/services/thumbnails/information#thumbnail-processors.