5 ms·

It doesn't really - for this particular technique an ANSI-art editor should do (and was in fact used for almost all graphics in this demo, to one degree or anot

by viler 4y ago

It doesn't really - for this particular technique an ANSI-art editor should do (and was in fact used for almost all graphics in this demo, to one degree or another). :) I suppose there's a wee bit of physics if you want to fine-tune the results for a particular CRT monitor... not that we've really done much of that for the party-version, but there's some research on the original IBM 5153 CGA monitor at https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-palette/ https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale....

jart 4y ago
It is hard. Anyone can mix colors by hand in an ANSI art editor. However this demo is huge and certainly appears to be programmatically generated at times. It's very hard to program a computer to blend colors using CP-437 shade blocks, because you're not actually linearly interpolating two RGB values like you would normally in graphics programming. The blending happens in physical space, hence physics. Read the section about gradients in the link you provided. They say they tuned the gradients, but they didn't explain how they did it. For example, was it just spending countless hours eyeballing color combinations until it looked nice? Or did they use a formula like CIELAB ΔE* to predict how background / foreground / shade block combinations would be perceived? https://en.wikipedia.org/wiki/Color_difference#CIELAB_%CE%94E\\\\\\\\\\\\\ https://en.wikipedia.org/wiki/Color_difference#CIELAB_%CE%94...* Those formulas are much more complicated than the RGB((r2-r1)/2,(g2-g1)/2,(b2-b1)/2) blending that computers use in software (which just punts the problem to the chosen color space). Notice also how CIE needed to keep revising the formulas over the decades since color isn't something we entirely understand yet.
- deleted 4y ago
  [deleted]
- ajenner 4y ago
  The programmatic transitions between still images use linear RGB space, which is the correct way to interpolate between two colours. The maths behind it is pretty simple - essentially just reversing the gamma correction from normal (0-255) sRGB space before the interpolation and redoing it for the final colour (no need to get into the hairy areas of LAB or perceptual colour spaces for this). Once we know the colour we want, we choose the character (from a list of 6) and attribute which most closely matches that colour. Of course, it's all done using lots of lookup tables so that we can process several hundred character cells per frame.
  - jart 4y ago
    My point is that sRGB linear interpolation does not accurately model the blending of color that happens in nature, which is something that should happen with CP-437 shade blocks. Here's a web page I set up so you can see for yourself. https://justine.lol/color.html https://justine.lol/color.html Even within the context of sRGB itself, it's not "correct" at all. For example, yellow and blue should make pink. But sRGB predicts it as being grey. Depending on how good your monitor is, the shade blocks should make pink, but even that is usually thwarted somewhat by subpixel layout. For example, if you drag the window around on an LCD, the coloring of the shade blocks will change weirdly as subpixels move. Subpixel layout shouldn't be an issue with IBM-PC CRT monitors. I wish I had one to confirm what it does. But in general this is just one of the weaknesses of the sRGB colorspace. But if you use something like CIELAB then it does predict pink. But that space has weaknesses of its own. But those problems are nowhere near as challenging as shade blocks, because linear interpolation just chooses a new color and doesn't need to predict anything. To choose colors for shade blocks you're applying your model to predict a more natural phenomenon.
    - ajenner 4y ago
      There's a difference between linear interpolation of sRGB values (what you're doing on your page) and linear interpolation of linear RGB values (which gives better results). This is the explanation that made it all fall into place for me: http://www.ericbrasseur.org/gamma.html?i=1 http://www.ericbrasseur.org/gamma.html?i=1 . The linear RGB colour space is also a linear transformation of the CIELAB space so doing the interpolation in this space is equivalent to transforming to CIELAB space, doing the interpolation there, and then transforming back. However, for the purposes of Area 5150 I think the differences between sRGB interpolation and linear RGB interpolation would have been too subtle to notice since there are only 6 * 16 * 16 = 1536 dithered colour/pattern combinations to choose from in the first place - the error introduced by that quantisation is likely larger than the sRGB vs. linear RGB difference. But I used linear RGB anyway, just to be correct about it.
      - jart 4y ago
        I agree that gamma correction helps, but we're not talking about gamma, we're talking about color. Here's a version of the page I shared earlier with ITU REC BT.701 gamma correction applied: https://justine.lol/color-gamma.html https://justine.lol/color-gamma.html It still has the same color problems. In fact they should be easier to see now that the white/dark issue is fixed. Could you explain how linear interpolation is different from sRGB interpolation? I would have thought they were the same thing. If by sRGB you mean interpolating but being lazy about gamma, I'll be the first to admit that's just plain old incorrect, even though laziness is sometimes a virtue. Also are you one of the demo authors? If so we could probably move this conversation to Discord or email and we could try some more blending methods!
- viler 4y ago
  Oh I certainly won't say that it was easy, mind you. The artwork was just done over a long, long period of time. As mentioned elsewhere in the comments, my 8088 MPH blog post from 2015 already shows an early version of one of the images (and a couple are even older). :) Our toolset for this demo did include an image converter (CGAArt), which can in fact use several version of the CIELAB formulas for its metric, among others. That's by reenigne from our team, who has commented here so I'll let him elaborate on it if he wishes. Personally when I do this sort of artwork, I prefer to tailor it by hand to the target video mode; as you noted, certain parts were indeed converted programmatically, but a lot of that was down to time constraints prior to the party release. In the final version, I plan to rework/redo those.
  - jart 4y ago
    That's amazing. I would love to see a blog post for instance talking more about the math that went into taming the unique visual blending properties of the IBM PC! Because the way you all hacked shade blocks is just as impressive as all the hacks you put into things like the crt and ram. Most importantly, the shade blocks are readily available for creative applications today thanks to unicode.
- viler 4y ago
  Ah, I think I get the original question now - you referred to the dynamic blending during the fade transitions, not to the static dithering used in the actual image data. If so, disregard my previous reply (see ajenner's instead). :)

by viler 4y ago

jart 4y ago

It is hard. Anyone can mix colors by hand in an ANSI art editor. However this demo is huge and certainly appears to be programmatically generated at times. It's very hard to program a computer to blend colors using CP-437 shade blocks, because you're not actually linearly interpolating two RGB values like you would normally in graphics programming. The blending happens in physical space, hence physics. Read the section about gradients in the link you provided. They say they tuned the gradients, but they didn't explain how they did it. For example, was it just spending countless hours eyeballing color combinations until it looked nice? Or did they use a formula like CIELAB ΔE* to predict how background / foreground / shade block combinations would be perceived? https://en.wikipedia.org/wiki/Color_difference#CIELAB_%CE%94E\\\\\\\\\\\\\ https://en.wikipedia.org/wiki/Color_difference#CIELAB_%CE%94...* Those formulas are much more complicated than the RGB((r2-r1)/2,(g2-g1)/2,(b2-b1)/2) blending that computers use in software (which just punts the problem to the chosen color space). Notice also how CIE needed to keep revising the formulas over the decades since color isn't something we entirely understand yet.

deleted 4y ago
[deleted]
ajenner 4y ago
The programmatic transitions between still images use linear RGB space, which is the correct way to interpolate between two colours. The maths behind it is pretty simple - essentially just reversing the gamma correction from normal (0-255) sRGB space before the interpolation and redoing it for the final colour (no need to get into the hairy areas of LAB or perceptual colour spaces for this). Once we know the colour we want, we choose the character (from a list of 6) and attribute which most closely matches that colour. Of course, it's all done using lots of lookup tables so that we can process several hundred character cells per frame.
- jart 4y ago
  My point is that sRGB linear interpolation does not accurately model the blending of color that happens in nature, which is something that should happen with CP-437 shade blocks. Here's a web page I set up so you can see for yourself. https://justine.lol/color.html https://justine.lol/color.html Even within the context of sRGB itself, it's not "correct" at all. For example, yellow and blue should make pink. But sRGB predicts it as being grey. Depending on how good your monitor is, the shade blocks should make pink, but even that is usually thwarted somewhat by subpixel layout. For example, if you drag the window around on an LCD, the coloring of the shade blocks will change weirdly as subpixels move. Subpixel layout shouldn't be an issue with IBM-PC CRT monitors. I wish I had one to confirm what it does. But in general this is just one of the weaknesses of the sRGB colorspace. But if you use something like CIELAB then it does predict pink. But that space has weaknesses of its own. But those problems are nowhere near as challenging as shade blocks, because linear interpolation just chooses a new color and doesn't need to predict anything. To choose colors for shade blocks you're applying your model to predict a more natural phenomenon.
  - ajenner 4y ago
    There's a difference between linear interpolation of sRGB values (what you're doing on your page) and linear interpolation of linear RGB values (which gives better results). This is the explanation that made it all fall into place for me: http://www.ericbrasseur.org/gamma.html?i=1 http://www.ericbrasseur.org/gamma.html?i=1 . The linear RGB colour space is also a linear transformation of the CIELAB space so doing the interpolation in this space is equivalent to transforming to CIELAB space, doing the interpolation there, and then transforming back. However, for the purposes of Area 5150 I think the differences between sRGB interpolation and linear RGB interpolation would have been too subtle to notice since there are only 6 * 16 * 16 = 1536 dithered colour/pattern combinations to choose from in the first place - the error introduced by that quantisation is likely larger than the sRGB vs. linear RGB difference. But I used linear RGB anyway, just to be correct about it.
    - jart 4y ago
      I agree that gamma correction helps, but we're not talking about gamma, we're talking about color. Here's a version of the page I shared earlier with ITU REC BT.701 gamma correction applied: https://justine.lol/color-gamma.html https://justine.lol/color-gamma.html It still has the same color problems. In fact they should be easier to see now that the white/dark issue is fixed. Could you explain how linear interpolation is different from sRGB interpolation? I would have thought they were the same thing. If by sRGB you mean interpolating but being lazy about gamma, I'll be the first to admit that's just plain old incorrect, even though laziness is sometimes a virtue. Also are you one of the demo authors? If so we could probably move this conversation to Discord or email and we could try some more blending methods!
viler 4y ago
Oh I certainly won't say that it was easy, mind you. The artwork was just done over a long, long period of time. As mentioned elsewhere in the comments, my 8088 MPH blog post from 2015 already shows an early version of one of the images (and a couple are even older). :) Our toolset for this demo did include an image converter (CGAArt), which can in fact use several version of the CIELAB formulas for its metric, among others. That's by reenigne from our team, who has commented here so I'll let him elaborate on it if he wishes. Personally when I do this sort of artwork, I prefer to tailor it by hand to the target video mode; as you noted, certain parts were indeed converted programmatically, but a lot of that was down to time constraints prior to the party release. In the final version, I plan to rework/redo those.
- jart 4y ago
  That's amazing. I would love to see a blog post for instance talking more about the math that went into taming the unique visual blending properties of the IBM PC! Because the way you all hacked shade blocks is just as impressive as all the hacks you put into things like the crt and ram. Most importantly, the shade blocks are readily available for creative applications today thanks to unicode.
viler 4y ago
Ah, I think I get the original question now - you referred to the dynamic blending during the fade transitions, not to the static dithering used in the actual image data. If so, disregard my previous reply (see ajenner's instead). :)