HDRScope

macOS 26以降 / Apple Silicon専用の、HDRウィンドウキャプチャ・表示・RGB測定ツールです。外部ライブラリやネットワーク通信は使いません。

ビルド済みバイナリは配布していません。各自でビルドしてください。

公証（notarization）を受けていないため、ビルド済みの .app を配布してもダウンロード先ではGatekeeperに拒否されます。また画面収録の許可は署名証明書に紐づくので、自分の環境で署名鍵を作る方が確実です。

必要なもの:

• macOS 26以降、Apple Silicon
• Xcode Command Line Tools（macOS 26 SDK）

git clone https://github.com/okaz-code/HDRScope.git
cd HDRScope
./Tools/setup-signing-identity.sh   # 初回のみ。ローカル署名鍵を作ります
./Tools/install.sh                  # ビルドして /Applications へ配置

setup-signing-identity.sh はログインキーチェーンに自己署名のコード署名証明書を作ります。理由は「画面収録の許可と署名」を読んでください。作らなくてもビルドは通りますが、再ビルドのたびに画面収録の許可をやり直すことになります。

バンドルIDは local.okaz.HDRScope です。フォークして使う場合は Info.plist の CFBundleIdentifier と各スクリプトの bundle_id を変えてください。

/Applications/HDRScope.app を開きます。./build.sh だけを実行した場合は dist/HDRScope.app です。

初回は「システム設定 → プライバシーとセキュリティ → 画面とシステムオーディオの収録」でHDRScopeを許可してください。権限エラーの「設定を開く」から開けます。設定後はHDRScopeを終了して再起動します。

TCCは画面収録の許可を、アプリの指定要件（designated requirement）に結び付けて記録します。アドホック署名（codesign -s -）では指定要件が実行ファイルのcdhashそのものになるため、ソースを1行変えて再ビルドしただけで別アプリと判定され、許可が無効になります。このとき、システム設定のスイッチは前回のままONに見えるのに、SCShareableContent は SCStreamErrorDomain code=-3801（ユーザが拒否）で失敗し、ウィンドウ一覧が空になります。許可ダイアログが毎回出るのも同じ理由です。

安定した自己署名証明書で署名すると、指定要件が「識別子 + 証明書」ベースになり、再ビルドしても許可が維持されます。最初に一度だけ実行してください。

cd HDRScope
./Tools/setup-signing-identity.sh
./build.sh
tccutil reset ScreenCapture local.okaz.HDRScope
open dist/HDRScope.app

ダイアログで許可した後、HDRScopeを終了して起動し直します。build.sh は署名鍵があれば自動的に使い、なければアドホック署名にフォールバックして警告を出します。フォールバック時は無効になった記録を tccutil reset で消し、設定画面にONのまま効かない項目が残らないようにします。

HDRSCOPE_SIGN_IDENTITY で別の署名IDを指定できます。

証明書の作成では、PKCS#12を旧来の PBE-SHA1-3DES + SHA-1 MAC で書き出します。OpenSSL 3系の既定（PBES2 / AES-256-CBC / SHA-256 MAC）はmacOSの SecKeychainItemImport が解釈できず、MAC verification failed during PKCS12 import (wrong password?) というパスワード違いに見えるエラーになるためです。パスワードは関係ありません。スクリプトは取り込み前にMACアルゴリズムを検査します。

署名も画面収録の許可もパスに依存しません。指定要件 identifier "local.okaz.HDRScope" and certificate leaf = H"…" にパスが含まれず、TCCはこの要件とバンドルIDで照合するためです。実測でも、別のパスへコピーしたバンドルが許可ダイアログなしで CGPreflightScreenCaptureAccess: 許可 になり、ウィンドウ一覧を取得できました。

ただし同じバンドルIDのコピーが複数残ると、システム設定のどの項目がどのコピーのものか判別できなくなります。配置には次を使ってください。ビルドしてアプリケーションフォルダへ入れ、dist/ のコピーとそのLaunchServices登録を取り除きます。

./Tools/install.sh
HDRSCOPE_INSTALL_DIR=~/Applications ./Tools/install.sh   # ユーザー領域へ入れる場合

配置後は ./build.sh を単独で実行しないでください。dist/ にコピーが再作成され、重複登録に戻ります。build.sh は配置済みのコピーを検出すると警告します。

check-permission.sh は /Applications → ~/Applications → dist/ の順に対象を探します。HDRSCOPE_APP で明示指定もできます。

なお spctl によるGatekeeper評価は「rejected」になりますが、これは公証（notarization）がないためで、署名の有効性とは別です。ローカルでビルドしたバンドルにはquarantine属性が付かないため、Gatekeeperの初回起動チェックは適用されません。

Resources/AppIcon.icns をバンドルに入れ、Info.plist の CFBundleIconFile で参照します。build.sh は .icns がなければ自動生成します。

図案はCoreGraphicsで描画しており、画像素材や外部ツールに依存しません。暗い角丸背景（Appleのグリッドに合わせて余白9%、連続曲率に近い超楕円）に、加算合成したR/G/Bのにじみ、その上に白い測定用レティクル。中央のセルはアプリ内の測定枠と同じ「黒の太線＋白の細線」で描いています。64px未満では細い線が消えるため、リングだけの簡略版になります。

./Tools/make-icon.sh        # 図案を変えたら Tools/make-icon.swift を編集して実行

配置済みのアイコンがFinderで古いまま表示される場合は、touch /Applications/HDRScope.app を実行してください。

./Tools/check-permission.sh          # 現状を表示
./Tools/check-permission.sh --request # 未確定なら許可ダイアログを出す
./Tools/check-permission.sh --reset   # 記録を消してから診断

バンドルパス、バンドルID、cdhash、署名種別、指定要件、CGPreflightScreenCaptureAccess、SCShareableContent の結果とウィンドウ一覧を出力します。

診断は必ず open 経由でアプリを起動して行ってください。dist/HDRScope.app/Contents/MacOS/HDRScope をシェルから直接実行すると、TCCは呼び出し元のターミナルを責任プロセスとして扱うため、許可の状態がアプリ本体のものと一致しません。直接実行した場合は診断結果にその旨を表示します。

同じバンドルIDのコピーが複数の場所にあると、システム設定にどれが登録されているのか分からなくなります。使わないコピーは削除してください。

1. 「開く…」（⌘O）で保存済みの画像を読み込んで測定できます。ウィンドウへのドラッグ&ドロップ、Finderからの「このアプリケーションで開く」も同じ動作です。
2. 左側の更新ボタンで現在のウィンドウ一覧を取得します。一覧はアプリごとにまとめ、検索欄でアプリ名・タイトル・IDを絞り込めます。
3. アプリ名・タイトル・サイズ・IDを確認して選択し、「キャプチャ」を押します。
4. 「再キャプチャ」は最後に正常取得したウィンドウを再取得します。一覧で別の項目を選んでも再取得対象は変わりません。ウィンドウID・PID・プロセス起動日時を再確認します。失敗時は最後の画像を保持します。
5. ホイールまたはトラックパッドのピンチで、ポインタ位置を中心にズームします。左ボタンドラッグで移動します。キーボードは不要です。
6. 「全体表示」でフィット、「1:1」で画像1画素をディスプレイの物理1画素に表示します。Retinaの論理ポイントとは異なります。
7. カーソル位置のRGB・アルファ・画像座標・測定範囲を下部に表示します。
8. 画像上で左クリックすると、その2行をそのままクリップボードへコピーします。ドラッグは移動のままで、3ポイント未満の移動だけをクリックとして扱います。メニューの「コピー」（⌘C）も同じ内容をコピーします。範囲外では何もコピーしません。
9. 「保存…」から形式を選びます。測定用は32bit float TIFF、macOSのプレビューでHDRを見たいならPQ HEICです。表示倍率や表示位置は保存内容に影響しません。
10. 左下の「テストパターン ×30」「ヘッドルーム階調」で、キャプチャなしの既知値パターンを表示できます（「テストパターン」を参照）。

再キャプチャでは現在の倍率・表示原点を保ちます。全体表示モードの場合はサイズ変更時に再フィットします。

Canonicalは共通ディスプレイ基準、Localはキャプチャ元ディスプレイ基準です。選択は次のキャプチャに適用されます。

• 色空間：拡張リニアsRGB（Rec.709原色・D65白色点）。ガンマ符号化されたsRGB値ではありません。
• (1, 1, 1) がSDR基準白です。絶対輝度のnit値ではありません。
• RGBの1超え、負値を内部処理・測定・保存でクリップしません。RGBは非乗算（straight）アルファ、Aは別表示です。
• 座標原点は画像の左上、xは右方向、yは下方向です。
• 100%以上ではポインタが位置する元画像1画素を読みます。
• 100%未満では、ポインタが位置するディスプレイの物理1画素セルを元画像に逆投影し、各画素との重なり面積を重みにして平均します。境界では画像内の有効面積で正規化します。
• 平均はリニアRGBを用います。アルファによる重み付けは行いません。表示背景の市松模様や測定枠は測定・保存に混入しません。
• 縮小表示自体も同じ面積平均をGPUで計算し、拡大表示は最近傍で画素を区別します。
• ピッカーは保存用float32データをdouble精度で集計します。画面から色を読み取っているのではありません。

測定値に負のRGBが出ることがあります。異常ではありません。原因は主に2つで、見分け方が異なります。

測定値はRec.709原色を基準にした座標系です。キャプチャ元がDisplay P3やRec.2020の色を出していると、その色はsRGBの三角形の外側にあり、sRGB原色の足し算だけでは表現できません。負の係数が必要になります。原色を変換した実際の値です。

拡張sRGBは、この色域外を表すために負値と1超えを許すよう定義された色空間です。負値はデータの破損ではなく、より鮮やかな色であるという情報そのものです。クリップすると彩度の情報が失われ、元の色に戻せなくなるため、このツールはクリップしません。

1を超える値は、色域外か、SDR基準白より明るいHDR輝度か、その両方です。

Core Imageは乗算済みアルファで返すため、非乗算（straight）へ戻しています。アルファが極端に小さい画素では、この除算が微小な誤差を大きく増幅します。乗算済みで−0.0001だった値は、A = 0.002なら−0.05になります。

該当するのはウィンドウの角の丸みや影の縁です。Aが1.0から大きく外れているときは、RGBの絶対値をそのまま信用しないでください。A = 1.0000の領域ではこの経路を通りません。

• Aがほぼ1で、負値が−0.3〜0程度 — 色域外の色。正常な測定値です。
• Aが0に近く、負値が大きい — アルファ逆乗算による増幅。参考値として扱ってください。

面積加重平均は重みがすべて非負なので、平均処理が負値を作り出すことはありません。平均が負なら、元画素に負値があります。

ScreenCaptureKitのHDR静止画プリセットで取得し、OSが返した元のCGImageと色空間を保持します。Core Imageが入力プロファイルを解釈して拡張リニアsRGB / RGBA float32へ変換します。非線形の拡張sRGBをリニアとしてラベル変更することはありません。

描画はRGBA float32テクスチャ → Metal → RGBA float16のEDR描画面です。描画面の精度やディスプレイ上限は保存・測定データに影響しません。固定SDRトーンマップは行いません。

右下に「表示EDR 現在値 / 上限」を出します。現在値は maximumExtendedDynamicRangeColorComponentValue、上限は maximumPotentialExtendedDynamicRangeColorComponentValue です。**現在値はパネルの固定的な性能ではありません。**SDR輝度設定・周囲光・発熱・電源状態で動き、EDRを要求する内容が画面に出ていないときは 1.00× まで落ちます。値は1秒ごとに更新します。

現在値が 14.05× なら、14倍程度までは階調として区別でき、それを超える値は頭打ちになります。現在値が 1.00× でも、上限が1を超えていれば「今はSDR表示なだけ」で、1を超えるRGB値はデータとして保持されています。

パネルのピーク輝度は固定なので、SDR白の輝度 × ヘッドルーム ≦ パネルのピークという関係になります。SDR白を明るくすると、その上に残る余地が減ります。ヘッドルームを動かす設定は次の3つです。いずれも「システム設定 → ディスプレイ」にあります。

**測定中に条件を固定したい場合は、輝度の自動調節とTrue ToneをどちらもOFFにしてください。**ONのままだと、部屋の明るさが変わっただけでヘッドルームが変わり、同じパターンの見え方が変わります。

ヘッドルームが潰れた状態でHDR画像を見ると、1.0を超える値がすべて同じ明るさへクリップされます。テストパターンなら階調の段が区別できなくなり、色は最大値へ張り付いてサチュレーションしたように見えます。**これは表示側の頭打ちで、データは変化していません。**ピッカーの値は正しいままです。

HDRを評価するときは輝度を下げてください。現在の画像の最大値がヘッドルームを超えている場合、右下の表示に「画像の最大 30.00× は表示しきれず頭打ちです」と出ます。右下の表示EDRは1秒ごとに更新するので、設定を触りながらヘッドルームの変化を追えます。

OSによるキャプチャ時の色変換・合成はアプリ外の処理です。キャプチャ元アプリの内部シェーダー値とキャプチャ結果が完全一致するとは限りません。

左下の2つのボタンで、キャプチャなしで表示上限を読み取れる既知値のパターンを出せます。どちらも白・赤・緑・青の4本の階調と、最下段の色域外・負値の帯（値は「負値と1超えの意味」の変換表と同じ）でできています。

**明るさが変わらなくなる段が、そのときの表示上限です。**ベタ塗りのパッチにしてあるのはこれを読み取るためです。

1360 × 780 px。列は左から 0 / 0.09 / 0.18 / 0.5、以降は1刻みで30まで（34段）。Windows版と同じ内容で、どのディスプレイでも同じファイルになります。

刻みが1.0固定なので、ヘッドルームは「整数倍で何倍まで見えるか」までしか分かりません。ヘッドルーム5.79のディスプレイでは34段のうち使えるのが6段だけ、という使い方になります。

いま表示しているディスプレイのヘッドルームに合わせて刻みを決め、全部の列を実際に見える範囲に使います。押した時点のヘッドルームで作るので、輝度設定・輝度の自動調節・True Toneの状態を変えたら押し直してください。

刻みは 1/16 / 1/8 / 1/4 / 1/2 / 1 のいずれかで、いずれも1.0を割り切ります。SDR白がかならず段のひとつに乗るので、基準として使えます。列数は最大34段に収まるうちで最も細かい刻みを選び、ヘッドルームの先に4段を足します。上限ちょうどで終わると頭打ちが「段が消える」形で見えないためです。

刻みの選び方・段数・上端はWindows版と同一のアルゴリズムで、この表の7ケースを自己テストで突き合わせています。

ヘッドルームが33を超えると、1刻みの34段でも届きません。そのときは階調が上限に届いていない旨をステータス行に出します（テストパターン ×30 を使ってください）。ヘッドルームが1.00×のときは1.00として作るので、SDR表示でどこからクリップされるかを見るのに使えます。

読み取りを狂わせる要因が2つあります。パネルの持続輝度制限により、面積の大きいパッチは小さいパッチほど明るくなりません。拡大表示してパッチを画面の一部だけに出すと影響が減ります。もう1つは表示設定で、輝度を上げすぎるとヘッドルームが潰れて全段がサチュレーションします。「輝度設定とヘッドルームの関係」を参照してください。

用途で使い分けます。1つの形式で測定と表示の両方は満たせません。

TIFF、非圧縮、RGBA各32bit IEEE float、straight alpha、上から下の行順、リニアsRGB ICCプロファイル埋め込み。TIFFタグのSampleFormatはIEEE float、ExtraSamplesはunassociated alphaです。

浮動小数点配列を直接書き込み、保存前にImageIOでfloat TIFFとして解釈できることを確認します。保存は原子的に行い、実ファイルを読み戻して生成データと完全一致することを確認します。SDR化・ガンマ再符号化・非可逆圧縮を行いません。

**macOSのプレビューはこのTIFFをSDRにクリップして表示します。**これは保存値がSDR化されたことを意味しません。ファイル内には1.0を超える値がそのまま入っています。32bit float TIFF対応の解析ソフトで開くか、HDRScope上で測ってください。ファイルサイズは概ね幅×高さ×16バイトです。Classic TIFFのため4GB以上は拒否します。

10bit HEIF、ITU-R BT.2100 PQ。macOSのプレビューがHDRとして描画する形式です。書き出し後に読み戻し、寸法とPQ色空間を確認してから配置します。書き出しに失敗しても既存のファイルを壊さないよう、同じディレクトリへ一時ファイルを作ってから差し替えます。

**値は量子化されるため測定には使わないでください。**PQは絶対輝度ベースで、量子化格子が高輝度側で粗くなります。実測では、同じ内容のベクトル画像でTIFFの最大13.88に対しPQ HEICは24.90になりました。中間の分位（2.0超1.63%、4.0超1.44%、p99≈10.2）はほぼ一致するので、HDRの実体は保持されますが、個々の画素値は動きます。

透明度を持つ画像では、TIFFのstraight alphaと同じ扱いにはなりません。アルファを含めて厳密に扱う必要がある場合はTIFFを使ってください。

TIFF / HEIC / HEIF / PNG / JPEG を開けます。ファイル自身の色空間からキャプチャと同じ拡張リニアsRGBへ変換するので、開いた画像もキャプチャと同じ条件で測れます。リニアsRGBのTIFFでも、BT.2100 PQのHEICでも、測定値の意味は変わりません。

読み込み後、ステータス行に寸法・ビット深度・元の色空間・最大RGB・1.0超の画素の割合を出します。「このファイルは本当にHDRなのか」を外部ツールなしで確認できます。キャプチャ直後も同じ情報を出します。

コマンドラインからも同じ読み取り経路を使えます。

/Applications/HDRScope.app/Contents/MacOS/HDRScope --inspect image.tiff

  2752 × 1972 px · 16bit float · ICC埋め込み
  RGB 最小 -0.0576 / 最大 13.8750 · 1.0超 2.150% · アルファ最大 1.0000

PQ HEICを読むときは注意点があります。アルファも10bitで量子化されるため最大値が 0.9990 のようになり、非乗算アルファへ戻す除算でRGBがわずかに持ち上がります。同じ内容のTIFFとHEICを読み比べると、最大値が 13.8750 と 24.9275 のように違って出ますが、これは量子化とアルファ復元の差です。測定にはTIFFを使ってください。

Xcode Command Line ToolsとmacOS 26 SDKが必要です。

cd HDRScope
./build.sh
./dist/HDRScope.app/Contents/MacOS/HDRScope --self-test --test-output test-results
python3 Tests/verify_tiff.py test-results/roundtrip.tiff

Core ImageテストはMetalへのアクセスを許可された通常のローカルプロセスで実行してください。GPUを遮断した実行サンドボックス内では正しい描画結果を取得できません。

テストパターンについては「テストパターン」を参照してください。アプリ起動時に --test-pattern（固定の×30）または --headroom-pattern（ディスプレイに合わせた階調）を渡すと、画面収録権限なしで表示・ピッカー・保存を確認できます。

• macOS 26.6.2 / Apple Silicon、Swift 6.2.3でビルド。
• 382アサーション成功：単一画素、面積平均、部分画素、画像境界、範囲外、上下方向、アルファ、非線形sRGBからの変換、SDR基準白、HDR値、負値、ImageIO経由のTIFF読み戻し。
• float32→CGImage→リニアfloat32のテストデータ最大誤差：0。
• Python標準ライブラリによる別実装で、TIFFタグ、ICC署名、行順、アルファ、保存された全チャンネルのfloat32ビット一致を確認。
• アプリ実画面でテストパターン、1:1表示、ホイールによる13.6%への縮小、64〜81画素の平均RGB=2.000000、ドラッグ移動を確認。
• 実画面でEDR上限1.00×と10.03×の表示状態を確認。物理輝度の測定器による検証は未実施。

• codesign -d -r- の指定要件が cdhash H"…" のみであることを確認。アドホック署名のため証明書ベースの要件が生成されていない。
• 連続ビルドでcdhashが 1490d497… → 82f8c576… → 3f7aae63… と毎回変化することを確認。TCCの記録は前のcdhashに紐づいたままになる。
• open 経由（親プロセス pid 1 launchd）で診断し、CGPreflightScreenCaptureAccess が未許可、SCShareableContent が SCStreamErrorDomain code=-3801（ユーザが拒否）で失敗することを確認。ウィンドウ一覧が空になるのはこのため。
• LaunchServicesに同一バンドルIDのコピーが2箇所登録されていることを確認：tool/HDRScope/dist と ~/Documents/Codex/2026-09-05/users-okaz-vecbeammame-workspace-tool/work/HDRScope/dist。システム設定でどちらの項目を操作しているのか判別できない原因になる。
• 対処として Tools/setup-signing-identity.sh（安定した自己署名証明書）と Tools/check-permission.sh / --diagnose を追加。build.sh は署名鍵を自動採用し、アドホックにフォールバックした場合は無効化された記録を消す。
• 証明書署名後の指定要件が identifier "local.okaz.HDRScope" and certificate leaf = H"cc97cdfc…" になることを確認。この状態で再ビルドしcdhashが変わっても CGPreflightScreenCaptureAccess が許可のままであることを確認。ウィンドウ一覧の取得も成功。
• 実ウィンドウのキャプチャ成功を確認。ウィンドウを持たないアプリのキャプチャは、エラーではなく完全に透明な画像が返る。既定の一覧から除外し、取得結果も検査して明示するようにした。
• TIFFがプレビューでSDRに見える件を調査。埋め込みICCプロファイルはHDRScopeとhdrshotでバイト単位一致（572B、cicpタグを含む、sha256一致）、CGColorSpaceUsesExtendedRangeも両方true。ビット深度・ExtraSamples・アルファの扱いを変えた4種を作って比較したが、いずれもプレビューではSDR表示だった。保存データ側の問題ではない。
• 同じウィンドウを両ツールで撮って比較。HDRScopeの保存分は最大6.8061 / 1.0超1.175%、hdrshotは最大6.8047 / 1.0超1.173%で一致（差はhalf floatの丸め）。HDRScopeの方が32bitで高精度。データの欠落はない。
• macOSのプレビューは、float TIFFをSDRにクリップして表示し、PQ HEICをHDR表示することを実機で確認。形式の違いであり、保存値の違いではない。この確認を受けてPQ HEIC書き出しを追加。
• ヘッドルーム階調の刻み・段数・上端をWindows版と同一アルゴリズムで実装し、7種類のヘッドルームについて両者が一致することを自己テストで検証。SDR白が段に乗ること、等間隔であること、上限に届かない場合の申告も検証。
• 輝度の自動調節とTrue Toneでもヘッドルーム調整が入ることをWindows版の調査と合わせて確認。測定時は両方OFFにする。
• macOSの輝度スライダーを上げるとカレントヘッドルームが減り、上げすぎると1.00×まで潰れることを実機で確認。この状態ではテストパターンの階調が区別できなくなりサチュレーションして見えるが、ピッカーの測定値は変わらない。表示側の頭打ちであることを右下に明示するようにした。
• プレビューでSDRに見えた同じfloat TIFF群をHDRScopeで開くと、いずれもHDR表示されることを実機で確認。ファイルの中身は最初からHDRであり、クリップはビューア側の挙動だったことが確定した。読み込み機能のダイアログ指定とドラッグ&ドロップも実機で確認。
• 読み込み経路を独立実装（Python / Core Image直叩き）と突き合わせて検証。TIFFは最大13.8750 / 1.0超2.150%で完全一致。HEICは最大24.9035→24.9275、1.0超2.637%→2.646%とわずかに差が出るが、これはPQのアルファが0.9990に量子化され、非乗算アルファへ戻す除算でRGBが持ち上がるため。
• PQ HEICの量子化を実測。同じベクトル画像でTIFF最大13.88に対しPQ HEIC最大24.90。ただし2.0超1.63%、4.0超1.44%、p99≈10.2は一致し、HDRの実体は保持される。
• クリックによるコピーは、4件のアサーションでコピー文字列＝表示2行であることを検証。クリックとドラッグの判別自体はGUI操作のため自動検証していない（osascriptに補助アクセス権限がなく自動クリックを実行できなかった）。
• OpenSSL 3系で作ったPKCS#12は security import が MAC verification failed（wrong password?） で拒否する。PBES2/AES-256・SHA-256 MACが未対応のため。旧形式（PBE-SHA1-3DES + SHA-1 MAC）での書き出しに変更し、使い捨てキーチェーンで取り込み成功を確認。

ScreenCaptureKitは、アプリが持つレイヤー0のサーフェスをすべて返します。この中には実際のウィンドウのほかに、ステータス項目・非表示のヘルパー・画面外の作業用サーフェスが多数含まれます。実測では全661個中、レイヤー0が222個、そのうち実ウィンドウは5個でした。残り214個は画面に出ておらず、210個はタイトルもありません。これらを選んでキャプチャしても、OSはエラーを返さず完全に透明な画像を返します。

そのため既定では、画面に出ていて、かつ40pt以上のウィンドウだけを一覧に出します。「非表示・小さなウィンドウも表示」をONにすると全件表示に戻ります。最小化中や別Spaceのウィンドウを選びたい場合はONにしてください。

キャプチャ結果は取得後に検査し、全画素が完全に透明だった場合と、全画素が同一の値だった場合は下部のステータスに明示します。エラーにはせず画像は表示するため、透明だったのか取得に失敗したのかを区別できます。

最小化・別Space・保護コンテンツ等はOSにより取得不可、黒画像、または更新されない画像になることがあります。一覧では非表示のウィンドウを明示します。タイトルのないウィンドウもIDで選択できます。閉じたウィンドウの代わりに同名の別ウィンドウを自動選択しません。

非常に大きい画像では、原画像・float32配列・GPUテクスチャ・保存用データのためにメモリを多く使用します。通常のデスクトップウィンドウの静止画利用を想定しています。

MIT License。LICENSE を参照してください。