gnuplotのrgbcolorでの色指定でハマりやすいところ(rgbcolorとlinecolor <n>)

今回はgnuplotの機能の解説ではなく、使っていてちょっとハマりやすい点を書いておきます。

rgbcolorで設定しているつもり

gnuplotでプロットの線or点の色をlinecolor、lcで設定するケース。ここでrgbcolorによる指定をしようと以下のコマンドを書いたとします。
gnuplot> plot x linecolor 0xff0000
本来ならここではプロットは赤い線(0xff0000)になるはずですが、プロット結果は以下のようになります。

赤い線となるはずが黒い線になってしまっています。色指定は0xff0000なので、これも赤色のはず。では何が間違いだったかというと、コマンドをよく見直してみると
linecolor 0xff0000
の色指定の部分に"rgbcolor"(もしくは"rgb")が入っていません。ちゃんとしたコマンドで書き直せば
gnuplot> plot x linecolor rgbcolor 0xff0000
となり、この出力結果は以下のように指定通り赤い線としてプロットされます。

linecolor <n>という書式

 さて、RGB値で色指定する場合の注意点は分かったわけですが、ではなぜ"rgbcolor"が無くてもプロットがエラーも無しに通ったのでしょう？
 これはgnuplotでは
linecolor <n>
という色指定も出来ることに関係しています。
 gnuplotではいくつかある基本の色を番号で指定することができます。"<n>"というのはその番号のことで、例えば以下のような指定となります。
gnuplot> plot x linecolor 1
ここでは以下のように紫色の線となります。

コンピューターは指定した通りにしか解釈しない

 RGB値である"0xff0000"は、実際にはこれだけでは単なる16進数の数値でしかありません。たとえ自分が「"0xff0000"は赤色だ」と思っていても、それはコンピューター側にはまったく関係がないこと。数値として渡されたのならあくまでも数値としてしか解釈されません。コンピューターに赤色を出力してもらいたいのなら、その数値は何を表している数値なのかもセットで指定する必要があります。"rgbcolor"が必要なのはそういうことのため。
 そして、 gnuplotの色番号は基本の数色のみですが、色数以上の番号を指定してもエラーは無くプロットされます。最後の色の番号まで行ったとして、そこから1つ番号が進むと最初の色に戻り、色割り当てが循環してずっと続いていきます。間違えたときに"0xff0000"が黒色になったのは、"0xff0000"の数値がたまたま基本の色の黒色の番号になっていたため。試しに"0xff0001"、"0xff0002"、"0xff0003"、"0xff0004"、... と1つずつ数を足した値でプロットしてやれば、そのRGB値が表す色とはかけ離れている色でプロットされることがわかるでしょう。
 そうやって何本か並べてプロットすれば以下のグラフのように基本色の循環になっているため、これはRGB値ではなく"linecolor <n>"という指定として解釈されていることが分かります。

というわけで、RGB値で指定する場合はちゃんと"rgbcolor"を指定しておかないと、このような思っているのとは異なる割り当てとなってしまうことになります。


gnuplot関連のブログ記事