Preview v2

[Crykon]

Decided to work further with this preview implementation and slightly improve it, but preserve base implementation while you adding and connecting it to future release. If you like the changes made here you can merge them, just notify me and I'll update it from draft to pull request

[Crykon]

Made some slight improvements on previews dimensions and "stretched" images fix, see description for details

[Crykon]

I figured out how to save disk space, albeit with a slight (hopefully) impact on preview loading speed. To do this, I dug deeper into what takes up the most disk space and discovered that GIFs take up the bulk of it. So, what i propose (feel free to adjust/correct my approach):

For Images:
Downloading original previews from the site, and upon loading resize them to "previews" aspect ratio. After that save compressed images to previews GameID folder. With that, disk space can be improved slightly.

For GIFs:
Discard the usage of GIFs completely. Instead, use WEBM, with VP9 or VP8 (this works faster, and for some reason sometimes even better for preserving disk space). With that approach I could save 10x more disk space converting just one GIF from initial test (but depends from situation to situation, also needs further testing). After the downloaded GIF was compressed and resized, the changed preview is stored in previews GameID folder.

Such implementation only works for previews, for the full image/video (click to expand) I will think of another method

[WillyJL]

the main reason i had changed the way you sized previews was looks and consistency. it would create a fixed height bar, but the images inside it were themselves different heights, with some being stretched. it should be that either each image is displayed with fixed aspect ratio and cropped, or each image is displayed at an appropriate size for its aspect ratio.

rather than what you made here, i think a better compromise is having a fixed height but varying width of each preview, so they do not get stretched or cropped but also look nice and fill the space well.

i just implemented this on main branch with ae1081a, please give it a try and let me know if you still feel sizing needs more tweaks, otherwise personally i think this is quite satisfactory and i'm leaning towards closing this pr. i tested this new variant and it works quite well with both horizontal, square and vertical images imo.

about further improvements to preview system overall, im open to them of course (but please dont feel obligated to work on anything, should be on a want to do basis). if you do, ofc open a new pr for them; i ask that you kindly make new changes based off of the main branch: as you see, the commit history for this pr kept the commits from the previous pr, as you created this new branch basing off of the previous branch instead of the updated main branch with changes merged. this gets messy quick, so new prs should be based off of main branch without dangling commits from prior prs. it seems youre making edits directly via github web ui, in this case you should be able to go to the branch list, click new branch, choose as source WillyJL/F95Checker repo and main branch. this will set you up with an updated branch to make new edits in

[WillyJL]

about saving disk space: im not a huge fan of reducing quality of the previews on disk. the next change i was looking to implement myself was a way to click on a preview to maximize it, and cycle through all previews, with ability to zoom further in aswell; if previews are downscaled to lower quality once downloaded, this feature would suffer from it.

i am very much open to more efficient ways of storing the images though. it is true that gifs are terrible for space efficiency. but it'll be tricky.

for still images:

• most images on the forum are automatically converted to avif, which is to my knowledge the best performing image format storage-wise, so nothing extra to be done here (apart from reducing quality on disk, which as i said id prefer not to)

for gifs:

• gif is indeed a very wasteful format, would be great to convert gifs to a better format before storing on disk
• apng would work, f95checker already supports loading apng transparently, but it is even more wasteful than gif with the very detailed previews used for games
• also looked at transparent lossless compression (zstd) on top of gif files, this provides no space saving at all
• using video formats is probably the only way we'll be saving space, but they might prove tricky: while gif and apng focus on each frame having full (compressed) image data, video formats are much more complex encoding differences from one frame to the next to avoid storing each frame, thus they need a comparatively expensive decoding step. this might end up requiring embedding ffmpeg into f95checker, which would be a pretty significant change to consider before moving forward

[WillyJL]

fwiw, i played around a bit with webm: what im seeing with ffmpeg -i $file -c vp9 -b:v 0 -crf 12 -pix_fmt yuv420p ${file%.gif}.webm -y is quite promising, no noticeable artifacts (not any worse than the source gif), and 5-20 times smaller files. so i would be happy with this solution.

the question that remains to be answered, is how to convert to/from webm/vp9. ffmpeg is always an option, but its a bit of a long way around to get the raw pixel data we want in memory, since ffmpeg primarily works on files. theres opencv which might work for decoding. for encoding ffmpeg is still probably the best solution.

but... that would mean:

• 40-50mb for ffmpeg
• 40-70mb for opencv

thats a bit much to bundle into f95checker... idk

and there is still the unknown of how much time it will take to load gifs like this: opencv like this is cpu only, so it wouldnt take advantage of gpu acceletared decoding.

[Crykon]

looks and consistency

Okay, maybe I don't have much preview examples to differentiate each aspect ratio in one game, but for me horizontal and squared previews looked consistent. But I'll look on the branch you provided, thanks

should be on a want to do basis). if you do, ofc open a new pr for them

It's totally on my want to do basis, and thanks for mentioning opening a new pr for that, l'm new to this Github thing

about saving disk space: im not a huge fan of reducing quality of the previews on disk. the next change i was looking to implement myself was a way to click on a preview to maximize it, and cycle through all previews, with ability to zoom further in aswell; if previews are downscaled to lower quality once downloaded, this feature would suffer from it

I also thought about saving without destructive methods. For me the process looks that way of doing it:
The app takes the url of the previews on the site. After that it compresses it for previews-only option and stores it as already compressed images/videos (for JPEG/GIF only). On hovering the mouse and clicking on it for expand, the app has it's own temp folder, where it temporarily download one piece of expanded image, full size (for zooming). With such approach, we don't have many full-size images/videos, only cropped ones for previews, and on-demand redownloaded full-sized ones (since fewer people would like to open every single preview on full size, and coming back to see it again). That way we don't need to storage the all full-sized images, and also expanded images that were already looked up. The cleanup of the temporary folder could be made with "Refresh!" button or something.
That's my way of seeing it, maybe I'm overcomplicating something, if so we can discuss it further

but... that would mean:

40-50mb for ffmpeg
40-70mb for opencv

Well, yep, with this task for now I can't propose something more promising, for now I only know ffmpeg as a primary solution for all encoding purposes. Maybe there is a way to make it lighter in size, but for now taking up 100-150 mb to save more space in the long run would be more beneficial

still the unknown of how much time it will take to load gifs like this

That's why I decided in the first place to implement it to see the results. But with commit history here I don't wanna mess the progress with basis, so I'll create a new branch and pull request for this, thanks again for pointing that up

[Crykon]

I looked into this a bit more, and I don't think OpenCV would actually be necessary here.
Instead of using the ffmpeg CLI, we could potentially use the FFmpeg libraries directly (or PyAV as Python bindings for them). libavformat/libavcodec can decode VP9 directly into frames in memory, so there wouldn't need to be a file -> ffmpeg -> temporary raw file -> OpenCV path. The decoded frames could go straight into the existing OpenGL texture path.
Looking at ImageHelper, this seems like it could fit reasonably well with the current architecture: instead of Pillow -> ImageSequence -> RGBA bytes -> OpenGL for animated previews, WebM could use something roughly like PyAV/libavcodec -> decoded frame -> RGBA -> OpenGL.
There might also be another advantage here: since video is decoded progressively, we wouldn't necessarily need to keep every animation frame as a separate OpenGL texture. We could potentially keep one texture and update it with glTexSubImage2D() as frames are decoded. So besides the 5-20x disk space reduction, this could potentially reduce VRAM usage for animated previews as well.
The main concern I see would then be the dependency/bundle size and making sure PyAV/FFmpeg packages cleanly with cx_Freeze on all supported platforms. Decode performance would also need benchmarking before deciding whether this is actually worthwhile.
So maybe a small proof-of-concept decoder would be useful before making any larger changes, will do it in the next pull request. Feel free to reject or to propose alternative solutions

[WillyJL]

That does sound like a good solution, I'm very curious how it will perform

[WillyJL]

closing as mentioned earlier