map8.six doesn't display

[roblourens]

Testing #183563

This worked with snake.six but something is wrong with this image and nothing is displayed when I cat it https://github.com/saitoha/libsixel/blob/master/images/map8.six

[Tyriar]

@jerch any ideas why map8.six wouldn't work in xterm-addon-image? It looks fairly simple

[jerch]

It seems the image is smaller than 1 row in height - since the addon only supports vt340 cursor mode, this line will get overwritten by the next shell prompt right after image output. To work around this, just append a NL, e.g. by appending and empty echo command:

$> curl -s https://raw.githubusercontent.com/saitoha/libsixel/master/images/map8.six && echo

(To see whats actually going on - you can also replace the echo with a sleep 5...)

[Tyriar]

Oh, is this something that other terminals do that we don't then? Could we force the empty line for small images?

[jerch]

Oh, is this something that other terminals do that we don't then?

Well yes and no. Its related to the question, where the text cursor should be at after a sixel sequence. There are like 5 different ideas about that floating around, which all have flaws for different reasons. Initially I had like 4 of them implemented, but after a longer discussion with @j4james and @hackerb9 I came to the conclusion, that only the vt340 cursor mode makes sense and avoids those flaws. (To put it in other words - the other emulators are broken in this regard)

Could we force the empty line for small images?

Nope this would not avoid that "issue", as it happens for every last row of an image, that does not form a full row height. It is basically up to app side to anticipate, whether a newline should be written or not (e.g. by grabbing terminal metrics & compare with image metrics).

Without going too much into details - in vt340 cursor mode the text cursor sticks to the row where the bottom-most sixel was printed, at the first sixel containing cell (does not move to the right, as sixel is "unbound" to the right side).

[j4james]

It's worth noting that XTerm updated their sixel cursor positioning algorithm to more closely match the VT340 behavior, so that map8.six test would also now be overwritten in Xterm, unless followed with an echo. And I know Contour also handles that case correctly.

It's been a long time since I tested any other terminals, and I suspect most are still wrong, but I'm hopeful that they'll all eventually start to converge on the correct behavior now that XTerm has gone that route (it's not perfect yet, but it's definitely improving).

[Tyriar]

Thanks for the info, sounds like it's by design then 👌

[hackerb9]

Last I check XTerm worked properly for map8.six.

Note that if you have a short prompt (PS1='$ ') you should actually see the image if you cat it to the screen. It's just that your prompt usually overwrites it.

Here's a screenshot from my VT340:

[Not visible in this image: The flashing text cursor after the first cat was inverting the olive color to a surprising purple.]

[jerch]

[Not visible in this image: The flashing text cursor after the first cat was inverting the olive color to a surprising purple.]

Just wondering - is this some sort of color or palette inversion going on? Do you have an idea, whats the algo behind this? (No need to explicitly test it, we deviate from text cursor coloring in other fields as well, and also on purpose...)

[j4james]

Just wondering - is this some sort of color or palette inversion going on?

On the VT240 (at least as implemented in MAME), the pixels in the screen buffer are represented by two-bit color table indices, and the cursor inverse just XORs those values with 0b11. So 0 is swapped with 3 (typically black and green), and 1 is swapped with 2 (typically blue and red).

On the VT340 you've got four-bit color table values, but I suspect its cursor inverse is implemented as an XOR of 0b0111 rather than 0b1111. That way your default colors (7 on 0) will get flipped to 0 on 7, rather than 8 on 15, which is more in line with what you'd expect from a non-graphic terminal.

The behavior of the cursor on the map8 image appears to confirm that theory. The green in that image is color index 2, so XORing that with 0b0111 gives you 5, which has been mapped to magenta. If it were XORed with 0b1111 you would get 13, which isn't used in that image, but defaults to light cyan.

[jerch]

@j4james Its really fascinating, what level of insight your are able to deduct from scarce DEC related resources. You are prolly right with the XORing, sounds perfectly plausible to me.

[hackerb9]

@j4james Its really fascinating, what level of insight your are able to deduct from scarce DEC related resources.

Yes, @j4james is a living DEC resource. Back in the early 80s the president of DEC was bragging about having literally a six-foot shelf of documentation. Now, we've got a six-foot @j4james of knowledge.

And, of course, he was right about xor with 0b0111.

When using the default VT340 colormap, the inverse color will always be the same saturation and lightness with the hue angle rotated by 180 degrees. For grays (saturation = 0), changing the hue has no effect, so instead the lightness is offset by around 50 percentile points.