I was thinking of touching up the help website, which currently has spotty hardware building instructions (especially Hardware Mods Library is sparse) and no documentation for the current web UI at all. I considered taking screenshots and documenting the web UI, but found some flaws in the option names and help text I'd like to improve first, as well as some options I don't understand yet.
[x] In the Resolution/Presets tab, when showing help, the preset buttons remain tall and go off-screen. Is this worth fixing?
I'll have to look into how to change the CSS, perhaps arranging items using a vertical flexbox instead of setting height to calc(100vh - #px), since the height of the help text may vary between computers.
[x] For the fixed resolution presets, should I add "Selecting a resolution also makes it the new startup preset"?
[x] What does Auto Gain do? It makes the image coming from my Wii brighter, and gets turned off when I pick a fixed resolution. Is the brighter image more accurate or too bright?
[x] In the scanline and bob help text, should I mention that scanlines are active when combining 480i sources with bob deinterlacing?
Is it a good idea to outright rename menu items, or does this break existing forum post advice? (The official documentation is already outdated and doesn't apply to the current iteration of the web UI.)
[x] Rename "RGBHV/Component Toggle" to "Output RGBHV/Component"?
One time I tried toggling this switch, because I thought it would make the GBS-C switch inputs faster between component and RGBs. Then none of my VGA monitors would see an output anymore, and I thought I had fried my PCB until I factory-reset my GBS-C and discovered it started working again.
[x] Rename "Custom Slot Filters" to "Save Filtering(?) Per Slot"?
I didn't know what the original name meant (though I still don't know if I'd understand the new name without showing help).
Enabling help is a good idea on most tabs, but it makes the Settings tab too long and overflow off a single screen. I'm not sure what to do about this.
[x] Should Help remain expanded when you refresh the page (possibly saved client-side, like Developer Mode)? It currently gets lost when you reload.
[x] The current documentation says that motion adaptive deinterlacing adds 1 frame of lag. In my measurements, I found zero frames of lag (beyond the normal 1/10 frame from frametime lock) in changing areas of the image. Additionally image lag would go against the TV5725's design, which uses the current frame for bobbing, followed by motion estimation using a causal vertical IIR plus 1-frame-delayed motion estimation and feedback (all built for zero frames of intrinsic latency), and no latency in the deinterlacer's output.
Download: 480i motion adaptive latency.zip. I took a 192khz Audacity capture of 480i scaled to 480p, and recorded switching between black and white screens, then switching between 240p Test Suite menu and "Drop Shadow Test".
What did you mean when you wrote that Motion Adaptive "adds 1 frame of lag"?
Did you think that was true when you wrote it?
Were you talking about how the deinterlacer transitions between flickering and solid colors?
The deinterlacer chooses to treat 2-field flickering as weaved stripes rather than bobbed flickering (except next to moving edges). I think it treats flickering as a still image because each field is identical to 2 fields ago, and ignores the large difference between the new field and the previous bobbed frame (see Programming Guide 6.3.1).
When I record with a 240fps camera and enter the "Drop Shadow Test", a black field (!= 2 fields ago) produces a black frame, a white field (!= ^2) produces a white frame, a black field (= ^2) produces a black frame, then a white field produces a striped frame. I'm guessing the second black frame was caused by feedback: the first white field didn't match 2 fields ago, so that area of the image was "memorized" as moving for the subsequent black field?
I think feedback is meant to avoid interlacing failure modes caused by only comparing to 2 fields ago (not the previous field). If I turn off feedback (enable MADPT_MI_1BIT_BYPS) and view the "Drop Shadow Test", the entire moving shadow is treated as non-moving (striped black) on every transparent frame, but the edges are treated as moving (solid black) on every opaque frame.
Because the deinterlacer treats flickering as a still image, it waits to see 2 bright fields in a row before it outputs a bright output image rather than weaving. Is this what you meant by 1 frame of lag? (Though it's impossible for a human who interprets flickering as non-motion (and therefore weaving) to do better from an information-theoretic perspective.)
Did you mean that unchanging areas of the image (which weave the current and previous field) have 1 frame of lag on every other scanline? Latency is unimportant in unchanging areas by definition, and I think the GBS-C doesn't often misdetect moving areas of the image as unchanging (though I could be wrong).
Does the deinterlacer add latency or fail to detect motion in small parts of the image changing? I didn't test whether that this happens, partly because I can't resolve much horizontal detail within scanlines using an audio interface as an "oscilloscope", partly because I'm not sure how to use 240p Test Suite to generate interlacing test patterns. (Though I did verify 0 frames of latency entering/exiting "Drop Shadow Test", which is a smaller change than going from all-black to all-white.)
Did I make a mistake in testing, and motion-adaptive deinterlacing does add one frame of latency in some situations?
To be safe, I verified both capture tracks have 480i input, and I didn't test 240p by mistake: alternating fields have 48 vs 54-55 samples of gap between the final active scanline ending and the first vsync pulse beginning.
I don't think I tested Bob by mistake. I remember my deinterlacer was set to Motion Adaptive rather than Bob before testing, I checked that it still is now, I saw (and recorded) motion-adaptive artifacts like scanlines on flickering objects during testing, and I didn't switch to Bob at all.
Should we add more documentation for the filter types?
I observed that "line filter" 'm' = wantVdsLineFilter enables vertical linear interpolation, but only when the output resolution is above 480p (I have no clue how it affects 15KHz output, and I can't actually display it to check for interlacing or filtering/moire, nor record the VGA signal directly). I think the GBS-C first performs line-doubling or deinterlacing (if needed) to an internal 480p framebuffer, then upscales the framebuffer vertically to the output resolution, and "line filter" switches upscaling from nearest-neighbor to linear.
[x] Honestly I think "line filter" should get its own help entry separate from scanlines, since it eliminates blocky artifacts when upscaling 480p sources (or worse yet, non-uniform nearest-neighbor upscaling at 720p).
[ ] And it should be on by default after factory resetting (IIRC it would turn itself off after a factory reset).
Unfortunately, when inputting horizontal lines at 480p and enabling "line filter" at 720p output, I think I see moire in the output. Though I don't think 720p is a good output resolution for 480-line sources to begin with.
I observed that peaking 'f' = wantPeaking would result in symmetric(?) overshoot around horizontal (not vertical scanline-discretized) brightness changes. But I don't know if this overshoot arises from the Wii's DAC or the GBS-C, and can't identify without an oscilloscope.
Why is there no vertical overshoot? The PDF says "if you enable vertical scaling up function, you must disable vertical peaking function", and you enable vertical scaling up and set VDS_VSCALE.
[x] Is peaking designed to act as an "unsharp mask" style filter, which adds overshoots around edges (boosting high frequencies)? I still don't really understand the PDF's section on peaking, or your Vds_PK_.._ register writes. Is the low/band/highpassed image added to the raw signal, or replaces it?
I recall there was some option or code, intended to align sampling with the source's pixel clock. Do you remember what it is?
[x] What does step response 'V' = wantStepResponse do?
It seems to control VDS_UV_STEP_BYPS, which only affects color. No wonder I couldn't see a difference in previous tests. Now I notice a color saturation difference in "Color Bleed Check" runing at "480p scaled 240p". This should be documented as well.
I'm not sure I like either peaking or step response, since they alter the incoming image. In particular, I turned off peaking for playing games, since it looks bad in Check Mii Out Channel on a widescreen LCD (it adds halos/fringing around black hair on light backgrounds), though it looks less bad on CRT and makes small text (like Homebrew Channel) higher-contrast. But I can keep the help descriptions marking them as recommended, since I don't currently want to make any debatable subjective changes that aren't purely more unambiguous, accurate, and/or comprehensive.
[ ] What does <!-- prettier-ignore --> mean? Do I need to add them when editing lists, or can I leave it as-is if I'm not using Prettier? You don't seem to use it in any build scripts.
I was thinking of touching up the help website, which currently has spotty hardware building instructions (especially Hardware Mods Library is sparse) and no documentation for the current web UI at all. I considered taking screenshots and documenting the web UI, but found some flaws in the option names and help text I'd like to improve first, as well as some options I don't understand yet.
calc(100vh - #px), since the height of the help text may vary between computers.MADPT_MI_1BIT_BYPS) and view the "Drop Shadow Test", the entire moving shadow is treated as non-moving (striped black) on every transparent frame, but the edges are treated as moving (solid black) on every opaque frame.'m' = wantVdsLineFilterenables vertical linear interpolation, but only when the output resolution is above 480p (I have no clue how it affects 15KHz output, and I can't actually display it to check for interlacing or filtering/moire, nor record the VGA signal directly). I think the GBS-C first performs line-doubling or deinterlacing (if needed) to an internal 480p framebuffer, then upscales the framebuffer vertically to the output resolution, and "line filter" switches upscaling from nearest-neighbor to linear.'f' = wantPeakingwould result in symmetric(?) overshoot around horizontal (not vertical scanline-discretized) brightness changes. But I don't know if this overshoot arises from the Wii's DAC or the GBS-C, and can't identify without an oscilloscope.VDS_VSCALE.Vds_PK_.._register writes. Is the low/band/highpassed image added to the raw signal, or replaces it?'V' = wantStepResponsedo?VDS_UV_STEP_BYPS, which only affects color. No wonder I couldn't see a difference in previous tests. Now I notice a color saturation difference in "Color Bleed Check" runing at "480p scaled 240p". This should be documented as well.<!-- prettier-ignore -->mean? Do I need to add them when editing lists, or can I leave it as-is if I'm not using Prettier? You don't seem to use it in any build scripts.