私の電子書籍リーダーがストライプを失った方法

私は生涯にわたる読書家であり、それは私たちの時代の終わりのない些細な気晴らしとの競争において、脆い習慣であることが証明されています。本や電子インクリーダーは注意を引くための競争の問題を解決しますが、利便性においてはスマートフォンに勝てません。私のポケットの中にあるその小さなデバイスは、通知がポップアップするたびに、読書をより簡単に、そしてより置き換えられやすくしました。 数日前、私は最近の小型電子インクリーダーの世代について初めて知りました。安価だったので、好奇心に負けてXteink X3を購入しました。それは驚くほど小さいだけでなく、すぐに素晴らしいオープンソースのCrossPointファームウェアをインストールできました。数冊の本をすぐにインストールできました。カスタムフォントをインストールできることも気に入りましたが、それらのレンダリングの無関心さには少し驚きました（前兆…）。 CrossPointは最初から非常に設定可能なので、写真をディザリングされた白黒ビットマップに変換して「デバイススリープ」画面にし、それがどれほどきれいに見えるかに満足しました。デバイスが4段階のグレースケールをサポートしていると読んだとき、私は興味をそそられました。グレースケール画像はより良く見えるでしょうか？ 穴に落ちていく：最初の画像バグ これはバグのように見えるものを明らかにしました。スリープ画面は、非常に不明瞭な暗い領域を持つグレースケール画像を表示していました。私の40代の目がついに衰えたのか、それとも暗いグレーが黒としてレンダリングされていたのか？クイックテスト画像を作成し、暗いグレーが実際に黒であり、明るいグレーが非常に薄い（ほぼ白）であることを確認しました。わずかに迷惑ですが、安価なデバイスではほとんど予想外であり、簡単に回避できました。3段階の画像を作成しましょう！ 再生成された画像の大部分が黒ではなくなったため、新しいバグが見つかりました。CrossPointビューアアプリでは、前の画面の内容が幽霊のような形で残っていました（表示の明るい部分にのみ、そのため最初に気づかなかった）。しかし、同じ画像でも、スリープ画面ではこの問題はありませんでした。これは、2つの画像レンダラーが異なる決定を下しており、ビューアアプリのコードにバグがあることを示唆していました。 しかし、どちらの場合も、写真にはビットマップファイルには存在しない特徴的な縦縞がありました。 私の3段階画像の電話写真。背景で最も見やすい細かい縦縞。 私は電子インク、ESP32開発、またはCrossPointについてほとんど何も知らなかったので、いつもの2026年後半の方法で、GPT-6 AstraをCodexで使用して調査を開始しました。X3の画面を携帯電話でキャプチャし、画像をCodexセッションにドロップしました。 電子インク画面は、電源が切れた後もその場にとどまる黒と白の顔料粒子を移動させるために電圧パルスを使用します。不完全な更新または不十分な電圧は、前の画像の幽霊のような痕跡を残す可能性があります。 グレースケール画像を表示するために、CrossPointはまず、グレーのピクセルでさえ黒から始まる白黒のベースを描画します。次に、選択されたピクセルを部分的に白に移動させる短い電圧パルス波形を実行します。この2番目のステージ、「ナッジ」は、それらのピクセルを異なる時間だけ駆動することにより、暗いおよび明るいグレーのシェードを生成します。 Astraは、ビューアが高速な白黒更新を実行し、グレーのナッジを実行せずに停止したことを発見しました。それはすぐに問題を修正しました。 縞模様ははるかにしぶといことが証明されました。Astraは当初、スリープ画像を準備するために使用したFloyd–Steinbergディザリングを非難して、的外れでした。異なるアルゴリズムは違いをもたらしませんでした。次に、スタックを下るリードに従い、ナッジ波形を調査する価値があるとしてフラグを立てました。 しかし、私たちは実際に見ている、または測定しているアーティファクトについて合意するのに苦労していました。これは私を心配させました。私は状態最先端のトークンを幽霊を追いかけるために燃やしたくありませんでした。私がプッシュしたとき、Astraは掘り下げて、2ピクセル幅のストライプパターンを報告しました。それは私には意味がなかったので、写真を注釈付けするように頼んだところ、私が目に見える帯ではなく、細かいディザテクスチャを拾い上げたことがわかりました。 AstraのFFTが見つけたもの ここで高速フーリエ変換（FFT）を使用したのは非常に賢明でした。それは、目で見つけるのが難しい繰り返しパターンを検出し、定量化するためのほぼ理想的なツールです。Astraは、写真の小さなパッチとソース画像に2次元FFTを適用し、両方で約2画面ピクセルの強い繰り返しを見つけました。 残念ながら、エラー拡散ディザリングはそれ自体で構造を生成します。その性質上、しばしば高周波ノイズがFFTで強い信号を作成します。Astraは、Floyd–Steinbergの細かいドットパターンを拾い上げていました。これは、調査の初期段階で非難した、画像を準備するために選択したまさにそのアルゴリズムでした。私が不満を言っていたより広い帯は、リーダー上でのみ現れました。私がその推定に異議を唱えたとき、それはこの注釈を作成し、私たちが異なるパターンを見ていることを確認しました。 Astraの2ピクセル推定の背後にある細かいディザテクスチャの注釈。 縞模様を測定可能にする# Astraの的外れな仮説に少し動揺して、別の視点を得るためにClaude CodeでFable 5.1に切り替えました。 縞模様の幅が何かを意味するという予感がありましたが、縞模様を特定することさえAstraにはできませんでした。そして、これは簡単ではありません。多くのソースがパターンとノイズを導入するためです。 画像自体のディザパターンがAstraを混乱させた 縞模様を導入していたもの X3画面自体の物理的特性 この混乱の携帯電話写真： センサーノイズ 画像内の焦点のばらつき レンズの歪み（259ppi画面をキャプチャするにはマクロショットである必要があります） 照明と露出の変動、処理アーティファクト 私の震える手からのモーションブラー Astraの単純な画像処理の行き止まりから警告され、Fableは各列の明るさを平均化するコードを書きました。以下のビューでは、200行の高さのスライディングウィンドウを使用しました。各点は、その周りの短い垂直ストリップの平均になりました。これにより、ディザテクスチャは平均化されましたが、列を下って持続する明るさの違いは残りました。写真の広い形状は残りましたが、縞模様ははるかに見やすくなりました。 スライディング垂直平均を適用した後のクロップ。広い形状は写真に属します。細かい垂直帯は欠陥です。 Fableは現在、1次元の明るさプロファイルにFFTを使用して、垂直パターンの間隔と強度を測定しました。最初の推定では、縞模様は約7画面ピクセル間隔でしたが、これは写真のスケールに関する私の推測に基づいています。 それはディザリングに注意を戻し、今回はファームウェア内で行いました。繰り返しの丸め誤差が並んで縦帯を生成する可能性があると提案しました。私のソース画像はすでにディザリングされていると述べたとき、それはより興奮しましたが、これは20分間の誤ったリードで終わりました。別の調査では、Fableが画像のビット深度について興奮しましたが、これもどこにも行きませんでした。少なくともAstraよりも革新的な調査でしたか？ グレーは何が違ったのか？ 私もデバイスでより単純な画像を調査していました。グレーまたはパターンを削除すると、縞模様が消えました。 画像 グレーのピクセルが存在する 異なる状態の隣接ピクセル 縞模様 均一なグレーフィールド はい いいえ なし 白黒ディザ いいえ はい なし グレーディザ（2つの方法のいずれかを使用） はい はい はい グレーのピクセルと異なるシェードの隣接ピクセルとの特定の組み合わせが問題を引き起こしていました。Fableはソース画像の小さなブロックを電話写真と一致させ、これにより、明るいグレーのピクセルが縞模様を運んでいることを最終的に認識できました。これは、明るいグレーのピクセルの非常に薄いトーンのために、私にとっても明確ではなかった重要な詳細でした。 この証拠は、画面がグレーをどのように生成するか、つまりグレーのナッジを介して生成するかを示していました。これを行うためのコードは、CrossPointが使用するハードウェアライブラリであるfreeink-sdkにあります。 Fableは当初、さらに進むことに消極的でした。「私はここからLUTの変更を設計または検証することはできません。」LUTは、ナッジ波形を保持するルックアップテーブルです。X3が私の机の上にあり、新しいビルドが表示するものを何でも写真に撮ることができると指摘すると、それは実験に戻ってきました。