スクリーンショットのカラーマネジメント


#1

スクリーンショットってややこしいトコありますよね……。


#2

macOSでShift+Command+3スクリーンショットを撮ると、モニタのプロファイルがついた画像が作成されます。

仕様としては「そうだよね」と思うのですが、これをどう扱うべきなのか、どう考えればよいのか、共有されていないような気がしません?

  • カラー値がどう扱われているのか(スルーなのか、変換しているのか)
    • メニュー、Dock、ウィンドウのフレーム、UI部品、デスクトップピクチャなどOSが受け持つ部分
    • アプリケーションが独自に描画する、OS標準ではないUI部品
    • アプリケーションが独自に描画する、コンテンツを表示する領域
  • 利用シーンによる扱い方
    • 操作の解説などのために、図版として全画面やUI要素のスクリーンショットを撮る
    • 入稿データの確認用に、見えている画面のスクリーンショットを添える
    • Webサイトを紹介するなど、コンテンツそのものを利用する目的で画像化のために撮る
    • 死にかけてるアプリケーションのスクリーンショット撮って保全する

スクリーンショットをPhotoshopで開いた時、Twitterに投稿する時、プロファイルがどう扱われ、どう扱えばいいのか。細かい話のようですが、こういうの整理しておかないとマズくないですかね……。

さしあたりmacOSの話をしてますが、Windowsの方の事情もどうでしょうか?


関係ないですが、<kbd>Shift</kbd>って書くとShiftになるの、格好良いですよね……


#3

テスト
(※Kindle for Macのスクリーンショット)

ここはプロファイルが削除されるのですね…


#4

Macの場合キャプチャがスルーで来ることはなさげで、必ずモニタプロファイル付いてるのはそのまま信じてよさそうです。

ただ非常にうざったいんですよね、モニタプロファイル付いてくるの。デュアルならそれぞれのプロファイルが付いてくるので、広色域モニタでキャプチャするとこういう所に上げれば全部くすみます。
あと、プロファイル付いてるからといってブラウザ等で期待通りにカラーアピアランス固定で表示されるとは限らない……ってのがひとつ。
明るいUIカラーにしたAdobeのパネルのキャプなんか特に色ずれが目立ちます。

問題になりそうなのが、複数著者入れたAdobeアプリ本。のキャプチャ。
書籍の場合、ダークUIは非常に見づらくなるため、一番明るくしたUIカラーでキャプります。
著者によってひとつの本の中で色がびみょーに異なったりする、同一著者でもキャプの色味が、ということが起きるですね。

(もっとも、Retinaかそうでないか、の違いの方がかなり目立つんですが)

撮ったらconvert -profileでsRGBに変換しちまった方がよさそうです。Macの場合。Winはどうだろ。


#5

必ずプロファイルがついてくる、ということで起きうる問題として、カラマネしてない(モニタプロファイルを測色機で作成していない)環境由来の自動生成モニタプロファイルが指定されている場合、というのがありますよね。一応、各モニタの特性は拾ってきているものの、固定の標準値のみなので、設定を切り替えていればそれだけで違ってしまうという。

Adobeアプリの本を書くような著者がモニタキャリブレーションしていないハズがない……などと思い込みで運用すれば事故るので、著者全員がカラーマネジメントされた環境で運用されていることを申し合わせた上で、sRGBに変換して運用するなどルール整備することが望ましい、ということになるでしょうか。

もう一つの方法として、スクリーンショット作成時にモニタプロファイルをsRGBに指定する、という運用も可能かなと思います。広色域モニタ使ってるとすごいヘンな色に表示されるのでツライですが、コンテンツ領域も含め、カラー値の統一を図ることができるというメリットがあるのではないかと思います。


自動生成:モニタのEDIDから得られる応答曲線のガンマ値、RGB各色の色度座標、白色点の色度座標を用いて、カラープロファイルを自動生成する機能のこと。詳しくは @yamma_ma さんのやんま まのブログの記事 モニタの(カラマネ的)プラグ&プレイを参照されたし。


#6

(まだ中身までいじれてないのよね……Docker配布モノになれてないのもあるんだけど……)


#7

Windowsの場合(少なくともGDIの層では)デスクトップ全体がひとつのデバイスとして扱われるのでPrt Scrキーでスクリーンショットをクリップボードにコピーすると全てのモニタの領域がつながった状態でイメージが取得されます。プロファイルも付きません。
あと、UI要素は(アプリ側でなんとかしない限りは)カラー変換なしで描画されます。


#8

PNG、identityでsRGBと認識されちゃうのはなんでやろ。モニタプロファイルが埋まってるんだけどな……埋まってないのかな? exiftoolでは出てくるんだけどなー


#9

Windowsは、やはりスルーしてきますか……。
やはり相互運用にはルールが必要だなぁ。

WindowsスタートメニューのFirefoxのアイコンとか、もの凄く派手な色で出ますよね。
MacのDockの方は落ち着いた本来の色で表示されるので変換されてるのよくわかる感じです。


#10

sRGBチャンクが付いててそちらが優先されている……はさすがにないか。
バグもしくは仕様かもしれませんね。
かの人ならソースコード読んでそうだし理由がわかるのでは。


#11

Macならmogrifyとかじゃなく、sips -m ‘Profile.icm’ filepath で正常にプロファイル変換できますな…

このsipsコマンド、SierraあたりからoptimizeColorForSharingオプションってのがついて、実行するとApple Wide Color Sharing Profile.iccてのが付くですよ。P3に近いけどちょっと違うやつ。iPhone等に合わせたWideColor対応………の一環かもしれんけど、訳の分からないオプション付けないでほすぃ


#12

話脱線&先日ツイートした内容ですが、プロファイルがない、sRGBチャンクなどが付いているわけでもないPNGをPhotoshopで開くとsRGB埋め込まれていることになってるのやめてほしいです……


#13
tell application "Adobe Bridge CC 2018"
	do javascript "var myList=app.document.selections;for(var i=0;i<myList.length;i++){app.system('exec sips -m \"/Library/Application Support/Adobe/Color/Profiles/Recommended/sRGB Color Space Profile.icm\" --deleteColorManagementProperties \"'+myList[i].path+'\" &>/dev/null &');}"
end tell

これKeyboardMaestroで実行…タグ無しsRGBにちゃんとなってるみたいです。


#14

(identify だとして) ImageMagick の sRGB は輝度非リニアなRGBという事しか表しません。画像データを取り込む際にそのガンマ値も一緒に保持しますが、色空間名をテキスト出力する時に gamma=1 の時に rgb、1 以外では srgb とする雑な処理です。
なお、6.7.5-5 からそうなっていて、それ以前ではどちらも rgb で、"rgb(255, 0, 0) " といった文字列を解釈する時の処理が混乱していたので srgb と分離して、その際に gamma=1 で分岐したのが今まで続いています。


#15

あと、蛇足ですけど、昨年末頃に出た 6.9.9-29 から gray も非リニアなものを sgray と表現するようになりました。以前は gray = non-linear だったので、ChangeLog を見てるとこれもまた混乱して見えますね。最近落ち着いたかも。


#16

PNG に内包している ICC プロファイルはこんな感じで確認出来ます。
% identify -verbose -format “%[icc:*]” スクリーンショット.png
icc:copyright=Copyright Apple Computer, Inc., 2010
icc:description=HD 709-A
icc:manufacturer=HD 709-A
icc:model=HD 709-A

自分はコマンド使うのも面倒なので、ブラウザに放り込むと大雑把な情報をダンプするようにしてます。 > http://app.awm.jp/image.js/icc.html


#17

便利ー
KMに吐かせるようにしました。

tell application "Finder"
	set A to (selection as alias)'s POSIX path
	do shell script "/usr/local/bin/identify -verbose " & quoted form of A
end tell