第74話で書き出した透明PNGのあが、18台の案内板に並んだ。
文字は、どれも正しく読める。
ところが表示機がday modeからnight modeへ切り替わった瞬間、イトは右上を指さした。
あから離れた場所に、青い四角が一つだけ浮いている。
day modeの明るい背景では、ほとんど気にならなかった。
濃紺の背景へ重なると、小さな光の傷に見える。
イトは白いpaint toolを選んだ。
「ここを背景と同じ白で塗れば、day modeでは消えるよね」
次のtheme syncでは、同じ画像が明るい案内板と暗い案内板の両方へ固定される。
片方だけで隠して流せば、もう片方の18台には四角が残る。
白いpixelは、透明なpixelではない
ユイはpaint toolを止めず、二つのpreviewを横へ並べた。
白で塗った試作を明るい背景へ重ねる。
青い四角は見えなくなった。
同じ試作を濃紺の背景へ重ねる。
今度は白い四角が、はっきり残った。
イト
色を背景に合わせただけだから、背景が変わると隠せないんだ
ユイ
白という色があるpixelと、下の背景を通すpixelは別ですね
マコト
見えている一マスを、位置と色と透明度に分けて調べよう
Picoはpaint toolにもsource gridにも触れない。
青い四角へcrosshairの光を置き、選択をイトへ返した。
三つの直し方
A：青い四角を白で塗る
明るい背景では隠せる。
けれど透明にはならず、暗い背景で白い四角が現れる。
B：画像全体を小さくして、四角を目立たなくする
問題の一マスだけでなく、あの輪郭まで変わる。
一度失った細部を、pixel数という数字だけで取り戻すこともできない。
C：問題のpixelを特定し、alphaを直して再exportする
sourceのcopyを開く。
問題のcoordinateとRGBA channelを確認し、色で覆わず透明度を直す。新しいPNGを一件書き出し、light / dark両方へ重ねてからsyncする。
イトはwhite paintの試作をdiscard trayへ入れた。
「C。背景の色を当てるんじゃなくて、この一マスが背景を通すようにする」
pixelは、画像の中の住所を持つ
今回のsourceは、32×32 pixelの小さなraster imageだ。
width 32 pixels
height 32 pixels
total 32 x 32 = 1024 pixel positionsraster imageでは、縦横のgridにpixelが並ぶ。
このlabのeditorは左上を(0, 0)とし、右へ行くほどx、下へ行くほどyが増える。
青い四角のcoordinateは(26, 7)だった。
coordinateの数え方はtoolや規則で変わり得る。だから「右上のあたり」ではなく、今使うeditorの原点とx / yを一緒に確認する。
pixelは、画面上で必ず同じ物理サイズになる点ではない。
32×32の画像を大きく表示すれば、一つのpixel位置が大きな四角として見える。小さく表示すれば、隣のpixelとまとまって見える。
ここでいうresolutionは、まず画像が持つpixel位置の数だ。
pixel数が多いだけで、ぼけたsourceに存在しなかった細部が自動で戻るわけではない。
一pixelの中に、四つのsampleがあった
このPNGは、8-bitのtruecolor with alphaというclosed fixtureだ。
一つのpixelに、四つのsampleが順にある。
R red
G green
B blue
A alphaR / G / Bは色の三channel。
Aは、そのpixelがどれだけ背景を隠すかを表すalpha channelだ。
この8-bit alphaでは、0がfully transparent、255がfully opaque。間の値なら、背景と混ざる度合いが残る。
すべての画像がRGBAで保存されるわけではない。
PNGにもgreyscale、indexed-color、alphaなしなど別のtypeがある。ここでは、前話の透明PNGを調べるためにRGBAの一件だけを見る。
イトが第四sampleだけを下げた
イトはsource PNGそのものを上書きせず、versionを付けたcopyをpixel editorへ開いた。
coordinate (26, 7)を選ぶ。
四channelの値が現れた。
before R 32 G 150 B 230 A 255
target R 32 G 150 B 230 A 0色の三sampleは、青いまま固定する。
イトは第四のalpha sliderだけを、255から0へ自分の手で下げた。
32×32のsource gridをcompareする。
changed pixel positions 1 / 1024
changed source samples alpha at (26, 7)
other RGBA samples unchangededitor上で一sampleだけを直しても、圧縮して作り直したPNG fileのbyte位置まで一か所だけ変わるとは限らない。
だから完成fileは「何byte目が変わったか」ではなく、decoderで戻したpixel gridと表示結果で確認する。
イトはnew versionをPNG exporterへ送り、一件だけ書き出した。
二つの背景で、同じ一件を確かめた
最初に、明るい案内板へ重ねる。
青い四角はない。
次に、同じoutputを濃紺の案内板へ重ねる。
白い四角も、青い四角もない。
あの輪郭はbeforeと同じ位置に残っている。
light background test pass
dark background test pass
unexpected opaque pixel 0
glyph pixels changed 0
source original kept yesイトは二つのpreviewを自分の目で見比べ、そこで初めてtheme syncを再開した。
18台の背景が明暗を切り替える。
どちらでも、あの外に四角は現れなかった。
RGBをゼロにするだけでも、白にするだけでもない
今回の問題は、青のsampleが大きかったことだけではない。
alphaが255で、そのpixelが背景を完全に隠していたことだ。
R / G / Bをすべて0へ変えてalphaを255のままにすれば、透明ではなく黒いpixelになる。
すべて255なら、白いpixelになる。
このfixtureで透明にしたいなら、alphaを0へ戻す。
ただし実際の縁のにじみには、半透明pixel、色空間、premultiplied alpha、拡大縮小など別の条件も関わる。見える四角を見つけるたび、いつもalphaだけ直せばよいとは限らない。
最初の一手は、背景色を塗ることではない。
1. どの背景で見えるかを再現する
2. coordinateを特定する
3. colorとalphaを分けて読む
4. source copyを限定修正する
5. 複数背景で一件testする四角の列が、時間の目盛りへ変わった
night modeの18台が静かに消灯すると、検査台から短い音が鳴った。
ピッ。
一度きりの音に聞こえたのに、隣のmonitorには、細かな時刻ごとの点が横へ並んでいる。
イトは画像のgridを振り返った。
画像では、位置をxとyで選び、一pixelのsampleを直した。
monitorの点には、横方向の位置しかない。
その代わり、点は左から右へ次々に増えていく。
「音では、四角の住所が時間になるの？」
白で隠すのをやめたから、一pixelの中に色と透明度が別々にあると分かった。
次にイトが分けるのは、連続して聞こえる音と、時刻ごとに残す数値だった。
次回、ピコルート第76話。
音の波は、どこでsampleになる？