カテゴリ: jagi

昨夜、ねこまたやさんに教えていただいた補正式を使ってみる。

補正した計算用の輝度
HY0 = (Y0 * (100/255))^0.7
HY1 = (Y1 * (100/255))^0.7
中間値 = (((HY0 + HY1) / 2) ^ (1/0.7) ) * (255/100)

輝度は0と255の中間が83程になる筈…うむ…まぁやってみよう。例によってまずはジャギ様。

…これはあの北斗無明拳?ジャギ様じゃなくてジャド様だった模様。
で、トレースを入れると…。

割合=128
入力 R0=0 G0=255 B0=0, R1=255 G1=0 B1=255
, 入力 Y0=149.585550 U0=-84.471300 V0=-106.765950, Y1=105.414450 U1=84.471300 V1=106.765950
ガンマ考慮 yy0=0.000000, yy1=0.000000, yyResult=0.000000
割合=107
入力 R0=0 G0=255 B0=0, R1=255 G1=0 B1=255
, 入力 Y0=149.585550 U0=-84.471300 V0=-106.765950, Y1=105.414450 U1=84.471300 V1=106.765950
ガンマ考慮 yy0=0.000000, yy1=0.000000, yyResult=0.000000

軒並み0が並ぶ。これは単なるコーディングのバグだな…。

このエントリーをはてなブックマークに追加 mixiチェック

そいえばお手本が欲しいので定評のある角滑(90%)でやってみた。左が角滑。

色合いはあんまり変わらず縁が出てる気もするが…。でも確かに滑らか。中間色ドットの数が多い感じ?
ついでにジャギ様で比較。左が角滑(90%)。右が私の(というか処理の中身の9割はLaymanのだけど)

むぅ。さすがだぜ角滑。ジャギ様の眼の輝きが違う。

このエントリーをはてなブックマークに追加 mixiチェック

以下は赤と緑の縁の拡大図。

輝度は左の緑が一番大きく右の赤が一番低いが、私の目には真中の方が暗く見える。ちなみに私としては緑と赤の間はもっと明るいオレンジで埋めるべきだと思う。
帰りに本屋で色モノの書籍を立ち読みした所、「ヘルムホルツ・コールラウシュ・フェノメノン」というのを発見。これはバオー武装現象時の必殺技の一つで、

三刺激値のY(反射率)は明るさを表わし、Yが同じ値なら色相や彩度に関係なく同じ明るさの色として 知覚される筈であるが、色相や彩度(色の純度)、視野の大きさ、輝度などによって左右され、特に純度の高い色光ほど明るく判定される現象である。

つまり、中間色計算時、彩度の高さに比例して輝度に下駄を履かせてはどうだろう?って事。その為にまずはYUVでは彩度が判らんのでHSBかHSVにしないと…。
後、もう一つ考えられるのは、今は中間の値を求める時に単純に足して2で割っているが果たしてそれで良いのか?0→1 は 254→255 よりも随分効果が大きいように思う今日この頃だから、その辺を考慮して何らかの等比でやるべきではなかろうか?

このエントリーをはてなブックマークに追加 mixiチェック


昨夜の問題は0-255にサチる処理を入れて簡単に解決。んが、YUVで混ぜてもRGBで混ぜたときと余り変わらないような。おかしいな。特に赤と緑の間が酷い。

入力
R0= 0 G0=255 B0=0, ... 緑
R1=255 G1= 0 B1=0 ... 赤
Y0=149.585550 U0=-84.471300 V0=-106.765950 ... 緑
Y1= 76.222050 U1=-43.028700 V1= 127.500000 ... 赤

混合割合=128で出力..これがちょうど半分
Y=113.403800 U=-63.250000 V= 10.867025
R=129 G=127 B=1

混合割合=96で出力
Y=104.233362 U=-58.069675 V=40.150269
R=161 G=96 B=1

混合割合=64で出力
Y=95.062925 U=-52.889350 V=69.433513
R=192 G=64 B=1

混合割合=32で出力
Y=85.892488 U=-47.709025 V=98.716756
R=224 G=32 B=1

一応、数字で見ると確かに輝度は両者の中間なんだけど…。

このエントリーをはてなブックマークに追加 mixiチェック

中間色を計算している個所を特定。
RGBをそれぞれ中間を取るのではなく、
RGBからYUVに変換、YUVをそれぞれ中間を取る、YUVをRGBにして書き戻す、
と改造してみた。

ぬぅぅっ!
…色がデタラメではなく反転?してるこの感じは…オーバーフロー/アンダーフロー臭いなぁ。まぁ改造個所が間違っていない事が判ったし、解決は時間の問題。

このエントリーをはてなブックマークに追加 mixiチェック

ジャギ様
昨日のプログラムはとりあえずだけど案外あっさり移殖できた。α付きの画像を使うと透明部分が真っ黒になるけどそれは想定の範囲、っていうかそうしてるし。
で、色々試したんだが…んーむ…どうみてもアンチエイリアシングどころか逆に縁が発生してしまう場合がありますな↓
暗い縁取り
我輩の直感では混ぜる時にR,G,Bのそれぞれ中間値を使ってるのが敗因ではなかろうかと。100%赤と100%緑の中間に赤50%+緑50%を置くから黒ずむと。事前にYUVに変換する?
はて?RGB←→YUVって可逆だったっけ?可逆だと楽なんだけど違ったら縁処理したとこだけ覚えておかないとならんから改造が必要になるなぁ。
いや、中間色計算部分だけ改造すれば良い気もするし…んー…。
ニュートランスファーのソースが使えれば一番良いんだけど、あまりにアセンブラ的なあれはJavaばっかでで鈍った私には辛い…。
でもまぁ、上の偽ケンシロウを見る限り、アニメ絵って黒で縁取りしている、あるいは似た色が隣り合ってるからこれでも使えるような気がしないでも無い。

このエントリーをはてなブックマークに追加 mixiチェック

Pixiaの境界ぼかしフィルターの利用に失敗したので自作(つかソース流用)するしか無いのか。TOWNSのニュートランスファーのソースが有る。このアンチエイリアジング処理は素晴らしいが何せFM-TOWNS用ソフトであり、画面のピクセル数固定(ソースのあちこちに数値直書き多数。斜め上のピクセルにアクセスする時は、現在位置-1022のアドレスにアクセスさ!)、1ピクセル/15bit、当然透明度など考慮なしなので翻訳は辛そう。
別を探してみたらLaymanというのが有った。画面ピクセル数可変、1Pixelが24bitなのでこちらの方が組し易そう。ただ妙にソースが短いので処理が単純なのかも。

このエントリーをはてなブックマークに追加 mixiチェック

Windows Server 2003 SDKからWindows XP SP2 Platform SDKに変えたら、VC++ 5.0でもGDI+のコンパイルが通る様になった。んが、上記のごとくCImage使う様に変更したのでMFC7.0が無いのでそっちで引っかかる。αなHBITMAPとGDI+の関連付けが自前で出来れば、VC++ 5.0でも行けるはずなんだけど、まぁこれは金で解決しよう。それよりPixiaのDLLを…。
どうでもいいが、GDI+で検索するとJPEGアクセスルーチンのバッファオーバーランの話ばっかり。

このエントリーをはてなブックマークに追加 mixiチェック

という、GDI+のラッパークラスがMFC7には有ったのでこれで万事解決。
昨日、αチャンネルが潰れたのはおそらくこう。
GDI+のイメージを作成する時に画像データをHBITMAPの形で渡さねばならん。のでわざわざDIBセクションなHBITMAP作ってそこにデータ書いて、それをGDI+に渡した。が、このHBITMAPは只のGDIでαに対応していないので無視した。
CImageのCreateでα対応なDIBセクション作ってそこにデータをmemcpyしたら上手く行った。
GetBits()は、データ領域の先頭アドレスを返したり、データ領域の末尾付近のアドレスを返したりするので注意。Create時の高さの指定によって、画像の左上か左下を指す。
問題はこれはVisual Studio 97では使えない事。

このエントリーをはてなブックマークに追加 mixiチェック

↑このページのトップヘ