Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user IcePic ! (Registered 2024-12-03) You are not logged in - nap
CSDb User Forums


Forums > C64 Pixeling > Screenshots of Interlace Pics
2024-11-29 10:53
Raistlin

Registered: Mar 2007
Posts: 671
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
 
... 47 posts hidden. Click here to view all posts....
 
2024-11-29 13:46
Gordian

Registered: May 2022
Posts: 72
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
2024-11-29 14:52
Count Zero

Registered: Jan 2003
Posts: 1931
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) ?
2024-11-29 15:33
Gordian

Registered: May 2022
Posts: 72
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).
2024-11-29 16:14
MagerValp

Registered: Dec 2001
Posts: 1075
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.
2024-11-29 16:20
chatGPZ

Registered: Dec 2001
Posts: 11379
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.
2024-11-29 17:35
Raistlin

Registered: Mar 2007
Posts: 671
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
2024-11-29 17:38
chatGPZ

Registered: Dec 2001
Posts: 11379
What you could also try is producing two images that have the half-frames in alternating lines, and then put those into a gif like above - it may or may not reduce flickering
2024-11-29 18:13
Gordian

Registered: May 2022
Posts: 72
Quoting chatGPZ

browser doesn't offer "loop" either.

You mean just playing video file (not html file) directly in browser? There should be "loop" option in the context menu.

I really don't know what is going on with 2nd version. It's encoded via libx264 encoder and should works...

Third version: https://kawalekkodu.pl/video3.html
Works in Chrome and FF.
Command used:
ffmpeg -framerate 1/0.02 -i cyclone_%1d.png -r 25 -crf 0 -pix_fmt yuv420p -codec:v libaom-av1 outputvideo.mp4

Codec AV1: https://trac.ffmpeg.org/wiki/Encode/AV1
Browser support: https://caniuse.com/av1
2024-11-29 18:24
chatGPZ

Registered: Dec 2001
Posts: 11379
Quote:
There should be "loop" option in the context menu.

yeah, right. and it looks much less irritating than the gif version.

However, if browser doesn't loop by default (and there is no way to force it), its kinda useless
2024-11-29 19:15
Gordian

Registered: May 2022
Posts: 72
Quoting chatGPZ
Quote:
There should be "loop" option in the context menu.

yeah, right. and it looks much less irritating than the gif version.

Video has lower frame rate - closer to real interlace.

Quoting chatGPZ

However, if browser doesn't loop by default (and there is no way to force it), its kinda useless

Yes, it's useless if you want to play "interlaced" images outside the webpage. There is solution for this, just put more than 2 frame into video file, but it will grow.
Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 84
Top Demos
1 Next Level  (9.7)
2 What Is The Matrix 2  (9.7)
3 13:37  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.7)
6 Mojo  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.3)
Top Musicians
1 Rob Hubbard  (9.7)
2 Jeroen Tel  (9.7)
3 Mutetus  (9.7)
4 Jammer  (9.6)
5 Linus  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.07 sec.