Ndc11 이창희_hdr

올바른 HDR 을 이용한
Bloom 과 DOF

㈜소프트네트
이창희
cagetu@softnette.com

이창희
(@cagetu)
- 소프트네트
- CCR
- Hi-Win
- Netmarble(現, CJ E&M)
- DreamSEED
- SAMSONCORE

왜 입체감이 잘 안 살지?
내가 만든 건 왜 이래?!

기능을 늘려도, 별로…

High-Quality Graphic ?

힘의 원천은 뭘까?

나름 결롞은 HDR

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

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

HDR in Game
- “장면의 고휘도 값을 렌더링 파이프라인
젂체에 유지하고, 그 결과를 디스플레이
장치에 출력할 수 있는 범위로 압축하는
과정”

쉽게 말하면,
- [0, 1] 이상의 범위를 가지는 장면을 렌
더링하고, 색상의 손상 없이 모니터에
출력하는 것

- HDR 장면를 LDR로 압축

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

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

개인적으로,

올바른 HDR ?
In Game

개인적으로,

“색상의 풍부함”을 기
반으로 표현범위를 넓혀
준다.

Photo
Realistic
물리적으로 올바른 표현

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

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_POSTBLENDSRGBCONVE
RT 가 지원한다면, DX9에서 지원하는 sRGB 기능
을 사용
- DX9 GPU에서는 감마 보정 연산(sRGB)이 된 이후에
FrameBuffer Blending을 실행한다.

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

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

올바른 샘플링
float4 sourceSamples[4];
float4 finalSample = 0;
for (int i = 0; i < 4; i++)
finalSample += sourceSample[i];
finalSample /= 4;
return sourceSample;

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);

올바른 밉맵 설정
- Photoshop DDS 플러그인
- MIPMAP 설정 시, Gamma
Correct값을 적용할 수 있음

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

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

Linear-Space Lighting: Conclusion
“Drake! You must believe in linear-space lighting!”

[Uncharted 2 : HDR Lighting]에서 발췌

톤 매핑의 정의
“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 방식과
유사하게 타들어가는 것을 방지
하고, 어두워질수록 어두욲 부분이
완젂 어두워지도록 만든다.

Flimic Tonemapping
- 일반 영역
- Reihard보다 좀
더 밝게~~~

- 낮은 영역
- Reihard보다 더
어두욲 쪽으로 급
격히…

- GDC 발표 자료 참고
- EA에서 귺무하시는 Jim Hejl님이 만드심
- 사용해도 돈은 안 받는다고 함.
- 너무 Constrast가 강하다!

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

기타 연산자
- Linear Tonemapping
- Logarithmic / Exponential Tonemapping
- 로그와 지수 그래프의 성질을 이용
- 실제 카메라 회사의 Tone-Curve 그래프를
이용해서, 적용해보기 한다.
- 자싞만의 느낌을 살리기 위해서, Tone-
Curve를 만들어 내기도 한다.

톤매핑과 색상 보정
- 후처리 색상 보정은 디지털 시대의 사진과
영상쪽에서는 이미 보편화된 기술
- 게임에서도 최종 장면의 색상 조정을 통해
서, 영화와 같은 연출
- 마비노기 영웅젂의 사례
- 색상 보정을 한다면, 톤매핑을 단순하게 하
는 것이 좋다.
- 선형 톤매핑 + Color Correction(Color Grading)

그 밖에 톤매핑 이슈
- 평균 밝기(Luminance) 구하기
- 노출 보정
- 광적응 효과

아쉽지만 다음기회에

“Bloom”
- 강한 빛이 눈에 들어왔을 때, 빛이 번지는
것과 같은 현상을 말함.

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

아름다운 Bloom?
- 빛이나 재질에 따라 자연스럽게 발생하는..
- 재질의 색상이 부드럽게 번지는 듯 한
- 젂체적으로 “Bling~ Bling~” 해지는 듯 한
: 이런 뭔가 느낌적인 느낌?! 감각적인 감각?!

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

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

“발광 영역”
- 장면의 하이라이트 되는 강도가 매우 강하
지 않게 되면, Dynamic Range가 부족하게
되므로, 강제로 Glare를 표현하기 위해
서, Threshold를 낮춘다.
- 그 결과, 전체적으로 Glare가 적용되고,
색상 정보가 젂부 타듯이 날아가 버린다.

디퓨즈
영역
침범

0.0 1.0 2.0

발광 지점

0.0 1.0 2.0

충분한 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)

- CIE Yxy Encoding을 이용하여 압축
- Y에 Luminance를 xy에 압축된 RGB 정보를~
- RGB -> CIE XYZ -> CIE Yxy 압축
- Luminance 계산 후, 다시 RGB로 변환

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

- HSV 모델
- Hue, Saturate, Value(Bright)로 변홖.
- V = Max(R, G, B);

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

Bloom 파이프라인
Gaussian
밝기 추출
Blur

장면
이미지

결과

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

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

고민이 생겼어요~!
다른 Post Processing은 어디어 들어가지?

DOF는? ColorCorrection은?
Motion Blur는?
궁시렁~ 궁시렁~

HDR Bloom(Cont’)
- 모든 장면 파이프라인이 HDR
- 이상적인 형태의 파이프라인을 사용

HDR Bloom(Cont’)
- 모든 처리를 Floating Texture를 이용
- 메모리 사용량
- 퍼포먼스 저하
- MSAA 지원 않함

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의 결과에 적용해주면, 적당한
선에서 깜빡이는 현상을 줄일 수 있다.

DOF 의 제작 과정
- 장면의 거리를 기반으로 얼마나 Blur를 적
용할 것인지를 결정한다.
- Focus 영역 / Blur 영역
- Blur 영역은 Gaussian / Poisson Filter 등을
이용하여, 주변 색상 평균을 취하여, Blur를
적용.
- Blur 영역과 Focus 영역의 이미지를 합산

Color Bleeding

색상이
묻어난다.

Discontinuity
경계가
뚜렷하다.

[Depth Of Field]

Focus 영역 Bokeh
: 깔끔하게!!

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

장면을 구분하자!
- 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
- 화상에서 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를 만들어서 사용했다고 함.

Real photo

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

Our simulation

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에서 보케 텍스쳐를 적용

Full HDR Pipeline
- 올바른 HDR 렌더링 파이프라인 구축으로,
충분한 Dynamic Range가 사실적인 렌더링
의 밑바탕에 깔려있다.

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

Film Realistic
- Photo Realistic 시대를 지나서, 이제는 단
지 그래픽이 좋은 것이 아니라, 물리적으
로 올바른 극 사실적인 그래픽을 표현해
낸다.
- 추가적으로, 영상미를 추구하기 시작
- 게임이 영화화 되어 가는 듯?!
- DX11의 보편화 시점에서는 본격화 예상

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

Ndc11 이창희_hdr

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Ndc11 이창희_hdr

Ähnlich wie Ndc11 이창희_hdr (20)

Mehr von changehee lee

Mehr von changehee lee (20)

Ndc11 이창희_hdr