トーンを縮小するとどう見えるか|編集部検証企画
公開日
自作の網点トーンを同じ端末で三段に縮小し、平均輝度と構造の残り方を実測しました。原因の切り分けは扱わず、再現できる条件と数字だけを載せます。
潰れたのか元からなのか分からない
縮小した原稿のトーンを見て、潰れたのか元からそう見えるのかが決まらないことがあります。
見る目の問題とは限りません。同じ素材を倍率だけ変えて書き出し、数字で並べた記録が無いからです。
CMT-B-0349 との線引き
ここで出すのは、再現できる比較データです。 原因を切り分ける手順ではありません。
同じ網点を倍率だけ変えて測り、条件を全部書き残します。 読んだ人が同じ形で測り直せることを目的にしました。
どの原因でモアレが出たか、という判定はしません。 そこは手順側の記事の範囲です。
二つの量を測った理由
数えたのは平均輝度と構造の二つです。片方だけでは、縮小で何が起きたかが分かりません。
平均輝度は、全体としてどれだけ暗いかを表します。濃さが変わったかどうかは、ここを見ます。
構造は、明暗がどれだけ細かく切り替わっているかを表します。網点の粒が残っているかどうかは、ここを見ます。
| 量 | 何が分かるか | 分からないこと |
|---|---|---|
| 平均輝度 | 濃さの変化 | 粒が残ったか |
| 切替回数 | 粒の細かさ | 濃くなったか |
| 輝度の段数 | 階調の幅 | 見た目の印象 |
濃さが変わらないまま、粒だけ消えることがあります。 そのとき平均輝度だけを見ていると「何も起きていない」と読んでしまいます。
逆に、粒が残っていても濃さが動くことがあります。 だから二つを別の欄に置きました。
揃えた条件
検証日は 2026年9月28日 です。
書き出しは Chrome のスクリーンショット(PNG)で、dpr は 2 に固定しました。 使ったのは Google Chrome 153 の headless で、走らせた機械は Mac15,5(Apple M3)、OS は macOS 26.6.2 の一台です。
素材はこの検証のために作った自作の網点三枚(原寸 240×160)です。 網点のピッチだけを 4px / 6px / 8px と変え、点の面積比は同じ設計にしました。
枠線を数えないよう、実測した矩形から 3 device px 内側だけを測りました。 輝度 128 より暗い画素を黒として数えています。
内側 3px を除いた理由
小さいことのようですが、ここを決めないと数字が動きます。
枠線は網点ではありません。 端まで数えると、枠の暗い画素が平均輝度を押し下げ、切替回数も増やします。
倍率を変えると、枠の太さの比率が変わります。 枠を含めたまま倍率を比べると、網点の変化と枠の変化が混ざります。
だから内側だけを測りました。 除く幅を一つに決めておけば、どの倍率でも同じ条件になります。
この幅は今回の素材に合わせた値です。 枠の無い素材なら要りません。除いたかどうかと、除いた幅を書いておくことが要点です。
網点は三種類
| ピッチ | 点の間隔 |
|---|---|
| 4px | 狭い |
| 6px | 中間 |
| 8px | 広い |
変えたのはピッチだけです。 濃さの設計は揃えてあります。
倍率は 1.0 / 0.75 / 0.5 の三段です。 素材そのものは書き換えていません。
出てきた数字
| 倍率0.5 | 輝度の段数 |
|---|---|
| 4px | 11 |
| 6px | 5 |
| 8px | 8 |
平均輝度は、九通りすべてで 190 から 197 の間に収まりました。 この条件では、倍率を下げても大きく濃くはなりませんでした。
行あたりの白黒の切替回数は、4px では 60.4 → 59.7 → 59.0 とほぼ変わりませんでした。 8px では 30.2 → 35.4 → 29.7、6px では 40.3 → 35.8 → 52.0 でした。
輝度の段数は 0.75 倍で最も多く、6px で 27、8px で 29 まで増えました。 0.5 倍では 6px が 5 段まで落ちました。
平均輝度が動かなかったことの意味
九通りすべてが 190〜197 に収まった、という結果はそれ自体が一つの観測です。読み方を書いておきます。
言えること。 この条件では、倍率を下げても全体の濃さはほとんど動かなかった。
言えないこと。 見た目が変わらなかった、とは言えません。同じ平均輝度でも、切替回数と段数は動いています。濃さが同じでも、粒の見え方は別です。
言えないこと。 他の網点でも同じか。測ったのは三種類だけです。
単調に減らなかった所
6px を 0.5 倍にしたとき、切替回数は 40.3から52.0 へ増えました。 倍率を下げたのに増えています。
この値は書き換えていません。 期待と違う向きに動いたことも、観測の一部として残します。
理由の断定もしません。 今回測ったのは数字で、機序の特定は範囲外です。
期待と違う値が出たときの扱い
上の 6px の行のような値は、検証でいちばん扱いを間違えやすいところです。手順を決めておきます。
- 測り直す。 同じ条件でもう一度取り、同じ値が出るかを見ます。
- 同じなら、そのまま残す。 向きが揃わないことを理由に消しません。
- 条件を読み直す。 値ではなく、条件のほうに書き落としが無いかを見ます。
- 理由を書かない。 機序を確かめていないので、推測を添えません。
- 測っていない点を足さない。 間を埋めると、測った値と区別が付かなくなります。
「外れ値だから除く」という処理をしません。 三段しか測っていないので、外れかどうかを判定する材料がありません。
残した値は、次に測る人の手がかりになります。 消すと、同じところで同じ迷いが起きます。
値が読めないとき
手が止まる場面を、三つ挙げます。 どれも書き出しの話です。
どの例でも数字を直していません。条件のほうを足しています。
並べたあとの確認
書き出し条件を書いたか。 ソフトと倍率が無いと再現できません。
数えた量の名前を書いたか。 輝度と構造は別の量です。
期待に合わせて直していないか。 向きが揃わない値も残します。
除いた範囲を書いたか。 枠を含めるかどうかで数字が動きます。
平均だけで結論していないか。 構造の欄も一緒に見ます。
自分のトーンを一枚縮める
検証に、全部の網点は要りません。自分のトーンを一枚選び、倍率を一段だけ下げて書き出し、同じ場所を数えてみること。
ソフトと倍率は書いたか。数えた量の名前を書けたか。 そこまで残れば、次のピッチも同じ形で並びます。
値が揃わなくても構いません。 揃えないまま残すことが再現できるデータになります。