I think I see a few things that could make the c++ code a bit faster... But will need to order one of these devices and wait for it to get here before I try.
Great progress so far!
I may have an idea to have a jitter-free program ! I'll experiment more on it tomorrow.
Trying to identify old hardware ? Visit The retro web - Project's thread The Retro Web project - a stason.org/TH99 alternative
There are still some errors in the image.
This is caused by this:
int x_scaled = 319.0/1070.0*(x-184);
In my QB64 code it is:
PSET ((319 / 1070) * (x - 305), y), color1
There must be something different with the counting of "x" in the C port...
This part was for "picking" of the pixels to be used. In "long" it was...
IF X = 306 THEN PSET (0, Y), color1
IF X = 309 THEN PSET (1, Y), color1
IF X = 313 THEN PSET (2, Y), color1
IF X = 316 THEN PSET (3, Y), color1
IF X = 319 THEN PSET (4, Y), color1
IF X = 323 THEN PSET (5, Y), color1
IF X = 326 THEN PSET (6, Y), color1
IF X = 329 THEN PSET (7, Y), color1
IF X = 333 THEN PSET (8, Y), color1
IF X = 336 THEN PSET (9, Y), color1
IF X = 340 THEN PSET (10, Y), color1
IF X = 343 THEN PSET (11, Y), color1
......
IF X = 1332 THEN PSET (306, Y), color1
IF X = 1335 THEN PSET (307, Y), color1
IF X = 1338 THEN PSET (308, Y), color1
IF X = 1342 THEN PSET (309, Y), color1
IF X = 1345 THEN PSET (310, Y), color1
IF X = 1349 THEN PSET (311, Y), color1
IF X = 1352 THEN PSET (312, Y), color1
IF X = 1355 THEN PSET (313, Y), color1
IF X = 1359 THEN PSET (314, Y), color1
IF X = 1362 THEN PSET (315, Y), color1
IF X = 1365 THEN PSET (316, Y), color1
IF X = 1369 THEN PSET (317, Y), color1
IF X = 1372 THEN PSET (318, Y), color1
IF X = 1375 THEN PSET (319, Y), color1
If this doesnt match exactly you have the jitter again...
I dont get it. Maybe the reason is that C applies other rules for rounding than QB64 in this calculation..?
Yes, thats it. In C ithe result is always rounded down...
Your C code says 184 and the QB code 305?
Predator99 wrote on 2020-07-17, 07:08:I dont get it. Maybe the reason is that C applies other rules for rounding than QB64 in this calculation..?
Yes, thats it. In C ithe result is always rounded down...
I put a round() into the calculation. I doubt that this is the problem. I rather think this is a sampling problem. The sampling is not accurate enough and we only let one pixel survive. As we have more than one sample per pixel, there is heavy oversampling, but only the last sample survives. And sometimes this already represents the next pixel. We need a kind of median filter, which picks the median pixel instead. Takes a bit of code to do that, but possible and it can be combined with reading more than one byte per loop. we can compute how many bytes per pixel we have (or samples per pixel), which will be a fractional value, so we need to also keep track of the error, and adjust the sampling once the error is bigger than one sample.
root42 wrote on 2020-07-17, 07:34:I rather think this is a sampling problem. The sampling is not accurate enough and we only let one pixel survive. As we have more than one sample per pixel, there is heavy oversampling, but only the last sample survives. And sometimes this already represents the next pixel. We need a kind of median filter, which picks the median pixel instead. Takes a bit of code to do that, but possible and it can be combined with reading more than one byte per loop. we can compute how many bytes per pixel we have (or samples per pixel), which will be a fractional value, so we need to also keep track of the error, and adjust the sampling once the error is bigger than one sample.
No. Try my QB64 program with the same sample data. Its much slower but the image is rock stable, no jitter at all.....
That might very well be. But there are sampling issues for sure. See this unscaled version:
It shows jitter in the original recording. Maybe it's the HSYNC heuristic that is failing, but even then we get the jitter in the scaled down version because we take only the last sample for each pixel. We should apply a median filter to reduce the noise. We can also do an average filter, but that will smooth things too much. Since we have a TTL signal, a median filter will be better.
Something is wrong in the C code also with the y and the detection of a new line. You can also see this in your above unscaled video.
When looking at the QB64 unscaled video (attached) also the right side of the picture is very stable. In your video there is a "hole" in the area where the arrow is....
In your Video I can see this only in the upper part where the letters "by bullfrog production" are. The remaining picture looks ok. With QB64 all looks OK (in all frames!).
Yes, that's what I meant with HSYNC heuristic. What is the actual definition of the HSYNC? it should have some form of length/duration? Currently this is tracked via the ref_len, I guess.
Ok, I did a continue when detecting the sync, which skipped a pixel. Fixed that, now the picture has less jitter.
EDIT: I also added the rounding, which removes a tiny bit more jitter. There still is jitter in the sampling itself, which we might filter out with the median filter.
We dont need a median filter....there is still a bug.
This is the QB64 HSYNC detection:
250 IF HSYNC = 1 THEN Ref_len = Ref_len + 1
252 IF HSYNC = 0 THEN Ref_len = 0
260 IF HSYNC = 1 AND x > 700 AND (Ref_len > 30) THEN PSET (x, y), 5: y = y + 1: x = 0
270 x = x + 1
I noticed there are some "false" HSYNC signals in the raw data. Therefore it must be at least 30 bytes long to be accepted. Also, it may only occur if the current line is at least 700 dots long.
In my code you see "THEN PSET (x, y), 5". This is not the drawing of the image. It simply puts a purple dot on the picture to mark the end of the scanline. You can see it it some screenshots I have posted here. This purple line at the right side has to be quite straight (+-1 pixel).
See arrows. Its almost a straight line. Each line has almost the same length (+-1 Pixel)
I dont think you see the same if yout put a pixel there....your lines do not all have the same length.
You may further analyze the problem by putting a colored dot to the pixels with "HSYNC = 1".
Has anyone had the chance to determine whether the 24MHz sampling process itself is jitter free?
If it's not, there is no clean solution.
But if it is, the secret lies in the phase offset between the sample clock and the original pixel clock, which, as I mentioned before, can be determined via cross-correlation between the measured sync-frame and a synthesized clean sync-frame.
This method would also implicitly take care of bouncing effects in the sync signals.
The final resampling from 24MHz back to the assumed original pixel clock can then be done efficiently with an incremental error algorithm similar to Bresenham's line algorithm, i.e. with nothing but additions, subtractions and bit shifts.
The algorithm's error accumulator variable would have to be initialized with a value that corresponds to the phase offset.
You might also want to use a lookup table for the indexed color to RGB conversion or leave it to SDL, entirely.
Declaring the pset function inline can reduce function call overhead.
The Hsync works fine. see new video:
@Benedikt the sampling is not jitter free in my opinion. Rendering the full res capture shows definite jitter. You will have to explain the phase offset reconstruction in more detail to me. I personally would have used a median filter on the sampled image with a window size of roundup(samples/pixel). I would have assumed that this gives us a good heuristic that filters out outliers without blurring the image.
I do get the error accumulation part though, but I guess that's not possible, since it looks like the capture is not perfect.
root42 wrote on 2020-07-17, 09:36:The Hsync works fine. see new video:
OK looks fine! Does it look the same in the unscaled picture?
If yes please try some variants of the line
int x_scaled = 319.0/1070.0*(x-184);
e.g.
int x_scaled = 319.0/1070.0*(x-183);
int x_scaled = 319.0/1070.0*(x-185);
Thanks!
Yeah, 183 makes it better: https://youtu.be/MnD5oGBcEUg
But this is just "luck" a proper median filter will result in the same and will be proofed against other jitter/different samplings or resolutions.
root42 wrote on 2020-07-17, 09:36:@Benedikt the sampling is not jitter free in my opinion. Rendering the full res capture shows definite jitter. You will have to explain the phase offset reconstruction in more detail to me. I personally would have used a median filter on the sampled image with a window size of roundup(samples/pixel). I would have assumed that this gives us a good heuristic that filters out outliers without blurring the image.
The deciding question is whether the visible jitter is due to the phase offset that naturally varies from line to line and from frame to frame or due to genuine irregularities in the sampling process.
The basic idea behind my phase offset reconstruction approach is to synthesize an equivalent sync frame (i.e. ~ 1/60 s of sync signals) at the original 14.31818MHz, to resample it to 24MHz using next neighbor interpolation and various phase offsets and to compare that to the measured sync frame to pick the matching variant, because you can then derive from that interpolation which pixels wound up in which samples.
(You would then also know how close to the center of a pixel or the border between pixels a certain sample point is.)
Will take a look at it later, thanks! You may call it luck but this way its 100% accurate at 320 resolution 😉 I didnt notice one single Display error in all Tests i have done.
Yes, for higher resolutions it will not work this way...
