search

kmiya-culti / RLogin

RLoginは、Windows上で動作するターミナルソフトです
http://nanno.bf1.jp/softlib/man/rlogin/
MIT License
464 stars 16 forks source link

Sixelの色情報を拡張2 #22

Closed kmiya-culti closed 5 years ago

kmiya-culti commented 6 years ago

Sixelの色情報を拡張する案

目的：Sixelで表現できる色数が端末の文字や背景などで表現出来る色数より少ない為に起こる背景色の不一致などを改善する為。

Pu=1 : HLS (Px=0-360;Py=0-100;Pz=0-100)
Pu=2 : RGB (Px=0-100;Py=0-100;Pz=0-100)

DECGCIにPu=3でR8G8B8の色空間を追加する。

Pu=3 : R8G8B8(Px=0-255;Py=0-255;Pz=0-255)

DECGCIに不透明度を指定するアルファ値(Pa)を追加する

Pu : 1=HLS(Pa=0-100). 2=RGB(Pa=0-100), 3=R8G8B8(Pa=0-255)
Px;Py;Pz;Pa : Paは、省略可能とし省略値は、最大値とし不透明とする。

※Pa=0の場合には、描画を行わないことで透明を解釈可能

Sixelに新コマンドRLGCIMAX(*Pu;Px;Py;Pz;Pa)を追加してDECGCIのPx;Py;Pz;Paパラメータの最大値を一時的に変更する

Pu : 1=HLS, 2=RGB, 3=R8G8B8(最大値を変更する色空間番号）
Px;Py;Pz;Pa : 各最大値(1-65535), 0の場合は、各色空間のデフォルト値(HLSの場合は、360;100;100;100)

※R10G10B10の場合は(*3;1023;1023;1023)で表現可能。実際の色数は、各端末に依存。
saitoha commented 5 years ago

@kmiya-culti フォーマットの形式に関しては改善されたと思うのですが、RLGCIMAXの最大値を自由に指定する考え方が、冗長過ぎるのでは、と感じます。

1-65535の範囲で自由に最大値を指定できるのは、前例として、PAM formatのmaxvalがありますが、 あまり有効に使用されている事例を見たことが無いので、妥当な仕様なのか疑問があります。

一方、この方式のメリットとしては、複数の深度のカラースペースを五月雨的に追加していくのに比べ、 「1回の拡張で済む」という点が挙げられると思います。 それを狙ったものでしょうか？

arakiken commented 5 years ago

長らく時間がとれず、議論についていけておらず、申し訳ありませんでした。

21 も含めて議論に全て目を通しました。

最初は、パレットを増やすならRGBを直接指定するなど新たな方法の導入も考えてみたところではありますが、適切に減色しつつ、パレット数が足りなければパレットを随時更新するのが結局一番無難そうですね(パレット随時更新する場合、行頭に戻る$だけでなく、画像の最初に戻るコマンドがあればもっとパレットの定義数が減らせるんですけどね。)。

一方、1パレットに指定できる色数の拡張は確かに必要だと思いますので、mlterm の hg head も、@kmiya-culti さんの拡張案及びオプション1に対応してみました(オプション1は今のところ、透過・不透過の2択になりますが)。パレット数は最大1024個です。

なお、RLGCIMAXについては、@saitohaさんと同じく私も少し冗長すぎるかなと思い、まだ対応していません。実装は簡単ですし、あってもよいとは思いますが、未対応のパーサの大半は(DECGCIのPuの定義を追加する場合と違って)読み飛ばすことができないであろうデメリットを補うほどのメリットがあるかどうかというところで、必要に応じてDECGCIのPuを増やしてカラースペースを拡張するという泥縄式でも(そんなに頻繁に拡張しないといけないものでもないと思うので)とりあえずいいのではないかなと思います。

kmiya-culti commented 5 years ago

オプション２については、たしかに冗長のような気がしましたがメリットも無いことは無いのでオプションで記述しました。

http://nanno.dip.jp/softlib/man/rlogin/sixel.tar.gzを更新してRGBのビット数指定-b[bits] とRGBA個別最大値指定-m[r,g,b,a]を実装してみました。どちらも同じオプション２を設定するオプションです。

オプション２があると細かな指定が可能になるので、悪くないと思いましたが、実験以上の効果は、疑問かもしれませんでした。案から削除の方向ですね。

オプション１については、どうでしょう？拡張案に組み込むかオプション扱いのままにするかくらいでしょうか・・・

arakiken commented 5 years ago

オプション１については、(今のところmltermでは透過か不透過かの2択でしか扱えませんが)拡張案に組み込んでいただいて支障ないと思います。

オプション2については、新規のコマンド形式を追加するのは抵抗がありますが、当初提案のあった#n;9;r;g;b;aのように、既存のコマンドのパラメータの解釈を追加するような形であれば、あってもいいんじゃないかとは思うんですけど、落としどころが難しいですね。