Great Hierophant wrote:

When were comb filters first introduced in composite color computer monitors or in consumer TVs?

I know nothing about computer monitors, but in TVs, it was the mid-to-late 1970s. More expensive models first, of course.

reenigne wrote:

Don't they amount to the same thing? (Assuming the filters are exactly matched).

I would imagine that to be quite difficult. It's way easier to just subtract the notch-filtered chroma than to exactly match the resonant bandpass to the notch filter. That why I chose the former approach.

reenigne wrote:

on the 25% and 75% grey sections it retains the full luma bandwidth (so you get a cross hatch pattern instead of a solid grey)

That's what you get if you take both luma and chroma from the comb filter, as seen in the attached picture. The other picture shows KQ1 again, this time with both luma and chroma from the comb filter. Notice the hanging dots, but also how the text is slightly clearer ("w" in "written). As I wrote before, my comb filter not not adaptive (yet).

reenigne wrote:

I wrote a little hack to display all the possible vertically alternating patterns - it'd be interesting to see what different comb filter algorithms make of this

Do you want me to produce pictures with my algorithm?

By the way, I just noticed when taking the luma signal from the comb filter instead of the notch filter, the dark gray is no longer solid even when post-filtering the luma to get rid of vertical bands. See the picture I posted before on the last page, now with luma from the comb filter instead of the notch filter. Where the lighter gray in the upper part was identical to the lighter gray in the middle part before, it now retains its checkerboard pattern.

Now I really think I should invest some time in making the comb filter adaptive, because now I found a reason to!

http://www.mobygames.com/game/quest-for-the-t … ird/screenshots
will this game be comb filtered too?

No, because from the palette used I can tell that it uses B/W mode, so no color at all on a composite monitor.

ok, so it wasn't intended to work this way. But it looks we can cheat it, cause for example ripsaw's enclosed dosbox makes it work in composite mode. So could a comb filter be applied to this composite picture?

When posting the test patch I mentioned that disabled color burst in mode 5 is not handled (red in the palette is characteristic of mode 5). If b&w composite is not going to be emulated with a luma-only palette, the other option is to fall back to RGB when color burst is not active -- although it could be confusing as to why there is no composite display even though it's been forced ON.

"Checkerboard" pixel patterns tend to produce alternating lines in composite mode that look like they could apply to a comb filter, but they actually don't. You can see in several of Servo's screenshots for Demon's Forge where there are alternating lines that are not affected by the filter.

ripsaw8080 wrote:

Checkerboard" pixel patterns tend to produce alternating lines in composite mode that look like they could apply to a comb filter, but they actually don't. You can see in several of Servo's screenshots for Demon's Forge where there are alternating lines that are not affected by the filter.

The point was to show that with a different kind of comb filter than the one that Servo's capture card uses, the checkerboard pattern does appear.

I was referring to robertmo's question, pointing out that just because something looks like it might be applicable to filtering doesn't mean it is.

Can comb filtering be done as post-processing, such as with a shader in SVN builds, or is too much information lost if it's not done earlier in the rendering process?

Comb filtering is basically an alternative method of luma/chroma separation, so it must be done at the rendering stage.

reenigne wrote:

NewRisingSun wrote:

But it won't necessarily make for particularly pretty colors. In particularly, people will continue to pester the developers about brown being too greenish or red being too pinkish, depending on the hue setting.

NewRisingSun wrote:

See pictures, all at a hue setting of ±0°. You would not need any fancy non-linear color correction either. That's actually the solution I would now favor, as there are no brownie points to be earned from following a 59-year-old standard as closely as possible.

I'm not convinced that there's any transformation which is going to make everyone happy as everyone is going to have their own aesthetic tastes and memories of how those games originally looked. So the best we can do is to make it as objectively correct as possible (according to the relevant standards) and then provide knobs that people can twiddle if they aren't satisfied with the outcome. I don't think the age of the standard has any bearing one way or the other.

VileRancour wrote:

"Pretty colors" is a rather subjective measure in itself, and if the qresult is cyan-colored grass (KQ1), bluish trees (KQ1, Black Cauldron), pastel-like yellows, etc., then I don't know how effective that would be in fending off user complaints.

NewRisingSun wrote:

Well, it can still be optimized, of course. 😀 But you notice that the grass in King's Quest is the same color as Graham's pants in King's Quest II, which are cyan in RGB. The booter version of King's Quest translates the same RGB colors differently to composite colors than King's Quest II.

as for color as Graham's pants in King's Quest II
they are green on the box http://www.mobygames.com/game/dos/kings-quest … eCoverId,13947/
and this screen shows this colour should be green too as the trees are of the same color
http://www.mobygames.com/game/dos/kings-quest … eShotId,312202/

NewRisingSun wrote:

Do you want me to produce pictures with my algorithm?

Yes please, if it's not too much trouble.

NewRisingSun wrote:

By the way, I just noticed when taking the luma signal from the comb filter instead of the notch filter, the dark gray is no longer solid even when post-filtering the luma to get rid of vertical bands.

That makes sense because the luma has a 3.58MHz component, and your post-filtering is only taking out the 7.16MHz component. Real hardware comb filters will leave this in because (on a 227.5 cycle-per-scanline signal) it represents detail in the form of vertical lines which is normally desirable to keep.

NewRisingSun wrote:

Now I really think I should invest some time in making the comb filter adaptive, because now I found a reason to!

I'm curious about what that would change for this case. Unless you specifically program it to recognize this sort of pattern and give the output you want.

robertmo wrote:

ok, so it wasn't intended to work this way. But it looks we can cheat it, cause for example ripsaw's enclosed dosbox makes it work in composite mode. So could a comb filter be applied to this composite picture?

You could, but what would be the point? This image was never designed to be displayed on a composite output, so it would look neither how the designer envisioned nor how it looked on any real hardware. Maybe what you really want is just a blur filter applied in post-processing which turns the checkerboard dithering into a solid colour, and which could work just as well with the RGB output as with composite - the colours would be as intended and no TSR hack would be necessary.

robertmo wrote:

as for color as Graham's pants in King's Quest II they are green on the box http://www.mobygames.com/game/dos/kings...rId,13947 […]
Show full quote

as for color as Graham's pants in King's Quest II
they are green on the box http://www.mobygames.com/game/dos/kings...rId,13947/
and this screen shows this colour should be green too as the trees are of the same color
http://www.mobygames.com/game/dos/kings...Id,312202/

Is this to do with the (ill-conceived, in my opinion) hack that shifts the hue 35 degrees when bit 5 of port 0x3d9 is set in composite mode?

reenigne wrote:

Is this to do with the (ill-conceived, in my opinion) hack that shifts the hue 35 degrees when bit 5 of port 0x3d9 is set in composite mode?

No, I mean that if we want to make colors prettier we should make light cyan between blue and green the way that nobody can tell for sure whether it is green or blue, like it is right now with dark cyan - it is used for:
water http://www.mobygames.com/game/dos/kings-quest … eShotId,312202/
clouds http://www.mobygames.com/game/dos/kings-quest … eShotId,312211/
and far trees http://www.mobygames.com/game/dos/kings-quest … eShotId,312208/
and nobody notices that.
Light cyan is too blue right now hence the problems.
The screens are from ega i think so it looks ega has the same problem and could be tuned to be prettier too.

VileRancour wrote:

As for the hard part (refactoring the proposed code to work with DOSBox's palette precalculation), here's what I was thinking: derive the 16 pixel patterns corresponding to each nybble for the current mode/color register, and feed them to reenigne's code (upsampled as necessary - the algorithm samples 1280 "sub-pixels" per scanline). For each nybble, take the result after 8 iterations (a full color-burst cycle), then use these values to populate the palette in the same way as the current implementation.

...Now that I actually tried looking at the numbers, the above approach isn't going to work... the current precalculation method (16 hues * 5 Y-levels) works as long as the original pixels are white/grey, since the 16 resulting artifact colors really have just 5 different Y levels between them (0, 0.25, 0.50, 0.75, 1 in the case of white). That doesn't hold in any other case, so those colors don't have matching entries in the resulting table.

It might be possible to "shoehorn" the real Y values into this, but that would likely mess with edge blending (besides being kludgy). So we probably do need an algorithm that can use more than the upper half of the palette.

Continuing my previous post:

It looks what NewRisingSun wants to achieve by making colours prettier by making red more reddish and brown more brownish or providing knobs for people to regulate like reenigne suggest is simply not possible, cause game programmers were using one color as more then one color even in one game. As a result they could use not only 16 colors of cga card (which are definitely not enough to reproduce reality) but actually twice more (ore even more). For example cyan can be used as green or blue, orange can be used also as brown, brown as green, green as yellow, purple as red, etc. Or yellow as 100 different shades of yellow 😉 This can be corrected now in dosbox if we make colors look as middle option between two colors. Of course a problem appears if game producer used one color as three possibilities: for example red can be used as pink or orange - see red carrot http://www.mobygames.com/game/dos/kings-quest … eShotId,318593/ That carrot would look ok if we introduced brown(orange) but cause there is already brown(orange) sand on the picture carrot has to be in a different shade of orange so it is red. It would look ok if we make a red(orange) color, but it won't look ok if the game would like to use that color as purple.

BTW - to look at colors a bit more open minded http://www.abovetopsecret.com/forum/thread749732/pg1

robertmo wrote:

It looks what NewRisingSun wants to achieve by making colours prettier by making red more reddish and brown more brownish or providing knobs for people to regulate like reenigne suggest is simply not possible, cause game programmers were using one color as more then one color even in one game.

Conclusion: Make it look like it did originally instead of trying to "improve" looks.

Actually i think making middle options is a better solution as it will make twice more colors look ok. Bluish green is less annoing than blue instead of green. Our mind can be cheated by middle options, but cannot by a totally different color.

TeaRex wrote:

Conclusion: Make it look like it did originally instead

There is no such thing. With composite color artifacting, there is just a tremendous variation of monitors, televisions with their own idiosyncracies, multiplied by the number of possible viewer-adjustable settings. It's not about improvement, it's the lack of an "original" as a reference.

One can solve that problem either by providing a plethora of adjustable settings and/or by trying to find reasonable defaults (or "pretty" colors, as I half-seriously worded it), which may not coincide with the behavior of the NTSC reference receiver (which only exists in theory anyway).

As far as King's Quest's booter version in composite mode is concerned, consider the attached photograph from a promotional source.

even with RGBI monitors, it has its own idiosyncracies.

I remember on some CGA monitor theres a button that 'i-believe' were designed to fiddling with mode 4.

One push will remove all blue-signal, this will change appearace as if using pallete 0 (black, green, red, brown/yellow).
Another push will forcibly add blue-signal, but its also affecting black color, as if you're somewhat using modified pallete 1(blue, cyan, magenta, white).
Another push will make the display look like black-green monochrome.
And another push of that button will return to normal.

robertmo wrote:

It looks what NewRisingSun wants to achieve by making colours prettier by making red more reddish and brown more brownish or providing knobs for people to regulate like reenigne suggest is simply not possible, cause game programmers were using one color as more then one color even in one game. As a result they could use not only 16 colors of cga card (which are definitely not enough to reproduce reality) but actually twice more (ore even more). For example cyan can be used as green or blue, orange can be used also as brown, brown as green, green as yellow, purple as red, etc. Or yellow as 100 different shades of yellow This can be corrected now in dosbox if we make colors look as middle option between two colors.

I think I understand what you are saying now, but I don't think DOSBox can (or should) do anything to solve the problem you're talking about.

If I'm understanding it correctly, the problem is this: There are some games where the art was originally made for EGA/Tandy/PCJr 160x200 16 colour mode (which has the standard RGBI colours) but which also support composite CGA (which has a completely different set of colours). However, the art was not redrawn to be optimized for composite CGA - instead (to save development effort and disk space) the developers just stored the original RGBI images along with a mapping (or possibly multiple mappings - some images might look better with one mapping than another) to convert between the RGBI colours and the composite CGA colours. These mappings were not even necessarily consistent between versions of the game (I've heard about DOS and Booter versions of the same game with the same art having different mappings).

These mappings have two (conflicting) goals: one is to make the image look as close as possible to the art as the artist originally envisaged it, the other is to use as many as possible of the composite CGA colours so that the game looks as colourful as possible. Remember also that these mappings are a part of the game, not a part of DOSBox (DOSBox has no idea, when a CGA composite pattern is drawn, what, if any, RGBI colour inspired it).

So there are two lossy transformations that happen to the image between the artist's mind and the CGA composite screen: one when it's converted to RGBI colours and a second when those RGBI colours are converted to CGA composite (not necessarily even using the closest colour). So it's little wonder that some of the CGA composite images from these games look very different to the box/concept art.

Now, if we try to "tweak" things with the explicit aim of making specific CGA composite images look better and/or more like the corresponding RGBI images, we're bound to make things look worse overall. That's because there are many games with many different RGBI->composite mappings (and many composite games with composite-specific art that was not derived from an RGBI image at all). If, for any given composite dot pattern, you look at all of the "original art" colours that map to that dot pattern across all games, you'll find that the colour in the middle of all those colours is the same as the average colour that that dot pattern produces over all the composite monitors used by the game designers, which in turn is going to be something pretty close to the ideal colour for that dot pattern that the NTSC standards demand.

That's why I want DOSBox to try to be as true as possible to NTSC rather than looking at any particular game to try to determine what the colours are supposed to look like. Looking at particular games is interesting when it seems like they're interpreting composite dot patterns in an unusual way, i.e. the colours are completely wrong because unusual hardware was used in the development (e.g. using a Tandy 1000 instead of an IBM CGA card, or using a monitor with a comb filter) but otherwise we shouldn't really worry too much about the colours in any particular game looking a bit off.

Joey_sw wrote:

I remember on some CGA monitor theres a button that 'i-believe' were designed to fiddling with mode 4. […]
Show full quote

I remember on some CGA monitor theres a button that 'i-believe' were designed to fiddling with mode 4.

One push will remove all blue-signal, this will change appearace as if using pallete 0 (black, green, red, brown/yellow).
Another push will forcibly add blue-signal, but its also affecting black color, as if you're somewhat using modified pallete 1(blue, cyan, magenta, white).
Another push will make the display look like black-green monochrome.
And another push of that button will return to normal.

Fascinating - I've never heard of that before! Some composite monitors and TVs had a switch to turn off the red and green signals for hue calibration (the SMPTE color bars test pattern will be continuous black and blue stripes when the blue switch is on and the tint is adjusted properly), but this is something different and hue calibration makes no sense for RGBI monitors in any case.

I remember using a monitor with an Acorn A3000 that had a button to switch between full colour and black/green monochrome - I guess it was useful for programmers/designers/artists who wanted to make sure their creations were usable on a monochrome monitor.