Thank for sharing your results, it’s really interesting and not only for RPi-users.
I suppose it is not possible to use the raw image when using the max-preview? And only do it for some sort of camera RAW formats that are not directly supported by browsers.
Very interesting! I didn’t know that my preview folder took up over 160GiB until I checked it because of your article.
I would’ve liked to see a comparison of disk usage from your sample data between the default config and your optimized config of the preview generator. Because I don’t really mind the cpu time.
Still an excellent article with obviously a lot of work put into it and a lot of insights given to the reader! Thanks again for that
Thanks @tflidd I assume that the max image is there in case the picture is really big, for instance 20MiB. In that case it would be a waste to send 20MiB to the browser.
That being said, when it’s a reasonable size we could save space by using that one directly, instead of storing an identical copy in the previews folder…
In my particular case I save 69,90% cpu time and 79,82% of space with the optimized settings, which i find pretty neat. I can also confirm, that image quality looks nice, as far as i have seen it.
My findings for the default and optimized run are not 100 % comparable because they were done on a production system, but i think they should be good enough. Neither was the cpu blocked by any other process, nor were there major changes to the file system.
@nachoparker I have made a post regarding the jpeg_quality showing that Nextcloud internal preview generation does not use the same setting as previewgenerator for jpeg_quality. Would you care to comment on that?