Elanorya画像の確認
PNGに実際の透過ピクセルがあるかを確認する
ピクセルの探索は、アルファチャンネルを宣言しているPNGでのみ実行され、64x64ピクセルに縮小した複製を利用者自身の端末で読み取ります。ブラウザが画像をデコードできない場合の答えは「判断できない」であり、ファイルが不透明だという意味ではありません。
結果
確認する画像を選んでください。
この結果からは分からないこと
答えがどこで計算されるか
選んだファイルは `arrayBuffer()` でメモリに読み込まれ、ブラウザ内のキャンバスに描画されます。この面を構成する6つのファイル全体で、fetch、XMLHttpRequest、sendBeacon、WebSocketの呼び出しは1つもないため、これらのコンポーネントが答えを得るために画像をどこかへ送ることはありません（apps/web/components/tools/etsy-image-checker.tsx の `const buffer = await file.arrayBuffer();`、2026-08-18に確認）。
この記述が対象とするのはコンポーネント自身のコードだけで、それより広い範囲ではありません。それらを囲むページの外枠は別の面であり、このページで決着させられるものではありません。
ファイルの先頭バイトから形式そのものをどう判定しているかは別の仕組みで、ここでは導き出しません。ある写真をアプリがそもそも受け付けるかどうかは、アップロードが始まる前に端末上で決まります。これは受け付けるファイルについてのページが決着させています。
透過の確認が実際に見ているもの
透過についての答えが出るかどうか、そしてその答えがどんな形になるかは、3つの条件で決まります。
- PNGのみ、しかもアルファチャンネルが宣言されている場合のみ。
- ピクセルの探索は1つの関門の後ろにあります。apps/web/components/tools/etsy-image-checker.tsx の `if (facts.format === "png" && facts.alphaChannel) {` です。透過したWebPやGIFはここに到達しないため、それらの形式で透過について何も述べられないことは、否定の答えではありません。
- 原本ではなく、64x64の複製。
- 走査は縮小した標本、つまり同じコンポーネント内の `const sample = 64;` に対して実行されます。コストを低く保つために意図して選ばれた値です。複製を作る際にアルファが混ぜ合わされるため、原寸では数ピクセルある透過が標本には残らないことがあります。
- デコードできないことは、不透明ではなく未回答を意味します。
- アルファチャンネルが宣言されていて、ピクセルの結果が undefined のとき、結果は「判断できない」と述べる参考情報になります。apps/web/lib/image/evaluate.ts の `} else if (facts.alphaChannel && hasTransparentPixels === undefined) {` です。検証できなかったものが合格として報告されることはありません。
- 指摘は、読み取った標本についての記述です。
- 検証済みの指摘は、走査した範囲に透過ピクセルがあったことを伝えます。指摘がないことは、走査した範囲にはなかったことを伝えるだけで、ファイルが完全に不透明であるという主張よりも狭い記述です。
1つのファイルについて、2つのツールが2つの文を返す
サイズ変更ツールは、PNGがアルファチャンネルを持っていればその時点で元画像のカードに透過のラベルを表示します。apps/web/components/tools/product-image-resizer.tsx の `{facts.alphaChannel ? ` · ${labels.hasTransparency}` : ""}` です。読んでいるのはヘッダーで、そのことをすぐに述べます。
確認ツールは、ピクセルを読まないままその記述を行いません。そのため、同じファイルが一方では透過のラベルを生み、もう一方では透過の指摘なしになることがあります。どちらのツールも間違っていません。答えている問いが違うだけです。
両者を橋渡しする前提は短い一文です。完全に不透明なRGBAのPNGもアルファチャンネルを持っています。ラベルが意味するのはチャンネルの存在であって、画像のどこかが透けていることではありません。
結果を読み違える4つの形
いずれも、基になっている規則が支えていない読み方です。
サイズ変更ツールの透過のラベルを、目に見える透過だと読む。
これはヘッダー由来の事実です。不透明なRGBAのPNGでも同じラベルが出るため、それをもとに動く前に、ピクセルで検証された答えを待ってください。
「判断できない」を「透過はない」と読む。
その結果は参考情報であり、ピクセルが検証されなかったという意味です。ブラウザがデコードできる複製を用意して、もう一度確認してください。
指摘のない走査結果を、ファイルが完全に不透明である証拠だと読む。
走査は64x64の標本です。指摘がないことは不透明であることの証明にはなりません。「標本には現れなかった」と書き留め、答えが重要なら原寸のファイルを確認してください。
WebPやGIFで何も述べられないことを、透過についての判定だと読む。
これらの形式ではピクセルの探索が実行されません。どちらの方向にも、解釈できる判定は存在しません。
透過についての答えを記録する前に
答えを変える順に、5つの短い確認です。
- ファイルがPNGであることを確認する。他の形式ではピクセルの探索が実行されない。
- 見ている答えが、ヘッダーのラベルではなくピクセルから出たものかを確認する。
- 答えが「判断できない」なら、ファイルを不明として扱い、ブラウザがデコードできる複製で試す。
- 指摘がない場合は、ファイルが不透明だとではなく、64x64の標本には何も現れなかったと書き留める。
- 判定と掲載先を、2つの別々の判断として扱う。判定が説明しているのはファイルにすぎない。
このページが決着させないこと
いずれもこのページが書かれた面の外側にあり、それぞれの持ち主に委ねられています。
- マーケットプレイスが今日、透過したアップロードをどう扱うか。コードは自身が記録している規則の文面だけを適用しており、その文面が最新かどうかはここからは確認できません。
- ファイル形式が先頭バイトからどう判定され、どの署名が認識されるか。これは別の仕組みであり、専用のページに委ねられています。
- 出力ファイルの形式、圧縮、変換の挙動。これは別の場所で決まっており、ここでは読んでいません。
- これらのツールが依存する画像処理の機能を持たないブラウザで何が起きるか。その場合、コードは一般的なエラーを表示するだけです。
- これらのツールが英語以外の言語で存在するかどうか、またそこで各インターフェイスのラベルがどう表示されるか。
- プライバシーやデータ保護の遵守についての約束。観察されたのはもっと狭い事実です。これらのコンポーネント自身のコードにネットワーク呼び出しがない、ということだけです。
よくある質問
PNGの背景が透過しているかを確認するにはどうすればよいですか？
確認ツールにファイルを読ませてください。ピクセルの探索は、ヘッダーがアルファチャンネルを宣言しているPNGのときに実行され、64x64ピクセルに縮小した複製を利用者自身の端末で走査します（apps/web/components/tools/etsy-image-checker.tsx の `const sample = 64;`）。検証済みの指摘は、その標本に透過ピクセルがあったという意味です。
ファイルにアルファチャンネルはあるのに、透過している部分が見当たりません。どちらが正しいのですか？
どちらも正しく、述べていることが違います。完全に不透明なRGBAのPNGもアルファチャンネルを持つため、ヘッダーから導いたラベルが真でありながら、画像のどこも透けていないということがありえます。目に見える透過について語るのは、ピクセルで検証された答えだけです。
同じファイルについて2つのツールの言うことが食い違うのはなぜですか？
サイズ変更ツールはアルファチャンネルだけを見て透過のラベルを表示し、確認ツールはピクセルを検証しないまま透過があるとは述べません。2つの文は、同じファイルを異なる深さで説明しています。
この確認はファイルをアップロードしますか？
これらのコンポーネントは `arrayBuffer()` でファイルを読み、キャンバス上で処理します。この面の6つのファイルのいずれにも、fetch、XMLHttpRequest、sendBeacon、WebSocketの呼び出しは現れません。これはコンポーネント自身のコードについての記述で、それらを囲むページの外枠は別の面であり、ここでは決着していません。
結果が「判断できない」でした。これはどう扱えばよいですか？
ファイルを不明として扱ってください。アルファチャンネルは宣言されていたのにピクセルを検証できなかったため、結果は参考情報です。検証できなかったものが合格として報告されることはありません。ブラウザがデコードできる複製で再確認してください。