| |
Raistlin
Registered: Mar 2007
Posts: 680 |
Screenshots of Interlace Pics
I’m interested to know what people’s thoughts are on screenshotting interlace pics…
On C64GFX, we do things a bit differently to CSDb. Generally, we care more about the original art than how it’s presented - so we’ll host logos with all the “extras” removed (scrollers, textual information, etc). But of course CSDb screenshots are of how things are actually released.
With interlace pics, it’s more complicated. In theory we should be displaying animations at 50fps (usually) switching between 2 screenshots.. but I’m lead to believe that that could cause battery drain and other problems on devices - plus the FPS probably wouldn’t be 50.
Some sort of blending was suggested.. or simply choosing alternate pixels and merging to create a full-res pic.
The latter is what I’ve tried with some pics .. eg. Some of Leon’s. It looks good and it looks like it’s true to the original creation - I’d hazard a guess that he simply drew these pics at full 320x200px resolution on most of these, actually, rather than drawing on C64 in an interlace editor?
Eg. https://c64gfx.com/image/168046
I toyed with the idea of blending the 1px offset pictures (frame 0 and frame 1).. but I’m not sure that that’s correct either.
Others have suggested some fairly complex blending schemes that presumably show more like it would be on CRT - and I think this is where the 1,000s of colours problem comes in (evident on many CSDb screenshots). This seems unfair since regular MC/HI screenshots don’t get the same treatment.
Anyway, interested to know thoughts… both for CSDb and for C64GFX.com |
|
... 71 posts hidden. Click here to view all posts....
|
| |
Gordian
Registered: May 2022
Posts: 80 |
Quote: Much, much better! Seems flawles on laptop and PC, and only glitches ocassionally on the phone.
However i'm not sure how much more data usage it would need. It is a matter of storage space, but more important on outgoing transfer. Depending on the plan it could impqact server costs greatly.
15186 bytes. |
| |
Raistlin
Registered: Mar 2007
Posts: 680 |
Quote: What about video?
https://kawalekkodu.pl/video.html
Trying on my phone, I’m just getting a static frame from this..? |
| |
Gordian
Registered: May 2022
Posts: 80 |
Quote: Trying on my phone, I’m just getting a static frame from this..?
Please check that file directly. You must set looping manualy.
https://kawalekkodu.pl/cyclone_de_l_interieur.mp4 |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Quote: Trying on my phone, I’m just getting a static frame from this..?
IT's that good!
Try zooming it, you will notice those are actually 2 images shown alternatively pretty quickly.
Though i noticed some compression artifacts. |
| |
Gordian
Registered: May 2022
Posts: 80 |
More accurate refresh rate without loss quality, but size is 69389 bytes.
https://kawalekkodu.pl/video2.html
Command used:
ffmpeg -framerate 1/0.02 -i cyclone_%1d.png -r 25 -crf 0 outputvideo.mp4
Files used: cyclone_1.png cyclone_2.png |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Hm - video.html works on my FF ESR (128.4 here currently) and Chrome, video2.html works on Chrome only. Shrug.
"Video can't be played because the file is corrupt." (using the mp4 directly - html has just a blank page) ? |
| |
Gordian
Registered: May 2022
Posts: 80 |
Quote: Hm - video.html works on my FF ESR (128.4 here currently) and Chrome, video2.html works on Chrome only. Shrug.
"Video can't be played because the file is corrupt." (using the mp4 directly - html has just a blank page) ?
There is something wrong with video codec. I will try encode later.
HTML is <video> tag with attributes autoplay, loop and muted (this one is needed to autoplay without user interaction). |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
I'd try a static 50/50 blend as the fallback, and then replace it with a javascript anim with two alternating 70/30 and 30/70 frames.
It'll never look exactly how it does on a proper crt in the web browser, so you'll have to find an approximation that isn't too jarring. Flipping between two frames without blending sadly never looks right on modern browsers.
Extracting hires pixels from MCI like your example above just looks wrong and should be avoided imho — it'll never look anything even remotely like that on a real C64. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Those flickering gifs are headache inducing, awful
video doesn't work for me (static), browser doesn't offer "loop" either.
I don't think there is a good solution for this. Not an easy one anyway. You'll either get non synchronised flickering mess - or some super unrealistic blended image.
Maybe you can steal a CRT shader with phosphor persistance somewhere and wrap it into a webgl based viewer. That might work - without showing totally unrealistic result. |
| |
Raistlin
Registered: Mar 2007
Posts: 680 |
Quote: I'd try a static 50/50 blend as the fallback, and then replace it with a javascript anim with two alternating 70/30 and 30/70 frames.
It'll never look exactly how it does on a proper crt in the web browser, so you'll have to find an approximation that isn't too jarring. Flipping between two frames without blending sadly never looks right on modern browsers.
Extracting hires pixels from MCI like your example above just looks wrong and should be avoided imho — it'll never look anything even remotely like that on a real C64.
50/50 blend is exactly what I'm working on right now - and I think is for sure the best solution.
Emulating CRT isn't something that I do for "regular" (non-interlace) images so I won't with interlace either. If someone wants to see these on CRT, they can just bring the pics up fullscreen and plug a CRT into their PC :p |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
