Support OR mode which is enabled by -O, --ormode option.

[arakiken]

I would like to add -O option to img2sixel.
It enables "ormode" extension of Sixel Graphics.
"ormode" is originally devised by https://twitter.com/isaki68k and https://twitter.com/moveccr for NetBSD/x68k.
Please read http://www.pastel-flower.jp/~isaki/NetBSD/osc16hi/page40.html and https://github.com/isaki68k/sayaka/blob/master/vala/sixel.native.c#L133 for more information.

[arakiken]

Here is more detailed information
https://qiita.com/arakiken/items/26f6c67da5a9f9f907ac

[coveralls]

Coverage remained the same at 0.0% when pulling d404b80 on arakiken:ormode into 6a5be8b on saitoha:master.

[saitoha]

I intend to incorporate this new feature eventually. However, since updates to the documentation, Python interface, and shell completion scripts are also required, I will first work on it in a separate branch. Once all components are ready, I plan to merge it into the master branch.

[saitoha]

@arakiken On several test images (e.g., images/egret.jpg), the output ends up larger than when encoded with -Esize.

On average I’m seeing a 30-40% reduction, but in about 25% of cases the file size actually increases.
result.txt

[saitoha]

The banding artifact at the bottom of images is fixed by @j4james’s patch (#187).

[saitoha]

@arakiken I’d like to start by offering this as a build-time option (default off), document it, and then gauge whether experts and terminal emulator authors will accept it.
I’m a bit uneasy about using the parameter P2, and i think we should also propose a companion capability-detection mechanism -- e.g., a DA/DSR-style response sequence -- to let clients detect terminal support.

[j4james]

It's worth noting the VT330 uses a form of OR mode in it's Sixel implementation (possibly XOR - I'm not certain of the details). So if I were going to implement something like this in a terminal, I would prefer an algorithm that was compatible with the VT330, as that way it could potentially also be used to support legacy VT330 apps.

But that requires that the mode can be enabled independently of the image format, e.g. with something like a DECSET sequence. Because an app designed to work on a VT330 wouldn't have set the P2 parameter to something special, so you can't rely on that to trigger the mode, but you could manually enable a DECSET mode before launching a VT330 app.

Another benefit of a DECSET mode is that modern applications could use a DECRQM query to determine if the mode was supported by the terminal before attempting to make use of it.

[saitoha]

I think DECSET has the downside that the application must restore terminal state itself.

[j4james]

I don't think that's a real issue. Any major TUI application is going to be restoring modes that would be far more critical than this (e.g. mouse modes, keyboard modes, alt screen mode). And if it was really a concern, you could always incorporate the mode settings along with your image sequence so you don't have to worry about it later, e.g. something like this:

"\033[?…h\033Pq…\033\\\033[?…l"

That said, I think the bigger challenge would getting this mode compatible with the algorithm that DEC used, so I doubt my implementation would end up being interoperable with this anyway. So feel free to ignore the mode suggestion - it was just an idea.

[saitoha]

@j4james It may not be a practical problem, and there’s precedent: chafa’s sixel output prepends CSI ? 25 l to hide the cursor.

That said, I have concerns: a sixel stream is a large control sequence, and if output is interrupted by SIGINT, the application must handle the signal and restore the terminal state itself.

Another issue is that inserting any sequence before DCS makes it harder for tools to recognize the data as sixel; for example, img2sixel only treats input as sixel when the file begins with DCS.

[j4james]

a sixel stream is a large control sequence, and if output is interrupted by SIGINT, the application must handle the signal and restore the terminal state itself.

I still don't think this is a big problem. Even if the terminal is left with the mode enabled, you probably wouldn't notice. I expect most Sixel images don't overwrite pixels in a way that would be affected by this mode.

Another issue is that inserting any sequence before DCS makes it harder for tools to recognize the data as sixel

I assume in this scenario that the app would have explicitly requested the OR encoding when calling img2sixel, so it should know the response could start with that prefix. And if you weren't expecting that encoding, you wouldn't be able to process the data meaningfully anyway.

But as I said before, I don't think this is going to be interoperable with the DEC format anyway, so it doesn't matter to me how you decide to enable it. I only really cared when I thought there was a chance it might be compatible.