Survey results and what was it all about? (9/10/26)

So, first things first, thank you all 22 people who downloaded and ranked the animations to their tastes, without your input I would be kind of lost. Also shout out to the ONE lovely survey responder with the eyes of a freaking hawk. You discerned a loss in frames on Amelia's animation and you were absolutely right. The video loader node magically ate 3 frames, turning a 96-frame animation into 93, cutting the animation short. You went above and beyond the call of duty and I truly thank you for saving me this headache of finding this out in the future. 
This will be a long rant so if you want to just see the results do down to the RESULTS in bold.
That being said, what started all this? Why did I suddenly put up an animation test? Well it was a few days ago when I started integrating builds that I noticed that my animations didn't look that good when full screen, but looked mostly fine when I was playing normally which is Windowed around 1366x768 on a 1080P screen. It was then that I figured out the problem, another AI AVN dev has told me 720P was good enough that they couldn't discern the difference, but animations in isolation looks completely different than what is actually in game. So I originally generated all my animations to 720P assuming it would work just fine because they looked good windowed and in isolation. Sadly, full screen with my model using 720P was not cutting it at all. As the 22 of you saw, it comes up blurry in most cases.
So if you guessed resolutions were what I was testing, you'd be partially right! While deep in this revelation I fell down the whole rabbit hole of quality, size, CRF, bitrates, containers, and codecs.
I initially used the standard workflow from my fellow AI AVN dev and a different one for non-looping animations. First and foremost, knocking some complaints out of the way, not all animations will be perfect loops. Sometimes the looping workflow does not generate enough motion to sell the scene. Secondly, motion lines are something I've removed from the initial renders from Chapter 7 onwards. These are animations of older renders where I didn't think I would have animations. And third off... artifacts with the background, etc. are really out of my control. I can't tell the model to not insert or make artifacts. It's sadly the nature of how AI animations work, even then I am selecting the best result.
Here an in depth look on what happened. So as I was testing upscaling for this animations test because I saw how blurry 720P looked, so I immediately went the route of extra processing power to upscale it frame by frame. Only to find out that I was noticing a lost in details from upscaling sometimes, not drastic ,but clear loss of details compared to the original render. There is a reason why I did not show you the original render alongside the animations as it would easily expose the missing details which would contaminate the survey results.
Since this is a public post I will only use the face of the Elaine CG that started off what I called blushgate. Why the Elaine watching you sleep CG? Because she is only blinking at you, which means it's easy to spot differences when staring at her lovely face. So the original render's face looks like this.
The detail is in the blush, notice those few lines of blush in your mind as I show you what happened to it in subsequent trials.
My original H.264 MP4 animations was 720P with CRF 20 on a 0-51 scale. 
A quick aside for those who don't know with Google's answer on what CRF is.
CRF (Constant Rate Factor) is a video quality setting where higher numbers mean heavier compression and lower quality, while lower numbers preserve more detail at the cost of larger file sizes. When set too high, it aggressively compresses the video data, causing clean animation lines and smooth colors to break down into ugly, blurry pixels. Different codecs also use different CRF scales, so the numbers aren't directly comparable between them.
As I was saying, the original workflow node was saving at 720P with CRF 20 using H.264 encoding in a MP4 container. So while it is not the worst quality is also is not the best especially with anime style linework.
As you can see (this is stretched to my 1080P screen) that the detail of her blush is basically muddied pretty badly at this CRF so you can guess what happens to it when I tried to upscale that.
Basically all the blush details disappeared, which drove me on 10 side tangents of maybe it was the upscaling model I was using erasing the blush (it was not). Turns out it was a matter of garbage in and garbage out in the simplest terms. You can't upscale details that weren't there to begin with. So this led me to go on another side quest. Because I had to convert all the MP4s to WebM anyways for Ren'Py, I figured maybe I try a lower CRF of 12 using VP9 encoding straight to WebM instead of double converting lossy animations. (For VP9 the range is 0~63 and 0 is not lossless, there is a specific lossless flag for VP9.)
This was the 720P copy that was used in the survey, as you can see it maintained the blush lines far better at the cost of a larger file size due to CRF.
And this was upscaled to 1080P, which was also in the survey, then saved at CRF 24 with VP9 to not blow up the file sizes. As you can see, it maintained more of the blush data than upscaling the MP4 at CRF 20. You may be asking why 24? Why not 12 like before to maintain all the quality? File size. I do not want the readers to be downloading HHCIRB and going OH MY GOD ITS 5 GB+ because I did not want to compromise on quality. One last example.
Just as a sanity check, I made this 1080P blinking animation at both settings. CRF 24 was 613 KB. CRF 12 was 1.35 MB. This is the CRF 12 version, and it is barely better at over twice the file size for an animation where she's basically just blinking. Imagine that over 1k+ animations, and now you know why I had to make a decision on using a higher CRF (based on survey results).
Okay I lied there is ONE more test I did, skipping the entire saving video > upscaling video > saving video again. Which technically is still a lossy into another lossy. But it netted an interesting result.
So this method is with an incredibly long ass workflow, that take 8~10+ minutes because it uses the direct animation frames it generates and does not save it in a lossy format, instead it goes straight to my upscaling workflow. Can you guess what CRF this is? If you thought 24, you'd be correct, technically best of both worlds of detail retention and file size with this being 685kb. Downside being animation upscaling time and it hammering all 64 GB of my ram with the workflow so it goes into pagefile. This WAS one of the worst case scenario since it is about 4 or so minutes for the original animations already, so basically double.
As you can see, there is just so many options/compromises decisions you can make.
Which leads me to the downside of finding all of this out. Time, I need to upscale everything for sure based on the results of the survey, but which method is dependent on this poll put below. There is basically two options here, redo my animations at a higher baseline CRF to not lose as much details, and go upscale that version. Or the longer version of upscaling directly from the output animation. I already have the prompts that created the animations I want, so it mostly just rerunning them workflow again with one directly doing upscaling in workflow taking longer and maintaining more details vs double lossy with higher baseline with upscaling in a different workflow. Both ending at a CRF 24 VP9 webm copy for Ren'Py, you do not need to vote right away, I have to get through the results of the survey first.

RESULTS

So after that entire spiel, time to get to the results of the survey, which was very interesting.
I was testing two things, upscaling and CRF at the same time, seeing if a lower CRF (higher quality lower compression) but lower resolution vs higher CRF with an upscaled resolution of 1080P and 1440P with an even higher CRF. The exact settings I tested were all VP9 encoded webm, 720P CRF 12, 1080P CRF 24, and 1440P CRF 30. Why these specific CRFs? They are about the same file size roughly.
So starting off with resolution, 14 were 1080P, 4 was 1440P, 3 was 4k and one lonely 16:10 user at 1920 x 1200.
More than half of you that answered played full screen 13/22 (59%) while the rest played windowed.
While I can't show you exactly the differences are due to the nature of the content, I can tell you the results.
For Elaine's animation
Elaine 1 720P
Elaine 2 1440P
Elaine 3 1080P
Elaine 1 had the lion share of 3rd ranks and a lot of comparisons of it being blurry while Elaine 2 and 3 were essentially tied in 1/2 ranking votes with the qualifier of too close to tell being over 50% with 22% saying all of them are similar. 18% said none were too close.
For Celia's animation
Celia 1 1080P
Celia 2 720P
Celia 3 1440P
Celia's animation is a bit interesting in this case, where the 1440P actually had more #1 votes while the 720P results weren't as unanimous like Elaine's. This time was about 40% saying 1 and 3 were similar with 27% saying all similar. 22% this time said not all 3 are similar and they could tell.
For Sierra's animation
Sierra 1 1080P
Sierra 2 1440P
Sierra 3 720P
Sierra 3 was nearly unanimous on being ranked third, the fuzzier pixels clearly showed that it was worse with 1080P looking better this time. 54% said 1 and 2 are similar with 22% saying they all looked the same. Only 13% said that none of them look the same this time.
For Amelia's animation
Amelia 1 720P
Amelia 2 1080P
Amelia 3 1440P
Far more interesting and split result, while 720P clearly was ranked third most of the time, even the 1440P version had its fair share of 3rd ranks. This one had a whopping 59% on 2 and 3 with 22% saying all looked similar and 13% saying it doesn't look similar at all.
And last but not least, Athena's animations
Athena 1 1440P
Athena 2 1080P
Athena 3 720P
Another interesting result where 1440P got far and away more 1st votes and 2nd was obviously 1080P, but with the qualifiers 54% said 1 and 2 were too close to rank. 31% said all three are too similar and none was at 9% the lowest yet.
So what was my conclusion of this animation survey? 720P that I originally rendered with isn't going to cut it at all as you can see, which sadly means another delay. The 720P strat may have worked for other devs/other art styles, but it's clear this exposes a lot of flaws in mine and makes it blurry by stretching it to 1080P. That means I need to upscale to sharpen it, and if you read about blushgate above, you'd understand where I am coming from of wanting higher quality baselines to not erase my intentions/details from the scenes as from the original renders/cg. Since most could not tell the difference from 1440P/1080P it's clear to just use 1080P in case of more artifacts and such and the potential for slight decoding issues from bumping it up.
Luckily this is not picking animations from scratch (as in rerolling them since I still have all the meta data), but the down side is upscaling still takes time per animation and QC to make sure it doesn't turn out worse. I could straight upscale from what I have currently, but it would leave out a lot of facial details as shown above which is something I really do not want to do (and then go back to redo it).
So there is only two viable ways forward, one is re-render the animations to CRF 12 baseline, then upscale to 1080P, depending on the render say the base takes about 4 minutes, upscaling would take anywhere between 1 ~2 minutes.
While the other way is to link my upscaling workflow into the end chain for maximum detail retention, using the same example as before it would take 4 minutes, but the upscaling would probably take 4 minutes as well due to basically pinning my RAM to the limit. I really hate how I have to keep delaying Chapter 7, but it's clear that 720P would be incredibly subpar viewing experience that I didn't see when I was playtesting the way I normally do which is windowed on a pretty condensed window.
How long will I need? I really am not sure how long the entire process will take to upscale everything to 1080P, but I will still be coding/implementing the rest of the build as I work on upscaling. I'd say minimum two weeks due to needing to do this over 1,000 animations regardless of method. I am sorry for all the delays, I really am. You can cancel your sub with me until I actually get CH 7 out if you want to. It's been so long since the last release that I genuinely feel bad taking your money while I keep asking you to wait for Chapter 7. Just so we're clear I am NOT abandoning the project, I just need more time to upscale all these animation assets to 1080P, but it's clear I have taken way more time than I'd like.
While this poll is running I will be doing the 2nd option with retaining more details even though it hammers my PC more so I would be coding on my laptop instead, but to me the details is worth it. Though if the supporters/readers think I should go for the other way to cut a bit of time, I will swap to that. Basically a short overview on time line is say 6~minutes x 1000 animations with some loss of details vs 8-10 minutes each, but maintaining more of that original render detail due to outputting the frames directly.
Thank you as always for your support, I hope you can see half the rabbit holes I went down for the animations.