このツールについて
ディスプレイが本当に欲しがっている配列
ディスプレイのドライバは PNG を受け取りません。受け取るのは、そのコントローラが読む並びちょうどに置かれたバイト列で、その並び方はどれも誰かが決めるしかない項目です。1ピクセル1ビットか16ビットか。いちばん左のピクセルはビット7か、ビット0か。行を順に並べるのか、高さ8ピクセルのページに切るのか。赤は上位5ビットか下位5ビットか。ここに画像を落として形式を選べば、それに合わせてバイトが詰まります。mono、gray2、gray4、gray8、LVGL が使う alpha1 から alpha8 までのマスク、rgb565、rgb888、argb8888。設定の横に出るプレビューは元画像を縮めたものではなく、詰め終わった配列を読み戻したものなので、見えているものがそのままパネルに出ます。
1ピクセル1ビットを何に使うか
128x64 の OLED は 8,192 ピクセル、1つあたり1ビット。つまり絵の出来は、白と黒の境目をどこに置くかだけで決まります。線画やアイコンなら素直なしきい値が正解で、スライダーがその境目を動かします。写真なら誤差をばらまくほうがよく、Floyd–Steinberg は隣のピクセルへ拡散して新聞印刷のようなざらつきを、Bayer 4x4 の規則的な行列は小さいパネルで読みやすい網目を作ります。明るさとコントラストは境目より前、invert は後に効き、どれもドラッグしている最中にプレビューが描き直されます。アイコンが1ビットに耐えるかどうかは、出るサイズで見るしか判断のしようがないからです。
フレームバッファを画像に戻す
逆方向は誰も作っていない機能で、しかも手元にある本当の疑問——この配列で合っているのか——に答えるのはこちらです。C 配列を貼るか（0x のバイト、十進、\x エスケープ、裸の16進の塊、波かっこやコメントや #define 行があってもなくても構いません）、フラッシュから抜いた生の .bin を落とすと、画像として描かれます。あとは幅のスライダーを動かすだけ。幅が違うフレームバッファは斜めの縞にずれ、幅が合った瞬間に絵がぴたりと立ち上がります。素性の分からないダンプを特定する定番の手ですが、自分の出力の点検にもそのまま使えます。アイコンを変換し、その配列を貼り戻して、出てきた絵が自分のアイコンに見えるなら、ビット順も行の詰め物も合っています。読めなかったトークンは飲み込まれず位置つきで報告されるので、貼り付けた配列のタイプミス1つで失うのは値1つ、残り全部ではありません。
テンプレートとバイト順、そして必ず引っかかるやつ
同じバイト列でも、何にコンパイルさせるかで包み方が変わります。素の static const uint8_t 配列、_WIDTH と _HEIGHT のマクロが付いた Adafruit GFX の PROGMEM 配列、#define で寸法を書く u8g2 の XBM、LVGL v8 の lv_img_dsc_t と v9 の lv_image_dsc_t、TFT_eSPI の pushImage() に渡す uint16_t 配列、そして framebuf のコンストラクタを隣に書いた MicroPython の bytes リテラル。引っかかるのは TFT_eSPI です。16ビットのピクセルを上位バイトから読むので、このテンプレートのときだけ RGB565 をビッグエンディアンで詰める必要があり、他のテンプレートはすべてリトルです。ここではテンプレートを選べばバイト順がそれに従います。きれいにコンパイルできて色だけ違う配列は、誰も見つけたくないたぐいのバグだからです。全部このタブの Web Worker で動きます。アップロードなし、アカウントなし、まだ発表していない製品のアートワークは手元から出ません。