短い結論

錐体細胞の感度のうち L錐体 と M錐体 の感度が近いため、RGBのうち特にG(緑)は純粋に緑とはみなせないから。

等色関数とは?

単一波長の光 (例えばレーザーのような) と、混色光 (RGB光) を比較して、どう混色すれば単色光と「同じ」に見えるかを関数化したもの。

人間の目の網膜のうち、色を感じる細胞である錐体細胞は3種類しかない。このため単色光で3つの錐体細胞が受ける刺激値を、3つの波長からなる混色光で再現できるならば、この単色と混色の光は人間の目には同一に見える (区別ができない)。

RGB等色関数とは以下のようなものである。ここでは 1931 CIE RGB 等色関数とした。このときの RGB の波長はそれぞれ 700nm/546.1nm/435.8nm。

一部の領域で R が負の値になることがわかる。これはBやGをどのように混色しても、この波長域の色を再現できず (具体的には彩度が足りない)、単色光のほうにRを足して等色したことを表している。

すなわちマイナスが含まれる領域はRGBで再現できない色となる。

人間の網膜細胞の感度

色を感じる細胞である錐体細胞には、L錐体 (Long=赤) M錐体 (Medium=緑) S錐体 (Short=青) と波長別に3つの種類がある。暗所で働く杆体という細胞もあるが、これは色には関係しないので今回は無視する。

それぞれの錐体にはRGBに波長のピークがあるが、実際の感度では重なりあう領域も大きい。特にL錐体とM錐体はかなりピークが近く、感度も似ている。これは進化の途中で一度M錐体相当のものを失い、再度L錐体から変異する形で獲得しなおしたという経緯があるためといわれている。

RGBの三原色で作り出せない単色光

錐体の感度と、等色関数を並べて、CIE RGB の原色光の波長に線をひいてみた。原色とは前にも書いた通り

• 435.8 nm 青
• 546.1 nm 緑
• 700 nm 赤

青と緑の混合色で青緑の単色光を作ろうとしても彩度が足りないので再現ができないのはなぜか?

LMS のうち L錐体 と M錐体は感度ピークが近いことから、原色の緑とした 546.1nm の単色光は実は M錐体だけではなく、 L 錐体も反応させてしまう。例えば 500nm の単色光で のL 錐体での感度よりも、546.1nm でのL錐体の感度のほうが高いため、錐体への赤みの刺激が相対的に多くなり、純粋に青緑の色ではなくなってしまう。すなわち彩度が下がる。

LMS Fundamentals のグラフ 546.1nm のL錐体の感度は、500nm のときのL錐体の感度よりも大きい (赤みが強い)。

言い換えると、536.1nm は純粋にM錐体を刺激できるような「緑の光」ではないため、これを青と混色しても高彩度の青〜緑は再現できない。

青〜緑の波長領域のL錐体の感度が、546.1nmでのL錐体の感度よりも低い場合、その波長は青と緑の混色光では再現できないことになり、Rは負の値をとる。

ref

• Wikimedia の錐体反応グラフ
• 1931 CIE RGB / CIE XYZ に詳しい説明
• 等色関数を求めう実験の説明 色の客観的な表現と伝達 （その４）｜光と色の話｜WEB連載｜テクニカルガイド｜画像処理用照明｜製品紹介｜シーシーエス株式会社
• 錐体細胞の感度データやXYZ等色関数のデータ元 http://www.cvrl.org/
  • LMS Fundamentals

Firefox の場合

gfx.color_management.mode

によって挙動が変わる。2がデフォルトだが、2の場合は sRGB が適用されない。1の場合は sRGB が適用される。

• カラープロファイルがない画像
• CSS の色指定
• canvas の色指定

に影響する。

CSS の色と画像の色をあわせるには

現状では画像に ICC Profile をつけないようにするのがベスト。色の再現を捨ててあわせにいく感じ。

CSS の色を sRGB にあわせたい場合は

CSS も含めてあわせるのは無理 (ということにしておくと吉)

備考

Firefox Chrome ともに起動時にディスプレイプロファイルを読みこむので、あとから変えても反映されない。また、プライマリディスプレイのプロファイルしか読みこまないので注意。

CSS の色を sRGB にあわせるには

実は少し可能なことがわかったので「(黒魔術) CSS の色を sRGB にあわせるには」というのをあとで書く → 書いた https://lowreal.net/2017/02/07/4

デモ

• https://lowreal.net/2017/colorprofile/

以下のような感じになっていて、書いてある通りです。Chrome と Firefox だと上3つと下3つの色が異なります。Safari だと全て sRGB 扱いされるので全部同じに見えるはずです。ただしカラーマネジメントが有効かどうかの判定を入れてないので、カラーマネジメントに対応してないシステムでも全部同じになっています。

一番下の色が JS で CSS のルールを書きかえて sRGB にしたものです。

やっていること

要は使う色をあらかじめ sRGB プロファイルの PNG に描いておき、この画像のレンダリング結果を canvas に drawImage して、getPixelData を行うとディスプレイプロファイルが適用されたRGB値を取得することができるので、これを動的に CSS の色として適用すれば sRGB にできます。

sRGB の画像を canvas に描くってところがポイントです。

自動的にCSSから色を抽出して sRGB を適用する

が、これは手動でやろうとすると面倒なので、CSSから色を抽出し、動的に sRGB PNG を作ってRGB値を変換してやるというのをやってみました。実用的かというと実用的ではないんですが、できそうですねってところです。

1. CSS から色を抽出 (cssRules から)
2. canvas に全部の色を描く
3. canvas から toDataURL で PNG を得る
4. この PNG に sRGB プロファイルを埋めこむ
5. img 要素で読みこませる
6. canvas に img 要素を drawImage する
7. canvas の色を読む
8. CSS に色を書き戻す

という手順でやります。

document.styleSheets の内容を書きかえているので、要素個別に書かれたスタイルについては対応できてません。

CSS の色を抽出

雑に以下のようにしました。当然完璧ではありませんが…

function scanStyleSheetColors (cb) {
	for (var i = 0, stylesheet; (stylesheet = document.styleSheets[i]); i++) {
		for (var j = 0, rule; (rule = stylesheet.cssRules[j]); j++) {
			for (var k = 0, name; (name = rule.style[k]); k++) {
				var val = rule.style.getPropertyValue(name);
				if (/rgb\((\d+),\s*(\d+),\s*(\d+)\)/.test(val)) {
					var r = RegExp.$1;
					var g = RegExp.$2;
					var b = RegExp.$2;
					var ret = cb(r, g, b);
					if (ret) {
						var newVal = 'rgb(' + ret.join(',') + ')';
						console.log(rule, name, val, '->', newVal);
						rule.style.setProperty(name, newVal, rule.style.getPropertyPriority(name));
					}
				}
			}
		}
	}
}

canvas に sRGB プロファイルを適用して PNG の data URL 化

// to PNG data URL with sRGB profile
function applyProfile (canvas) {
	function pngChunk (type, data) {
		var LEN_LENGTH = 4
		var LEN_TYPE = 4;
		var LEN_CRC = 4;
		var buf = new ArrayBuffer(LEN_LENGTH + LEN_TYPE + data.length + LEN_CRC);
		var view = new DataView(buf);

		var pos = 0;
		view.setUint32(0, data.length);
		pos += LEN_LENGTH;
		for (var i = 0, len = type.length; i < len; i++) {
			view.setUint8(pos++, type.charCodeAt(i));
		}
		for (var i = 0, len = data.length; i < len; i++) {
			view.setUint8(pos++, data.charCodeAt(i));
		}
		var crc = CRC32.bstr(type + data);
		view.setUint32(pos, crc);

		return String.fromCharCode.apply(null, new Uint8Array(buf));
	}

	var dataURL = canvas.toDataURL('image/png');
	var matched = dataURL.match(/^data:image\/png;base64,(.+)/);
	var base64 = matched[1];
	var png = atob(base64);
	// sRGB with Perceptual (0) rendering intent
	png = png.replace(/(....IDAT)/, pngChunk("sRGB", "\x00") + "$1");
	return 'data:image/png;base64,' + btoa(png);
}

こんなんでできます。やってることは sRGB チャンクを追加してるだけです。PNG は sRGB に関しては ICC プロファイルを埋めこむ必要なく、13バイト追加するだけですみます。

備考

Safari だと drawImage がうまくいかないです。ちゃんと追ってません。Safari はそもそも sRGB なのでやる必要ないです。

前提

ICC Profile を埋めこんだ画像を canvas に drawImage すると、プロファイル変換されたRGB値が描かれる。getImageData 経由でピクセル値を読むことでプロファイル変換済みのRGB値が得られる。

Chrome と Firefox だけで確認しています。これらのブラウザは上記の前提があてはまるからです。基本的に不具合に近い仕様だと思うので、そのうち動かなくなりそうです。あくまでネタってことです。

Safari と IE は OS レイヤーのカラーマネジメントなのが関係しているのか、putImageData や getImageData も sRGB として扱われていそうです。

戦略

プロファイルに影響される値がとれるということは、間接的にプロファイルを推定できるはずです。具体的には sRGB プロファイルで 0,255,0 という画像データがあったとき、これは sRGB の色域で 0,255,0 という色ですが、もしモニタプロファイルが Adobe RGB など広色域であれば、取得できる値は Adobe RGB の色域のためにもっと小さい (飽和していない) 値になると予想できます。

判定

実際にはモニタプロファイルを推定しているので「Adobe RGB の色域だ！」というのはおかしいのですが、近似として Adobe RGB / DCI P3 / sRGB の3種類の計算値の中から、近そうな色域として判定を出しています。

判定方法は sRGB で 0,255,0 (緑) の色が現在のモニタでどういう RGB 値になるかで行っています。255,0,0 (赤) と 0,0,255 (青) を判定にいれるとどうも変なので判定につかってません。もうちょっと考慮の余地がありそうです。

xy色図に色域をプロットする

sRGB の 200,55,55 / 55,200,55 / 55,55,200 をレンダリングした結果を読みとり、三元一次連立方程式を3つ解いてXYZへの変換マトリクスを逆算し、あらためてRGB各頂点のXYZ値を求めるという方法でxy色図に色域をプロットするようにしてみました。中途半端な値を使っているのは飽和させないためです。

こうするとやっていることが多少わかりやすいかなという気がします。

仕様

• 元の高さから変わらないこと
  • 非同期にやってもガタガタしないこと
• 各行ができるだけバランスをとること
  • 文字数 (正確には幅) をあわせる

元の高さから変わらないことというのは行数を変えないということです。これを制約にしてページ全体の高さに影響を与えないようにすることで、非同期的に行数を調整しても閲覧に支障がないようにという意図があります。

「各行のバランス」はできるだけ行ごとの幅を揃えるという意味でいっています。基本的に幅が揃うことはないので、あくまでできるだけです。また、揃わない場合には一番下の行が一番長くなるようにします。これはデザイン上、重心が下になるほうが安定して見えるからです。

実装

• 改行しても良い単位ごとに文を分割する
• 各セグメントの文字幅を計算し、各行に埋めていく

デモ

• https://lowreal.net/2017/midashi-kaigyo/

また、このサイトにも適用済みです。

各行に埋める

1行に収まっている場合は処理しません。

場合によって全く改行位置を調整できないケースも生じます。つまり各行に文字がいっぱいっぱいに詰まっている場合、調整できません。この場合も諦めてブラウザにまかせます。ただ、最後のセグメントには改行禁止ゼロスペース文字を入れることで1文字だけ残るというのは可能な限り避けます。

文字幅の計算には canvas の measureText を使っています。カーニングやリガチャなどが適切に反映されない可能性がありますが、現時点だとこれ以上良い方法がない気がします。

Webフォントを使う場合、ロードされていることを実行前に保証する必要があります。document.fonts.ready がちゃんと使えればいいんですが、Safari の挙動がおかしいので使えませんでした。

そこで以下のようにしてWebフォントのロードを判定しています。

function webfontReady (font, opts) {
	if (!opts) opts = {};
	return new Promise(function (resolve, reject) {
		var canvas = document.createElement('canvas');
		var ctx = canvas.getContext('2d');
		var TEST_TEXT = "test.@01N日本語";
		var TEST_SIZE = "100px";


		var timeout = Date.now() + (opts.timeout || 3000);
		(function me () {
			ctx.font = TEST_SIZE + " '" + font + "', sans-serif";
			var w1 = ctx.measureText(TEST_TEXT).width;
			ctx.font = TEST_SIZE + " '" + font + "', serif";
			var w2 = ctx.measureText(TEST_TEXT).width;
			ctx.font = TEST_SIZE + " '" + font + "', monospace";
			var w3 = ctx.measureText(TEST_TEXT).width;
			console.log(w1, w2, w3);
			if (w1 === w2 && w1 === w3) {
				resolve();
			} else {
				if (Date.now() < timeout) {
					setTimeout(me, 100);
				} else {
					reject('timeout');
				}
			}
		})();
	});
}

もっと良くできるか？

本当は各形態素境界ごとにスコアリングして、読みやすい順に改行を加えるみたいなことができればいいんですが、僕の技術力だとむずかしそうです。クライアント幅によるという性質上、処理はクライアントサイドでやる必要がありますが、そうすると実行ファイルサイズも問題になってきます。

そもそも学習データとして「適切な改行位置」を与えるのが難しい問題があります。Cabocha を使えばもうちょっとマシになるでしょうか？

「下のほうを長くする」という方針がいまいちだと思います。意味的に区切れるところを優先して区切るのが正しいと思われます。

備考: TinySegmenterMaker のマルチスレッドバージョン

なんかどうも boost_system も必要でした。以下のようにコンパイルしました。

g++ -I/usr/local/include -L/usr/local/lib -DMULTITHREAD -lboost_thread-mt -lboost_system -O3 -o train train.cpp

あと train に引数を与えないとマルチスレッドで処理されませんでした。8スレッドでやるなら -m 8 を加えます。

./extract < /tmp/corpus.txt > features.txt
./train -t 0.001 -n 10000 -m 8 features.txt model
./maker javascript < model

レポジトリ

https://github.com/cho45/midashi-kaigyo あまり整理されてません。

追記: budou

ブコメ で教えてもらいましたが、Google がまさに同じことをやってました。

Google の NL APIを使っているみたいです。

追記

文字を変形させるという発想がなかったのですが、編集系の識者のかたから長体かけつつ字送り詰めて押し込んだりしますという意見をいただきました。また、これを実現する方法として CSS transform を使えばいいのではないかという意見もいただきました。

端末の DNG 対応

端末が DNG 対応しているかどうか調べられないか？ と思ったら、Lightroom Mobile だとちゃんと DNG 対応しているかどうかを表示するところがあった。まぁもちろん実際の撮影設定で DNG に設定できるなら対応ということなんだけど。

DNG 対応してない場合は以下の通り

Android DNG

API Level 21 (5.0 Lolipop) から ImageFormat.RAW_SENSOR や DngCreator というのが入っていたらしい。

現実的には CameraDevice が RAW をサポートしているかどうかで実際に出力できるか変わりそうだが、いまいち市場での対応状況はわからない。スペックに RAW 撮影対応かどうか書いてあるのを見たことがない。

手元の ZenFone 3 だと Lightroom Mobile で DNG が生成できることは確認できた。ただ、 ZenFone 3 はそもそもカメラの性能がいまいちなのでそれほどテンションあがるわけではない。

• https://developer.android.com/reference/android/hardware/camera2/DngCreator.html

Google Photos の画像の exif を得る

Google Photos の画像から exif 情報を得るのは簡単ではない。表示しているサムネイルのURLから exif 情報をとれるのが一番簡単なのだが、これはたぶんできない。URL にオリジナル画像や、後述するAPIリクエストに必要な情報が含まれているように見えない。

幸いこの日記では picasa へのリンク ( https://picasaweb.google.com/[userid/[albumid]#[photoid] みたいな形式 ) は保存してあったので、これを利用することにした。

exif を取得したい場合大きくわけると2つの方法がある

• オリジナル画像をダウンロードして自力で exif を解析する
• API 経由で取得する

が、オリジナル画像の URL を取得するためには API リクエストをしないといけないので、とにかく API リクエストを行う必要がある。オリジナル画像の URL を取得するレスポンスには exif のメタデータも含むため、これで足りるならわざわざオリジナル画像をダウンロードする必要はない

Invalid な albumid を回避する

Picasa API という既にメンテされていないAPIを使わなければならないのだが、userid albumid photoid 全てがわかっていないと画像のメタデータを取得することができない。

保存されている picasa へのリンクに全てあるのだが、albumid に invalid なものが含まれることがある。これは Google Picker API 経由で取得したものなので、 Picker API がなんか不思議な URL を返すようだ。意味がわからないんだけどなぜかそうなっている。

これじゃあ無理かと思いつつ試していたところ、albumid は valid で存在してさえいれば、photoid の親でなくとも良いということがわかった。画像が含まれるアルバムのIDというのを知る必要はないのだ。

ということで、userid は簡単に調べられるし、albumid には適当に存在する albumid を指定しておけばよいということなので、実質的には photoid だけでメタデータを取得できた。