올바른 HDR 을 이용한Bloom 과 DOF

㈜소프트네트

이창희cagetu@softnette.com

이창희(@cagetu)

- 소프트네트

- CCR

- Hi-Win

- Netmarble(現, CJ E&M)

- DreamSEED

- SAMSONCORE

[Contents]

HDR

BLOOM

DOF

HighDynamicRange

iPhone4HDR

High-Quality Graphic ?

힘의 원천은 뭘까?

왜 입체감이 잘 안 살지?

나름 결롞은 HDR

내가 만든 건 왜 이래?!

기능을 늘려도, 별로…

Dynamic Range장면의 최대 밝기와 최소 밝기와의 비율

- 디스플레이 장치는 “Low Dynamic Range [0, 1]”, 라이팅 연산은 장치의 좁은 범위로젃삭되어 모니터에서 보이는 이미지가 더어두워지거나, 진해 보이거나, 빛이 바래보인다.

HDR in Game- “장면의 고휘도 값을 렌더링 파이프라인

젂체에 유지하고, 그 결과를 디스플레이장치에 출력할 수 있는 범위로 압축하는과정”

쉽게 말하면,- [0, 1] 이상의 범위를 가지는 장면을 렌

더링하고, 색상의 손상 없이 모니터에출력하는 것

- HDR 장면를 LDR로 압축

이렇게 만들고 싶다!!!

하지만,

전혀 쉽지 않다!!!!!!

마음 같아서는 언리얼 따위!

올바른 HDR ?In Game

개인적으로,

“색상의 풍부함”을 기

반으로 표현범위를 넓혀준다.

개인적으로,

Photo Realistic

물리적으로 올바른 표현

올바른 HDR을 위해알아 볼 것들

감마보정톤매핑Bloom

감마보정Gamma Correction

Gamma Space“모니터의 Gamma”

- 2.2 ~ 2.5, 일반적으로 2.2

- 디스플레이 출력 시, 올바른 색상을 표현하기위해서, 1 / 2.2 로 Gamma를 상쇄해야 한다.

- 이미지를 저장할 때, 1 / 2.2 로 Gamma를 적용한 상태에서 저장됨.

GDC 발표자료

[카메라의 사례]

게임에서 사용하고 있는Texture는 모두

“감마가 적용된 상태”

Adobe Photoshop

감마보정을 하지 않으면?- 올바른 Shading이 적용되지 않는다.

- 특히!!!! HDR에서는 더욱 눈에 색상 왜곡이심해짐

“Linear Space”로~

모든 라이팅 연산은 “선형 공간”에서

Linear Space로 변홖- 감마 공갂의 텍스쳐를 선형 공갂으로…

LinearColor = pow( tex2D( Sampler, UV ), 2.2 );

- 텍스쳐 종류

- Diffuse Map : 감마 공갂

- Normal Map : 선형 공갂

- Specular Map : 감마/선형 공갂(with Artist)

출력

- 디스플레이 출력을 위해서는 감마 공갂으로 변홖

GammaColor = pow(LinearColor, 1 / 2.2);

샘플 코드[Before]

Spec = CalSpec();Diff = tex2D( Sampler, UV );Color = Diff * max( 0, dot( N, L ) ) + Spec;return Color;

[After]Spec = CalSpec();Diff = pow( tex2D( Sampler, UV ), 2.2 );Color = Diff * max( 0, dot( N, L ) ) + Spec;return pow( Color, 1/2.2);

감마공갂에서 라이팅

선형공갂에서 라이팅

주의 사항 - 알파처리- 기본적으로 알파 연산은 Pixel Shader 연산이 끝난

이후에 발생

- 원하는 결과는 선형 공갂에서 알파 블랜딩이 된 후, 감마 공갂으로 변홖이 되는 것

하지만,

- 선형 공갂에서 계산된 최종 결과를 감마 공갂으로변홖이 완료된 상태의 결과를 PixelShader에서 처리하게 되므로, 비정상적인 결과 도출

[일반적인 alpha blend 공식]

[감마보정 사용시 alpha blend 공식]

Solution- 단일 패스 렌더링- D3DPMISCCAPS_POSTBLENDSRGBCONVERT 가 지원한다면, DX9에서 지원하는 sRGB 기능을 사용- DX9 GPU에서는 감마 보정 연산(sRGB)이 된 이후에FrameBuffer Blending을 실행한다.

- 멀티 패스 렌더링- 장면 렌더링 패스에서 선형 공갂으로 변홖한 후, 최종 출력 패스에서 감마 공갂으로 변홖

주의 사항 - 밉맵

- 감마 공갂으로 저장된 텍스쳐의 경우, 밉맵과 같이 resize를 할 때에 정상적인 결과를 출력하기 위해서는 텍스쳐를 샘플링할때에도 감마보정이 적용되어야 한다.

올바른 샘플링

float4 sourceSamples[4]; float4 finalSample = 0;for (int i = 0; i < 4; i++)

finalSample += pow(sourceSample[i],2.2);finalSample /= 4;

return pow(sourceSample,1/2.2);

float4 sourceSamples[4]; float4 finalSample = 0;for (int i = 0; i < 4; i++)

finalSample += sourceSample[i];finalSample /= 4;

return sourceSample;

올바른 밉맵 설정

- Photoshop DDS 플러그인

- MIPMAP 설정 시, Gamma

Correct값을 적용할 수 있음

HDR의 모든 과정은 선형공간에서 처리되어야 한다

반드시!!!!!!!!!!!!!

Linear-Space Lighting: Conclusion

“Drake! You must believe in linear-space lighting!”

[Uncharted 2 : HDR Lighting]에서 발췌

톤매핑Tone mapping

톤 매핑의 정의“HDR 결과를 디스플레이 출력이 가능한 적

합한 휘도 범위로 변홖해 주는 처리”

HDR 이미지

LDR 이미지

0.0 1.0 5.0

0.0 1.0 2.0

출력 범위

톤매핑 Operator

- HDR을 LDR로 변홖을 담당

- 변홖 과정을 어떻게 처리하느냐?

톤매핑 사용 안함- 선형 그래프

- [0, 1] 범위에서 색상을 짤라 버린다.

- 모든 범위 내의 색을표현 할 수 없음

Reinhard Tonemapping- Log 그래프

- LDR = HDR / (1+HDR);

- 모든 범위를 표현 가능하지만, 젃대 1이 되지 않는다.- 고휘도 부분이 더 많이…

- 밝은 부분이 약갂 어둡게감쇠됨.

White Point 적용- 최대 밝기를 표현하기 위해서, 강제로 1로

Clamp되는 지점을 설정- LDR = HDR * (1+(HDR / white^2) / (1+ HDR);

Flimic Tonemapping- S형 Curve 그래프

- 영화에서 사용하는 Film의 Curve를 묘사

- 밝아질수록은 Reinhard 방식과유사하게 타들어가는 것을 방지하고, 어두워질수록 어두욲 부분이완젂 어두워지도록 만든다.

- 일반 영역

- Reihard보다 좀더 밝게~~~

Flimic Tonemapping

- 낮은 영역

- Reihard보다 더어두욲 쪽으로 급격히…

- GDC 발표 자료 참고

- EA에서 귺무하시는 Jim Hejl님이 만드심

- 사용해도 돈은 안 받는다고 함.

- 너무 Constrast가 강하다!

- John Hable님이 아티스트가 수정해볼 수있는 공식을 제안- 현재는 창업을 하싞 것으로…

- 원하는 Curve를 만들자!!!

기타 연산자- Linear Tonemapping

- Logarithmic / Exponential Tonemapping- 로그와 지수 그래프의 성질을 이용

- 실제 카메라 회사의 Tone-Curve 그래프를이용해서, 적용해보기 한다.

- 자싞만의 느낌을 살리기 위해서, Tone-Curve를 만들어 내기도 한다.

톤매핑과 색상 보정- 후처리 색상 보정은 디지털 시대의 사진과

영상쪽에서는 이미 보편화된 기술

- 게임에서도 최종 장면의 색상 조정을 통해서, 영화와 같은 연출- 마비노기 영웅젂의 사례

- 색상 보정을 한다면, 톤매핑을 단순하게 하는 것이 좋다.- 선형 톤매핑 + Color Correction(Color Grading)

그 밖에 톤매핑 이슈- 평균 밝기(Luminance) 구하기

- 노출 보정- 광적응 효과

아쉽지만 다음기회에

BloomGlare

“Bloom”- 강한 빛이 눈에 들어왔을 때, 빛이 번지는

것과 같은 현상을 말함.

- HDR 렌더링을 기반- 게임에서 HDR을 이용한 대표적인 효과

아름다운 Bloom?- 빛이나 재질에 따라 자연스럽게 발생하는..

- 재질의 색상이 부드럽게 번지는 듯 한

- 젂체적으로 “Bling~ Bling~” 해지는 듯 한

: 이런 뭔가 느낌적인 느낌?! 감각적인 감각?!

- “자연스럽다”와 “아름답다”

Bling~ Man~

BioShock2

Halo3

Burn?

실제 화상에서는 어지갂히강한 빛이 아니면, 큰Glare가 나오지 않는다.

“발광 영역”- 장면의 하이라이트 되는 강도가 매우 강하

지 않게 되면, Dynamic Range가 부족하게

되므로, 강제로 Glare를 표현하기 위해서, Threshold를 낮춘다.

- 그 결과, 전체적으로 Glare가 적용되고,

색상 정보가 젂부 타듯이 날아가 버린다.

0.0 1.0 2.0

0.0 1.0 2.0

디퓨즈영역침범

발광 지점

[잘못된 Glare 사례]

충분한 Dynamic Range 확보 해야, 올바른 발광영역을 추출할 수 있다.

“SIGGRAPH 2010 Course:

Physically-Based Shading

Models in Film and Game

Production” 을 참고하세요!

휘도(Luminance)- 특정방향에서 표면으로부터의 단위지역당

빛의 정도. 즉, 색의 밝고 어두욲 정도를 말한다.

- Luminance를 사용하는데도 주의!

휘도(Luminance) 변홖- RGB를 Luminance로 변홖.

- Luminance = dot(RGB, float3(0.2125f, 0.7154f, 0.0721f));

- 결과는 “Lightness” 즉, 빛의 양!

- 변홖된 Luminance를 다시 RGB로 변홖을 할수 없다.- float Luminance = RGB2Lum(RGB);- float Bright = Luminance – Threshold;- float3 BrightColor = Bright * RGB; (X)

휘도(Luminance) 변홖- CIE Yxy Encoding을 이용하여 압축

- Y에 Luminance를 xy에 압축된 RGB 정보를~

- RGB -> CIE XYZ -> CIE Yxy 압축

- Luminance 계산 후, 다시 RGB로 변환

- 결과는 “Lightness” 즉, 빛의 양!

휘도(Luminance) 변홖- HSV 모델

- Hue, Saturate, Value(Bright)로 변홖.

- V = Max(R, G, B);

- 결과는 “Brightness”. 즉, Pixel의 밝기

Luminance HSV

Bloom 파이프라인

밝기 추출Gaussian

Blur

장면이미지

결과

고민이 생겼어요~!

“톤매핑” 후 “Bloom”을 해야 하나?

“Bloom” 후 “톤매핑”을 해야 하나?

다른 Post Processing은 어디어 들어가지?

DOF는?

Motion Blur는?

ColorCorrection은?

궁시렁~ 궁시렁~

HDR Bloom

HDR Bloom(Cont’)

- 모든 장면 파이프라인이 HDR

- 이상적인 형태의 파이프라인을 사용

HDR Bloom(Cont’)

- 모든 처리를 Floating Texture를 이용- 메모리 사용량

- 퍼포먼스 저하

- MSAA 지원 않함

LDR Bloom

LDR Bloom(Cont’)- 아마도 대부분이 사용하는 방식

- DX9 기반에서는 최적

- Floating Texture를 사용하지 않는다.- 메모리 사용량이 적다.

- 매우 빠르다.

- Hardware MSAA 지원

LDR Bloom(Cont’)- 톤매핑된 LDR 장면 + 톤매핑된 LDR Bloom

- [0, 1] + [0, 1] ?

- 디스플레이 장치에 의해 강제로 [0, 1]로 젃삭됨.

- LDR로 변홖되기 때문에, 이후 파이프라인에대해서, 고민을 많이 해야 한다.

- 현 세대 그래픽에서는 적젃한 선택- 퀄리티 와 퍼포먼스의 Trade Off

HDR 압축- LogLUV Encoding- 단, 알파를 사용할 수 없다!- xy: RGB 압축

- zw: 루미넌스 압축

- 장면을 축소할 때, 올바른 축소를 위해서, 축소필터적용- Gamma Space 축소(밉맵)과 동일한 이슈

- PC의 경우, Floating 텍스쳐와 압축 텍스쳐를적젃히 사용하면, 충분히 HDR 파이프라인을만들 수 있다.- “HDR 장면 렌더링(Floating) -> 압축 -> … -> 출력”

Flickering- Bloom과 같이 하이라이트를 너무 강하게

주면, 깜빡(Flicker)거리는 현상이 발생!

- 톤매핑 그래프와 유사하게 “밝기는 고휘도로 갈수록 조금씩 밝아진다”

- 젂형적인 지수(exponential) 그래프.

- Bloom의 결과에 적용해주면, 적당한선에서 깜빡이는 현상을 줄일 수 있다.

DepthOfField

[Depth Of Field]

DOF 의 제작 과정- 장면의 거리를 기반으로 얼마나 Blur를 적

용할 것인지를 결정한다.- Focus 영역 / Blur 영역

- Blur 영역은 Gaussian / Poisson Filter 등을이용하여, 주변 색상 평균을 취하여, Blur를적용.

- Blur 영역과 Focus 영역의 이미지를 합산

Artifacts

색상이묻어난다.

Color Bleeding

경계가뚜렷하다.

Discontinuity

젂경:뒤의 배경이비쳐진다.

Focus 영역: 깔끔하게!!

Bokeh

[Depth Of Field]

Solution?

[Siggraph08] Star Craft II

장면을 구분하자!- Focus 영역

- 기졲 장면

- Focus 보다 앞의 영역- Foreground Blur 장면

- Focus 보다 뒤의 영역- Background Blur 장면

Color Bleeding- 원경이미지를 Blur할 때, 주변 픽셀의 색상

을 샘플링 하여 평균을 내다 보니,

- Focus 영역에 인접한 픽셀의 색상이 같이포함되어 버림.

“Focus 영역의 픽셀의 색상이 포함되지 않게 하면 되겠네?”

해결 방안 1원경 (Focus < d) 인 영역만!!!- 주변을 샘플링할 때, Focus보다 거리가 Pixel들만 평균

- BUT,

- 같은 해상도의 이미지에서만 사용가능

- 작은 해상도에서 Sharp하게 Blur 이미지를 만들어도,

Upscale 되면서 미세하게나마 번질 수 밖에 없다.

해결 방안 2- 정규화!!!

- 순서- 원경 이미지만 마스킹

- Focus Weight가 0 ~ 1 사이인 영역

- [원경 이미지 RGB + Focus Weight]

- 원경 이미지(다욲사이즈)를 Gaussian Blur

- (업스케일된)Blur가 적용된 이미지 사용.

좀 더 자세히…- 기졲 방식과 동일하게 Gaussian Blur를 적

용한다.- 이 때, FocusWeight가 같은 가중치로…

- 다욲 스케일된 이미지도 상관없다. 어차피 같은 가중치로 FocusWeight도 적용된다.

- 최종 결과를 만들 때, “가중치가 적용된

FocusWeight”를 이용하여, 정규화!!!

- Background.rgb = Blurred.rgb / Blurred.w;

결과 비교

Discontinuity- Focus 영역과 Blur 영역이 구분되기 때문에

어쩔 수 없이 발생.

- Blurness를 확장.

사례 1- Blurriness -> 확장 -> filter

오즈라엘님의 구현사례ozlael.egloos.com

Bokeh

Bokeh- 화상에서 Out-Focus가 적용될 때, 조리개

의 형태나 Focus Distance. 즉, 렌즈에 따라발생하는 뿌옇게 보이는 효과

특성?!- 화상에서 상대적으로 빛이 강한 부분의

Bokeh가 눈에 많이 띈다.- Out-Focus 영역 중 렌즈로 들어오는 화상 중에서 빛이 강한 부분이 조리개의 모양으로 상에 맺히는 듯?!

- Bokeh의 크기는 거리에 따라 다르다?

Bokeh의 구현 방식- Geometry 방식

- 실제 Bokeh가 생길 영역 생성한다.

- Gather 방식- Bokeh 부분을 샘플링해서 원본 이미지와 합성

Gather 방식 (DX 9, 11)- So Cool~ 하게, 샘플링을 통해서, 구한다.

- Dynamic Range가 충분하다고 가정.

- Pixel Shader만 있으면 된다.

- CryEngine3의 사례

- Bokeh Filter를 만들어서 사용했다고 함.

Our simulation

Real photo

F2.8 F3.2 F3.5 F4 F5.6

GDC09- SO4_flexible_shader_managment_and_postprocessing

흉내 내보기- Gaussian Filter를 이용- Gaussian Filter를 Flat하게 만들어서 테스트- 완만하게…

- Specular를 강하게 하고,Blur를 적용하면…

- 대충 느낌은 나더라!- Filter를 설계할 수 있으면, 가능할 듯!!!!!!

- 하지만, 샘플링 한계는 어쩔?!

Geometry 방식- 물리적인 정확성

- Geometry Shader를 이용.

- 개요- “각 픽셀에 대해서, Bokeh Texture가 입혀진 사각형(Quad)를 렌더링한다 – 사마리안 데모 中”- CoC 크기를 이용해서, Quad의 크기와 투명도가 결정되고, Bokeh 텍스쳐에 의해 Pixel의 색상과 투명도가영향을 받는다.

Geometry 방식- DX9 기반에서, 어떻게 해야 할까?

- DX9에서는 동적으로 Quad를 만들 수가 없다는 것이 가장 큰 문제점!

- “그럼 Quad를 만들어 놓고 시작하면 되지 않을까?”

이런 패턴이라면…- 표현할 수 있을 정도로 “Downscale”된 장

면을 준비.

- 픽셀 당 하나의 단위 Quad를 미리 만들어놓는다.

- 버텍스 셰이더에서 조정할 수 있게 미리 버텍스들을 할당해둔다.

- 4 * w * h 만큼

- StreamFreq를 이용하면, 4 * w + h 로 줄일 수 있음

이런 패턴이라면…(Cont’)- Vertex Texture Fetch를 사용.

- CoC 등의 정보를 얻어와 버텍스 셰이더에서, Quad의 크기를 조정한다.

- CoC 크기가 일정량 이상만 처리되도록…

- Pixel Shader에서 보케 텍스쳐를 적용

Conclusion

Full HDR Pipeline- 올바른 HDR 렌더링 파이프라인 구축으로,

충분한 Dynamic Range가 사실적인 렌더링의 밑바탕에 깔려있다.

- Bloom, DOF, MotionBlur등 파이프라인이확장되면 될수록, 그 결과는 점점 더 차이가많이 벌어진다.

세대가 변하고 있다!!!

Film Realistic- Photo Realistic 시대를 지나서, 이제는 단

지 그래픽이 좋은 것이 아니라, 물리적으로 올바른 극 사실적인 그래픽을 표현해낸다.

- 추가적으로, 영상미를 추구하기 시작

- 게임이 영화화 되어 가는 듯?!

- DX11의 보편화 시점에서는 본격화 예상

HDR은끝이 아닌

시작

Q & A

Reference- http://filmicgames.com/archives/category/gamma

- http://filmicgames.com/archives/category/tonemapping

- [SIGGRAPH06] HDRInValvesSourceEngine

- [GDC08] PostProcessingInTheOrangeBox

- [GDC09] Uncharted2_HDRLighting

- http://cagetu.egloos.com/5373181에 다량 첨부.

- [SIGGRAPH10] “Physically Based Shading Models”

- Epic Games – Samaritan Demo

- CryEngine3 – 차세대 기술 Feature들- [GDC04] Advanced Depth Of Field

- 오즈라엘님 블로그 - Depth Of Field

- Gpu Gem3 – Practical PostProcess Depth Of Field

- StarCraft2 – 기술문서

Reference- http://en.wikipedia.org/wiki/Luma_(video)

- http://en.wikipedia.org/wiki/HSL_and_HSV