L*a*b*とD50の関係ColorACでNTSC比、カバー率を計算ICCプロファイルの色域制限ICCプロファイルの色域制限ColorACでICCプロファイルからデータをインポートする際に、クリップの可能性についての警告が出る場合があります。これについて解説してみます。Spaces)と呼ぶ共通のデータフォーマットに変換します。L*a*b*)を元にした形式(PCSLAB)のどちらかを使います。プロファイルの特性を記録したTagのデータ形式は、都度のデータ形式変換を避けるためにPCSに合わせた形式て格納されます。この2つのPCSの形式の中で、一般に色彩の振る舞いを表現するにはPCSLABが優れているとされるので、ICCプロファイルを作成する時は、PCSLABが採用されるケースが多い様です。PCSLABは、a*とb*の範囲が-128~127に限定されています。これを超える色は表現できません。(より詳細には、ICCプロファイルのバージョンやタグにより多少扱いが異なります。Ver4.2のPCSLABは+127が最大値。)PCSLAB色域の広さ-128~127の範囲がどの程度の広さかと言うと、およそAdobeRGB(D50に色順応変換した)が表現できる程度の範囲です。a*=-129とほぼ限界に等しい数字になっています。実際の色度がAdobeRGB色域よりも外側にずれている可能性もあります。その場合は、先のL*a*b*形式の範囲では特性を表現しきれなくなります。例として、Greenの原色の色度がAdobeRGBよりも濃い場合について、どうなるか見てみます。xy座標で示しました。様になると考えられます。-128の外に出た部分が、切り取られて無くなった様な形です。xy座標上に戻すと下図の様になります。Gの原色の部分が欠けている様に見えます。以上の現象は、ICCプロファイルを作成する条件として、PCSをXYZに指定する事で一旦は解決します。XYZの形式よりもLab形式の方が特性モデルとして精度が良い(中間調の時の補間精度が良い)ので、PCSとしてXYZを選択すると補間精度の低下と言う欠点が出ます。PCSをLabにしたまま、クリップ現象を起こさせない方法があるかどうかについてですが、残念ながら私は知りません。a*,b*が±128に近いデータになっている場合には、警告を出す様にしています。この警告は、ディスプレイの表示特性に異常があると言う意味ではなく、ICCプロファイルに書き込まれたデータの内容に関するものです。上記の例の様にGの色度点が多少クリップしている程度であれば、カラーマネージメントと言う意味では、Gの強度が強い部分だけに影響が出るので、ほとんど問題にならないのかもしれません。ICCプロファイルを使ってディスプレイの色域を評価する場合には、注意が必要です。警告が出た場合は、CIELAB形式で色域をインポートして、*a,*bの値が飽和していないか確認してみてください。方法が、良く使われます。ColorACでも、もちろんこの計算ができます。操作方法と注意点を記載しておきます。3原色の色度点が作る三角形の面積を色域として計算します。NTSC比であれば、特に指定しなくてもサマリに表示されます。RGBWアイテムにRGB色度を入力した下図の例では、色度図とサマリは次の様になります。このRGBWアイテムを使う方法では、情報としては3点の座標のみで、色域は三角形の面積として色域が計算されます。0.080となっています。0.1582)との比率がNTSC比です。他の色域(上記のNTSCではない)を基準とした比率の数字が欲しい時は、領域重なりアイテムを使って計算します。カバー率が欲しい時も領域重なりアイテムで計算できます。表示アイテイムの構成は次の様になります。領域重なりアイテムを追加し、作った2つのアイテムを指定たとえば、sRGBの3原色と上記のデータを比べてみます。領域重なりアイテムのサマリを見ると次の様になっています。計算結果はアイテムリスト上にも表示されています。黒背景文字の部分がカバー率です。(2)黒データが含まれている場合ColorACは、データ補正アイテムを使ってRGBの原色に加えて、黒のXYZを入れる事ができます。表示が白っぽくなってしまっている状況(コントラスト低下)等を表現する事を想定しています。3角形ではなくなります。この場合は、色域は6角形になります。色域は単純に3角形で計算した場合よりも少し広くなります。ColorACは、正しく多角形の面積として色域を計算します。色域の計算方法が”3原色の座標が作る三角形の面積”と明確に指定されている場合があるので、注意が必要です。その場合はColorACで、データ補正アイテムを使って計算すると数値が合わなくなります。(三角形の面積で計算したい場合は、3原色の数字を直接指定する(1)の方法で実施してください)(3)ICCプロファイルからデータをインポートする場合ICCプロファイルは、上記(2)の黒を入れた単純なモデルよりも、より複雑で詳細な表示特性のモデルが使えます。色域計算に使った時の結果の解釈にも注意が必要です。ICCプロファイルの中でCIELAB形式を使っている場合は色域が制限されるので、広色域の検討では制限に掛かっていないかどうかにも注意が必要です。ColorACでICCプロファイルからデータをインポートする時に、ColorAC側のデータ形式として2つ準備しています。RGBWアイテム(RGBWの色度)+データ補正アイテム(黒輝度)多点アイテム(Gamut領域の多角形表現)評価対象のディスプレイの色域(Gamut)を得るためにインポートする時は、多点アイテムでインポートする事を推奨します。これは、ICCプロファイル側で採用したモデルの種類によらずに正しく色域を計算した結果が得られるためです。インポートのダイアログ画面の設定は、初期設定(default)のままで良いです。明るさに変換」になります。「黒色度データを差し引いて、黒輝度=0のデータを作る」は非選択のままにします。これで、実際のディスプレイを評価したデータに相当する色度を取り込む事ができます評価対象のディスプレイのICCプロファイル色域をインポートした後の扱いは、既に記載した領域重なりアイテムで計算する方法が使えます。多角形の面積、多角形同士の重なり面積の計算に対応しているので、多点アイテム形式で問題ありません。ICCプロファイルを活用する時、もう一つ重要な注意点があります。評価対象のICCプロファイルの扱いとは全く逆の考え方が必要になります。多くの場合、余計な黒輝度を含まない規格通り(理想値)の原色の色度を得るためには、黒を差し引いて読み込む事が必要です。”多くの場合”と推測になるのは、基準に使うICCプロファイルの作り方に依存しているからです。規定の色域に黒輝度を加えて色域が狭くなった状態のプロファイルの作りになっています。この様なICCプロファイルから規格の色度を得るには、黒輝度を差し引く事が必要になります。黒輝度=0の設定になっているICCプロファイルも多いです。その場合は黒の差引は不要ですし、ColorACのインポート設定画面上でも黒輝度を差し引く選択ができない状態になります。AdobeRGBのICCプロファイルは、黒輝度=0でした。4.2)から色域を読み込んだ例を示します。sRGBのICCプロファイルからインポート基準の原色色度の座標が分っている場合には、ICCプロファイルから基準色域のデータを引き出すのは避けて、直接RGBWアイテムに数値を入力して基準を作った方が確実です。NTSCやAdobeRGB,sRGBに対する比率が必要な場合は、ColorACに座標データがプリセットされているので、それを活用すると簡単です。良く見かける色度図のひとつです。ColorACでも、RGBの3原色の色度(RGBWアイテムを利用)からa*-b*の色域図を簡単に描く事ができます。sRGBなどのa*-b*色域図を掲載しています。このColorACで描いた色域図と、ネット上で見かける色域図とが少し違っている場合がある(と言うよりも、違う色域図が多い)事に気づいた方もいるでしょう。(ギャラリーページと同じ形の図を掲載しているサイトもありますが少数です)この状況から、ColorACで描画した図が間違っていると思った方もいるかもしれません。この誤解を解くために、ネットで良く見る図とColorACの図で何が違うのか、WikipediaのLab色空間のページに掲載(2015年7月時点)のa*-b*色度図を例に確認、説明してみます。Webで良く見るL*a*b*図WikipediaのLab色空間のページに、sRGBのL*固定のa*-b*図が掲載されています。この図です(WikipediaのLab色空間のページの画像データをリンク)。この図には「sRGBの色域に収まる範囲(一般的なコンピュータのディスプレイに表示できる範囲)」と説明が付いています。一般的な解釈、以下の色度、またはそれを元にしたものを指していると言う事で間違いないと思われます。何が違うのでしょうか?もったいぶらずに結論を書いてしまうと、Wikipedia掲載の図は、プロットするsRGBの色度点を、D50の白色基準に変換(色順応変換)した上で、L*a*b*でプロットしている様です。これは推定にすぎませんが、以下の様にいくつかの条件で色度図を描いて比較してみた結果、D50に変換する事でWikipedia掲載の図と良く似た図が描ける事が確認できました。実は、グラフの範囲が-128~128と言う2進数を想起させる数字を適用している点だけでも、この図の由来が推定されます。別の記事を書くつもりです。ディスプレイのL*a*b*図の描画条件Wikipedia掲載の図はsRGBであり、かつ、なぜか違う色度図になっている。比較しているColorACの色度図は、単純にsRGBの原色の色度に基いてa*-b*を描いていますが、これにディスプレイの表示条件を追加すると、色度図が変わってきます。Wikipediaの図では、どんな条件を付与したのか。考えられるのが、黒表示レベルを追加する事で色域が変化している場合です。実際のPCモニタの使用環境では外界の写り込みなどがありますし、たとえそれが無かったとしても、ディスプレイの特性のため完全な黒の表示はできません。この黒はRGB単色の表示にも影響を与えるので、色域が変化します。ICCが作ったsRGBのICCプロファイルの表示色を確認すると、上の表の3原色とは違う色域になっています。point)が設定されているためです。黒輝度を考慮したL*固定図を描いてみると、以下の様になります。黒が明るくなる要因は複数あり各種条件に依存します。sRGBをの規定を調べても黒の明るさを一意に決める事ができないので、ここでは例としてICCプロファイルに入っていた黒を使っています。黒による変化の様子が分りやすくなる様にICCプロファイルに入っている黒の10倍の明るさの黒を適用した場合も表に入れてみました。xy色度図で見ると、この様になっています。この3つのディスプレイをL*一定のa*-b*図に描くと、下表の様になります。(a*-b*図の画像データを作成する時のRGBの値は黒輝度=0の理想的なsRGBのディスプレイに表示する想定で計算しています)Wikipedia掲載図の利用承認を取る手間を避けるため、この表にはWidipediaの図は掲載していません。その代り右端に色域形状の比較図を追加しました。形状比較図は見易い様に拡大して±100の範囲の表示にしています。(白色=D65,黒Y=0)L*=75L*=50L*=25黒の数字(黒の明るさ)を入れる事で、L*一定で描画できる色の範囲は減ります。L*=25の図は空になっています。これらColorACで描いた図とWikipediaに掲載の図を比べてみると、色域の広さと言うよりも、形状が違っています。ColorACの結果とWikipedia掲載の図が一致する事はありません。色度図の不一致は、想定する黒レベル条件の差が原因と言う事では無さそうです。そこで黒ではなく別の要因の可能性を考えます。次に考えたのは、色順応などの観察者側の要因を入れて、sRGBの色度から他の色度に変換してしまっている場合です。sRGBの白色はD65ですが、これとD50を組み合わせてみます。以下、sRGBのRGBと白色をD65からD50への色順応変換を施したものをsRGB(D50)と表記します。Transformです。xy色度図で見ると、この様になっています。この2つのディスプレイをL*一定のa*-b*図に描くと、下表の様になります。sRGB(D50)L*=75L*=50L*=25黒レベルを入れた時と同様に、図を見比べただけではWikipediaの図との比較が難しいので、以下に形状比較を示します。Wikipediaの図が良く一致している事が分ります。(Wikipediaの色域図の形状は、掲載の画像から読み取って作ったため、あまり精度が良くありません)WikipediaのsRGBの色度図は、sRGBをD50に色順応変換してから描画して作ったと考えられます。D50と言う標準光源の名称が出てきましたが、sRGBの色度をD50の白色基準に変換する事はどんな意味があるのでしょうか?なぜD50なのでしょうか。私がD50への変換に関連していると推測したのは、D50に色順応変換してから描いた色度図を、とても良く使っているグループがいるからです。それはカラーマネージメントのコミュニティです。ICCでのカラーマネージメントにおける表示データの色域変換の計算は、一旦、カラーマネージメントの対象デバイスの色域(色空間)をD50基準に変換してから、変換を実施する手順です。色域変換した後に変換先デバイスの白色基準(sRGBであればD65)に戻して変換結果を使います。これがD50に色順応変換した色度を使う理由の様です。これは色度図を描く手順ではありません。色域変換に使うL*a*b*のデータをそのまま表示すると、D50基準のL*a*b*図になっている訳です。ICCプロファイルなどのカラーマネージメントシステムの実装としては、D50に変換後の形式でデータを保持しているため、自然とD50基準のL*a*b*図になります。このカラーマネージメントのプロセスは、異なる照明環境、あるいは別の白色基準のデバイスでの色の見え方を比較、変換するために実行される処理です。L*a*b*の形式よりも色順応変換の方が主役です。L*a*b*の形式で色を表現する事は、多くの場合計算精度を上げる工夫にすぎません(実際、規格化された三刺激値も使われています)。共通の環境としてD50が選ばれるのは、主に歴史的な経緯によるものです。従って、L*a*b*の表示のためにD50に変換すると言うのでは本末転倒ですが、カラーマネージメントに関連する場合ば問題無いでしょう。D50への色順応変換してはいけない場合では、この表示デバイスの色度をD50に変換して扱うと言う方法が、カラーマネージメントやそれ以外も含めてどんな場面でも常に適切かと言う事になると、さすがにそれは違います。世の中にD50ではない環境、デバイスが沢山あります。ディスプレイの白色とD50の間で変換すれば万事解決ではありません。そもそも、色順応とL*a*b*は別のものです。このD50に変換する方法にメリットがあるのは、想定する白色の色度の色順応計算が有効な場面に限定されます。素直にL*a*b*を計算した方が良い場面も多いはずです。うまくいかない例をひとつ挙げます。前のCIE2000色差の計算に書いた、D65のモニタと7000Kのモニタの色比較の様な場面です。ここでは色の差が目視しやすい様に7000KではなくD93(およそ9300K)を例にします。色域もモニタで見やすい様にAdobeRGBではなくsRGBを想定します。これが、sRGB用のカラーパッチをD65とD93のディスプレイに表示したイメージのビットマップです(右側がD93です)。注意:比較しやすい様に、カラーパッチの周辺はL128のグレイに統一しています。単純に0~255の範囲に丸めてしまっています。正確な変換とは言えません。以下のD50への変換した場合等も同様です。当然ですが、明らかに色が違って見えます。青っぽくなっているのが分ると思います。これほどはっきりわかる例ですので、色差をそのまま計算すれば、大きな数字になりす。先ほどの「モニタの白色をD50に変換する」と言うプロセスを実施してみます。・・・理屈からして計算するまでも無いですが。D50に揃えてしまった訳ですから、両者は同じ色になりました。この状態のL*a*b*の値で色差を計算したらどうなるでしょうか。色順応の変換の意味を理解せず、盲目的にD50に変換すると、D65のモニタの表示とD95のモニタの表示に色差は無いと言う結論になってしまいます。これは一般には間違と言って良いでしょう。「色順応したらD65のモニタとD93のモニタに差は無いから、色差は無いと言う結論は正しい」と言う意見もあると思います。それこそ「色順応したら」ですから、その様な前提が成り立つ場面でのみ適用できます。前のCIE2000色差の計算では、色差を計算する前提としてD65のモニタと7000Kのモニタを並べて見て比較していると状況では成り立ちません。以上は極端な例ですが、ここまで酷くないにしても、意味を理解せずにD50に変換すると、目的に沿わない結果が得られる場合がある事が分ると思います。まとめ以上の様に、ColorACのL*a*b*図の描画が間違っている訳ではないです。D50に変換した色度図を描画したい場合は、その様にデータを作る必要があります。ColorACは汎用を主眼に作っているため、ディスプレイの色度図を描く条件は、前提とする環境条件など複数あるため、目的の条件を設定する必要があると言う事です。確かにD50に変換した色度図は利用頻度が高いかもしれないので、要望がありましたら、もっと手間が省ける選択枝を追加しても良いかもしれません。ICCプロファイルからのインポートを使う場合に、D50のままインポートして色度図を作成すればD50の図が作れます。D50に変換した状態の色度図だけを、この変換に関する説明は全く無く掲載しています。一方で特記しておきながら、色度図の例には解説無しでの適用は不釣り合いなので、せめて注釈は欲しいですね。D65とD95のデータを一括してD50に変換すれば、色差を残したままD50に変換する事ができるし、そうすべきと言う反論が考えられます。D65とD95の平均値からD50への変換を両方に掛けてみました。これならば確かに色差は残ります。D50の環境に変換する必要がある場合であれば、有効かもしれません。これは、色順応計算は環境を正しく見て設定する必要があると言う例にはなります。2000色差式(以下dE2000)の採用が推奨される場面が増えてきました。ColorACにもdE2000が実装されていますが、dE2000の計算式は少々複雑なので、注意して計算式をプログラムに変換する必要があります。そこでColorACでの計算の確認結果と、適用例を挙げてみます。データを入れて、計算結果を比較しようとしました。そもそもコンテンツの間でも計算結果が合わない事が分り、どれが正しいか分からないので検証に使うのは諦めました。リファレンスになりそうな報告書を探したところ、うってつけの文献が見つかりました。いろいろな条件のデータが網羅され、色差値も掲載されています。整理された計算式も掲載されていて、大変参考になります。この文献のテストデータを使って、ColorACが文献の色差計算結果を再現できるかやってみました。表の右端の誤差とは、この論文記載の色差値を正として、それに対しての差です。0.00%当然と言われてしまいそうですが、ColorACでも論文と一致した結果が得られました。ColorACに、正しくdE2000が実装されれていると言えそうです。)このテストデータが入ったColorACのデータファイルを、この章の末尾にリンクした参考データに入れておきます。重箱の隅をつつく様な話ですが、実はVer0.762までのColorACでは、データNo.14に約0.5%の誤差が発生していました。実用上、まず問題無いと思います。このNo.14のデータ例で誤差が出た理由は、このデータがちょうど分岐点にあたる例になっていて、ColorAC上の演算誤差が元で違う分岐になってしまったため、結果が大きく(と言っても0.5%ですが)ずれていました。dE2000の計算の途中に、計算する色度データを原点から見た角度の差が180度、またはそれよりも小さいと言う条件が出てきます。2番目の分岐になる意図の様ですが、Ver0.762までのColorACでは3番目の分岐になってました。わずかに大きいだけですが、≦の条件不成立で分岐違いになり%オーダーの差として現れます。差分を解消できないかと再トライしてみました。イコール条件が成立する様になりました。ディスプレイの色差計算例ColorACは、任意の座標変換が可能であり、色彩輝度計などのXYZの測定値からL*a*b*の色差を計算する用途にも便利に使う事ができます。ColorACによる色差計算の例を作ってみました。仮想実験の想定は、2つの設定が異なるディスプレイにマクベスチャートの色を表示して、色彩を見比べたと言う状況です。色温度をAdobeRGBを元に7,000K相当に調整したモニタです。輝度は両者共に200cd/m2に合わせて、暗室で測定したものとします。三刺激値を元にColorACで計算したdEとdE2000です。ColorACの表示はこの様になっています(図中の数値はdE2000。計算結果を後からMultipointのOptionとして入力しています。末尾のリンク参照)やはり無彩色部分の色差が目立つと言う分りやすい結果です。dE2000を基準に見ると、dEでは黄色、シアンなどの変化を大きく評価しすぎている事が分ります。多くのディスプレイは発光で色を表現するため、CIELABの本来の想定(光源色を基準のXYZとして用いる)と違っているため、基準のXYZの選択は悩みの種となります。異なる白色のディスプレイがあるため、そのままあてはまりません。基準の決定には状況設定が必要であり、今回はディスプレイを並べて同時に見ている事を想定しました。基準は、色度は2つのディスプレイの白色の平均値(三刺激値の平均から計算)で、輝度は基準が2つのディスプレイの三刺激値を下回らない(X/Xn,Y/Yn,Z/Znが100%を超えない)数値を設定してL*a*b*を計算しています。ColorACの参考データ上の計算の値検証と、下のディスプレイ色温度の色差計算のColorACデータを掲載します。値の検証はCIEL*a*b*の値を直接入力して計算する例として、またMacbeth色彩の例は三刺激値XYZの値を入れて計算する例です。Formulaトップに戻る相関色温度の計算についてColorACには色温度(相関色温度)の計算が実装されています。素直にプランクの放射式から求めています。面白味はありませんが、正確な結果が期待できます。ColorACの計算結果と比較したので報告します。測定方法)が良く参照されています。8725は色温度についての定義、計算、測定の方法について整理、規定したもので、1999年に改定されたものが現行の規格です。記載されている様な)説明と同じで特別なものではありません。次の様に端的に規定されています。色度座標にもっとも近い色度座標をもつ黒体放射の絶対温度として定義される。相関色温度の定義として、理想的な黒体(プランクの式)ではない放射を想定するものもある様ですが、このJISの定義は黒体が基準であり、プランクの放射の式からスペクトルが計算できます。付表1(または付表2)を用いて相関色温度を求める方法が指定されています。具体的なプログラム例が記載されています。8725に準拠した相関色温度の計算と言えそうです。8725の考え方と同じです。ColorACでは直接プランクの式から黒体放射スペクトルを求めて、色度を計算します。C++による倍精度の浮動小数点計算です。相関色温度は、繰り返し色度点と黒体放射軌跡の距離を計算して一番近い黒体放射曲線上の点の色温度として求めています。プランクの式に適用する物理定数の値です。光速の組み合わせから作られるc2(放射の第二定数)の値を決める必要があります。起源の古い規格等は、古い異なる定数値を使って作られているので、比較には注意が必要です。現在は、物理定数はCODATAの推奨値を用いるのが一般的です。まるめて記載されていて、どの数字を想定していたのかは分りません。この数値を使う理由は知りませんが、この数字が国際的にも標準として使われている規格の様です。0.01438800を使う事にしました。Ver0.762から変更。D2BL(Tc-ΔT)と表現できます。このΔTは上記の式を確認しながら繰り返し計算して、徐々に小さくして行きます。相関色温度の数値として有効桁5~6桁を想定する場合、収束に関しては十分(すぎるぐらい)と言えます。目標のΔT≦Tc/108の前に計算を打ち切る必要が出てきます。そこで、実際に相関色温度を計算した時に、どこまでΔTを小さくできているか調査しました。0.3885~0.2395の範囲に乱数で色度点を発生させて相関色温度を計算し、計算結果に適用されたΔTの最大(最悪)値を確認します。色温度やduvにより精度が変わると考えられるので、段階に分けて集計しました。ppm)結果は予想通り、duvが大きいほど、また色温度が高いほど誤差が増える傾向になりました。悪い値でも204ppm(0.02%)となっていて、実用上問題無い精度と言えると思います。8725によれば、Tcを相関色温度と呼べる範囲)に限れば、最大で16ppm=0.0016%と、十分高精度になっていました。計算が正しいかどうか(精度ではなく確度)の確認のために、信頼できる色度座標と相関色温度がセットになったデータが欲しい所です。探したのですが、色度座標の有効桁が少なかったり、信頼できる文書でなかったりで、都合の良いデータはなかなか見つかりません。見つけた中では良さそうなデータと比較の結果を一つ提示します。(u,v)=(0.247629,0.367808)となっています。2900.0086・・・K、duv=0.020000・・・となります。最後の桁の下の桁に±5の範囲の数字があると考えて3x3のデータ点を作ってした結果が以下です。0.1K程度まで正しい数字になっています。その色度から複数の手段で色温度を計算して比較しました。使って、色度に変換したものです。Excelのスプレッドシート上でマクロ等を使わず簡単に計算できます。プランクの式から求められる色度の正しい計算結果として使えると考えます。8725と同じ数値を用いています。補間の誤差はほとんど出ない色度座標になっています。10進数でちょうどきりの良い数字であるため、特殊な数字のみの検証と誤解されない様に、中途半端な数値を入れてみました。Calculator、およびMcCamyの近似式です。ColorACについては、元にしたデータがduv=0であるため精度低下要因が無く、上述した様に1/108までの収束計算を反映した精度が得られています。Calculatorも、精度良く再現できています。3者は一致すると言ってよいと思います。ついては、高温側で誤差が目立ちますが、基本的にはプランクの式から求めた色度と合致していると考えてよいと思います。あり、信頼性の高い数字が得られる手段と考えて加えたのですが、予想外に誤差が大きいと言う結果です。2000Kから7000Kの範囲でプロットしてみて、精度が良いとの話の意味がわかりました。2点に着目しての話しの様です。8725のテキストを見て気づいた点、及び計算を確認した結果見えてきた問題に以下があります。そのままでは使えません。実行して答えが返る程度には修正されている事が分りました。なっていて、偶然この条件が成立する入力値を与えた場合以外は正しく動作しません。j-2>0の条件が必要です。jの添え字範囲のケアが必要です。8725で比較してみました。等間隔に500点選びました。10度視野(CIE1964)の計算から先に比較結果を示します。8725差を示します。0.01%以下の差となります。両者は良く一致していると言えると思います。前後のuの値に対してずれています。次の図の様に1,750K近辺での差の局所増が無くなります。8725に準拠しない結果と言う事になります。)前節の10度視野と同様に2度視野の計算結果を比較したのが下図です。局所的に差が増大する箇所があったのですが、H21年の公式修正により無くなりました。両者の差は%オーダー未満に収まっていて良く一致していると言えると思います。差が大きくなる傾向あります。この高温側で差が増える傾向は10度視野でもあったのですが、2度視野ではより目立ちます。8725で使うデータテーブルの中央付近にあり、補間の誤差の傾向とは考えられません。プランクの式から計算した黒体の色度からずれている事が分りました。この差がColorACの計算結果との差になって見えている様です。この差が何に由来するものなのか、現時点良く分かりません。プランクの式になんらかの補正項を加えているのか、あるいは単にデータを作った当時の計算精度が悪かっただけなのか・・・まとめColorACに実装されている相関色温度の計算は、プランクの式から計算した黒体の色度を正しく算定している事を確認しました。同じc2=0.014388を適用しました。大差無い結果となります。準拠の計算結果が必要な場面も多いと思います。8725準拠は"Tcp"と表記する様にして、後からどちらを適用したか分りやすくしました。掲載のプログラム例を元に作った相関色温度計算のソースコード(ColorACで使ってい物と同じ。C++ですが)を掲載します。2011Lindbloom.comトップに戻るHSVの輝度の扱いHSVは、RGB色空間の変換として式が定義されています。従って、やはりスジ状に見えます。いま良く判らず、まずは変換式から単純に描画(補正無し)としています。HSVの場合はデータ空間と考えて補正無しが正しいですね。トップに戻るxy色度図の輝度の扱いLABは大変苦労しているのですが、より軽微な問題として、xy色度図などでも考えるべき点があります。xy色度では、座標で色は決まるのですが、輝度をどうするかは色度図を作る側の検討項目となります。それは、RGBの3原色が混色するYMCの部分が輝いてスジ状に目立って見えている事です。実は、この図は色データとしてRGBの階調のどれかが最大の階調(256階調だと値255)になるルールで描画しています。混色の部分は単色のRGBよりも当然、加法混色して輝度が大きくなるので、当然スジ状に目立って見えてきます。色度図の本質とは何ら関係無いので、色度図としては好ましくない不自然な見栄えだと言えます。ColorACの色度図はそうならない様に混色部分の輝度を下げる様に調整しています。三刺激値データ(あるいは色度+輝度など)とHSVの変換式が決まります。HSV上でどうなっているかが分かります。トップに戻るa*-b*の表示L*a*b*から、a*,b*の色度図の作成を考えます。ColorACにa*-b*色度図の描画機能を実装しようとしたら、a*-b*面での描画色は、一意に決定できない問題である事に気付きました。xy色度図ではPCモニタ上で表示できる色と色度図の色の差分をどう処理するかに工夫が必要でしたが、もっとずっと深刻な問題です。a*,b*の座標における色そのものが、L*の取り方で変わってしまうため、一般論としては、色を決められません。適切な前提条件を付加する必要がありますが、一般的に適切と言える条件を作るのは難問です。Locus)を描画しようとする場合、輝度の情報は無いので、L*を決定するルール(条件)を置かないといけません。単純な方法として、L*をある値に固定してしまって、a*,b*の断面を描画する事が考えられます。右図はL*a*b*における基準の三刺激値をD65光源とし、L*=100で固定して波長軌跡を描画したものです。すごく伸びた形状になっています。L*=100と不自然に固定してしまったために、それを反映して伸びたものと考えられます。この図は定義が明確であり、十分意味のある図と考えますが、a*-b*の色のイメージとして汎用なものが欲しい所です。それを表現できません。L*を小さい値に設定すれば良いかと言うと、この傾向は変わらず解決にはなりません。結局、視感度の悪い波長部分でも、L*が保たれてしまう事が不自然になる根本原因です。実際の評価対象の色のバリエーションと同じ様なL*の振る舞いをするモデルが必要です。青の異常な広がりは無くなって目論見通りにはなりました。RGBの3原色をどう設定するのか根拠ある方法なのかについて、良いアイディアが浮かびません。計算の原色RGBを一致させる事でうまくいくのかも...しかし、これでは3原色のシステムにしか適用できません。今、別の考えとして波長ごとの視感度の値をL*に変換して描画すれば、もう少し自然で適切な図が作れないかトライ中です。a*,b*もゼロとなり、不自然な図になる事が予想できますとにかくL*a*b*を2Dの色度図として成立させる事が結構難しい事は分かりました。素直に、3Dグラフとして描画した方が、ずっと簡単だと思えます。ColorACはxy色度図を描画する事をメイン機能として作っているソフトです。xy色度図は2次元データですので、そのまま2次元のグラフとして表現可能です。明るさの情報を含んだ3Dの表現としてL*a*b*(CIELAB)や、HSV色空間なども良く使われています。ColorACでも、これらを表示する事を考えました。2Dの図としての描画を考えました。xy色度図と同様な図がなりそうです。実際に、その様な図が世の中にあります。たやすい事に思えました。ColorACの変更点は、座標変換関数を追加する事と、入力データとして3次元のデータに対応する事が主となるでしょう。直交座標に変換すれば、xy色度図と共通の描画ルーチンが使えるでしょう。色度データで、色度のばらつきなどのデータをプロットしようとすると、沢山のx,y値を入力、編集する必要があります。この処理は、Excelなどの計算表のイメージの編集環境を思い浮かべて、それを実現しようと考えました。MFCを使っているので、ちょうど良さそうなCListCtrlクラスがあります。これで簡単に実現できる思ったのですが、そのままでは使い物にならない事が判明。データセルをクリックしての編集だけでも、CListCtrlでの実現は設定が難しそうでした。CListCtrlクラスのオーバライドは、手に余りそうだったので、データ入力の時だけ、他の手段で実現できないか考えました。実際作って見ると、CEditからデータを取り出した後の動作の調整などが、なかなか難しい。諦めて、他の人がどんな方法で実現しているか検索してみました。すると、このCEditをCListCtrlの上に重ねる方法での実現を薦める意見がいくつもヒットしました。やり方は間違っていないと、自信が持てたので、諦めずカットアンドトライの繰り返し...。多少操作に対して不安定な感じもするのですが、CRやTABキーで次のセルに編集が移るところなど、最初のイメージに近いものが作れたと思います。正しい色度図を表示する事が実際には不可能です。モニタの表示できる色度範囲が、色度図全体を表示するには足らないからです。正しい色の色度図は作れません。従って、色度図を作ろうとしたら、どうやって本物らしく見える色度図を作るかが課題となります。作る目的が正しい色度図では無いと言う話になりましたが、現実に色度図を描こうとしたら、この本物っぽさが重要です。基本的には、色度図全体の色を淡するか、または出ない濃い色の部分をうまくグラデーションを付けて、モニタで表示できる色度範囲で表示しても不自然に見えない様にします。書籍等に掲載されている色度図とはだいぶ違うものが出来上がります。書籍は印刷で白つぶれているためか、白色部分がはっきりと白く見える場合が多いです。正しい、白く見えない色度図がいいのか、あるいは正しくはないが、白色部分が白く見える色度図が良いのか。上に、測定した色度のマークを表示したり、重ねて使う事になりますが、正しい色度図だと、マークが見え辛くなったりします。色を淡くしたくなります。色の濃さを調整できる様にしました。ColorACでは、色度図を画像ファイルとして出力します。最終出力装置(プリンタとか)での見栄えを改善する目的でも使えると思います。トップに戻るどんなソフトにしようか構想段階にソフトを開発しようとすると、一般素人としては、情報が手に入りやすいWindowsか、Linux系かMacのどれか。私は仕事でもWindowsを使っていて、いちばん慣れているWindowsで開発する事にしました。ソフトの仕様の大枠は、以下の様に考えました。他の資料作成に使うソフトに貼り付けて仕上げる事を想定して、必要最低限の部分(色度図)を作る事にしてハードルを下げる。それらで読み込めるデータ形式のファイルを出力する必要がある。再編集の可能な拡張メタファイルが魅力的だったのですが、しかしそれでは本当にWindows限定になってしまう。ソフトはWindowsでしか動かないけど、成果物は汎用性をもたせたい。結局一番簡単で使いまわしが効く画像ファイルで出力するコンセプトで。グラフ作成ソフトなので、操作性が重要です。色度図を描くだけのために使い辛いソフトを使うぐらいならば、Excelで三角形のおむすび型の輪郭だけ描くだけで十分て人が多そうです。フリーソフトでも、一定レベル以上の作り込みで使い勝手を良くしなければ使ってもらえない。今回は、使い勝手にも力を入れて作っています。