輝度ムラの原因調査 - Githubissues

42minirt / miniRT

Simple RayTracer with miniLibX

0 stars 0 forks source link

輝度ムラの原因調査 #30

Closed ak0327 closed 1 year ago

ak0327 commented 1 year ago

これの続き　https://github.com/42minirt/miniRT/issues/11#issuecomment-1585475408

原因判明　https://github.com/42minirt/miniRT/issues/30#issuecomment-1588391743

対策検討中 -> 無理っぽい

ak0327 commented 1 year ago

y == 270, 800 <= x && x <= 850 の範囲の各数値をチェック

輝度ムラの原因は掴めず
この範囲で濃淡の周期は10回程度繰り返されているはずなのだが...

全体

サンプル範囲

結果

x=800の値との比を評価した
draw直前のR,G,B ： x=800 -> 850 への変化に伴い、単調減少（R==G==Bのため、代表してRをチェック）
dot(n, l) : 同上
ray.dir.x：同上
ray.pos.x：常に0
plの法線ベクトル：常に(0,1,0)

ak0327 commented 1 year ago

mlx_pixel_putを介さず画像を取得

上記の結果より、計算されたcolorは問題なく、描画側が怪しいと考えた
mlx_pixel_put以外の方法で画像を取得した結果、輝度ムラが生じると判明
謎が深まった...

方法

raytraceで得たr,g,bをppm形式で出力し、画像ファイルとして書き出した

結果

得られた画像はこれ

ak0327 commented 1 year ago

int_colorの値

やはり内部の計算で生じていそう...
int_colorの値が未チェックだったので確認 -> これ怪しそう！！

結果

サンプリング範囲：y == 270, 800 <= x && x <= 850
x=800の値との比をグラフ化すると以下のように
輝度一定の区間が繰り返されている
濃淡ムラのある画像をよく見ると、濃->淡の連続的な変化ではなく、グラフのように幅を持つ一定の色の領域が、色調を変えながら存在しているようにも見える
グラデーションに見えるのは、両端の領域との色度差による錯覚である可能性が高い

int_colorは以下のようになっている。double->intの変換時の問題かも。対策できるのか...??

対策

これ無理なのでは？
double -> intで丸められる

minilibxの仕様上、RGBが8bit, 0-255の表現範囲しかないので色調が一定の間隔が発生する

r(=g=b)   int_color(=255*r<<16 | 255*g<<8 | 255*b)
0.361412  6052956
0.361052  6052956
0.360692  5987163
0.360333  5987163

対策するなら色調を連続的に変化させるようなグラデーション処理が必要かも
objのcolorをr=g=bにすると目立つが、r,g,bの値をずらせば目立たなくなりそう -> 多少マシに見える程度だった...

参考

色バンディングという現象らしい https://coliss.com/articles/build-websites/operation/design/how-to-stop-banding-in-your-images.html

ak0327 commented 1 year ago

結論出たのでclose