이 절에서는 인코더 동작에 대한 요구사항과 권장사항을 제공합니다. PNG 인코더는 앞선 절들에서 규정된 형식에 부합하는 PNG 이미지를 입력으로 하여 PNG 데이터스트림을 생성해야 합니다.
추가로 이곳에 제시된 권장사항을 따르면 보통 최상의 결과를 얻을 수 있습니다.
감마 문제에 대한 간단한 소개는 C. 감마와 색도를
참고하세요.
완전한 색 관리가 가능한 PNG 인코더는 여기서 설명한 것보다 더 정교한 계산을 수행할 수 있으며 iCCP 청크를 사용할 수
있습니다. 이미지 샘플이 sRGB 규격을 준수하는 것으로 알려진 경우 [SRGB]
인코더는 추가적인 감마
처리 없이 sRGB 청크를 쓰는 것을 강력히 권장합니다. 두 경우 모두, iCCP 또는 sRGB 청크를 인식하지 못하는 PNG 디코더에서 사용할 수 있도록 적절한 gAMA 청크를 생성하는 것이 권장됩니다.
PNG 인코더는 다음을 결정해야 합니다:
- gAMA 청크에 어떤 값을 쓸지;
- 제공된 이미지 샘플을 PNG 데이터스트림에 기록될 값으로 어떻게 변환할지.
gAMA 청크에 쓸 값은 PNG 디코더가 원하는 방식으로 동작하도록 만드는 값입니다. 자세한 사항은 13.13 디코더 감마 처리를
보십시오.
적용할 변환은 이미지 샘플의 성격과 정밀도에 따라 달라집니다. 샘플이 부동소수점 또는 고정밀 정수 형태로 광 강도를 나타낸다면(예: 컴퓨터 그래픽 렌더러 출력), 인코더는 정수를 PNG
데이터스트림에 포함하기 전에 감마
인코딩(지수값이 1보다 작은 거듭제곱 함수 적용)을 수행할 수 있습니다. 이는 주어진 샘플 깊이에서 밴딩 아티팩트를 줄이거나 동일한 시각적 품질을 유지하면서 샘플을 작게
유지할 수 있게 합니다. 범위 0에서 1의 부동소수점 intensity 값은 다음과 같이 데이터스트림 이미지 샘플로 변환할 수 있습니다:
integer_sample = floor((2sampledepth-1) * intensityencoding_exponent + 0.5)
만약 식의 intensity가 원하는 출력 휘도라면, encoding exponent는 gamma value로서 gAMA 청크에 사용됩니다.
만약 인코더에 주어진 intensity가 원래 장면의 휘도라면, 다른 변환이 필요할 수 있습니다. 때때로 표시된 이미지는 원본보다 더 높은 대비를 가지도록 요구됩니다. 이는
원장(scene)에서 표시 출력까지의 end-to-end 전달 함수가 1보다 큰 지수를 갖는 경우에 해당합니다. 이 경우:
gamma = encoding_exponent/end_to_end_exponent
원래 이미지가 캡처되거나 계산된 조건이 그러한 대비 변화를 정당화하는지 알 수 없으면, 표시 휘도가 원래 장면 휘도에 비례한다고 가정할 수 있습니다. 즉 end-to-end
exponent를 1로 가정하면:
gamma = encoding_exponent
이미지가 데이터스트림으로만 기록되는 경우, 인코더는 인코딩 지수를 자유롭게 선택할 수 있습니다. 그 값이 감마 값이 gAMA 청크에서 1/2.2가 되도록 하는 선택은 전형적인 비디오 모니터에 이미지를 표시하는 PNG 디코더의 작업을 최소화하므로 종종 합리적인
선택입니다.
어떤 이미지 렌더러는 이미지를 PNG 데이터스트림에 쓰는 동시에 화면에 표시할 수 있습니다. 표시되는 픽셀은 사용 중인 표시 시스템과 시청 조건에 대해 감마 보정되어야 하며, 사용자가 의도한 장면을 적절히
보도록 해야 합니다.
렌더러가 화면에 표시된 샘플 값을 그대로 PNG 데이터스트림에 쓰고 데이터스트림에 대한 별도의 감마 인코딩 단계를 피하려면, 렌더러는 표시 시스템의 전달 함수를 거듭제곱 함수로 근사하고, 지수의 역수를 gAMA 청크에 기록해야 합니다. 이렇게 하면 PNG 디코더가 렌더링 중에 원작자가 화면에서 본 것을 재현할 수 있습니다.
그러나 렌더러가 표시 장치에 적합한 표시 픽셀을 계산하고 데이터 저장 및 전송을 위해 별도의 감마 인코딩을 수행하여 나중에 이미지를 사용할 때 더 적절한 gAMA 값을 갖게 하는 것도 합리적입니다.
컴퓨터 그래픽 렌더러는 종종 감마 인코딩을 수행하지 않고 샘플 값을 장면 광 강도에 비례하도록 만듭니다. PNG 인코더가 이미 정수로
양자화된 샘플 값을 받으면, 그 값에 대해 감마 인코딩을 수행하는 것은 추가적인 정보 손실만 초래하므로 의미가 없습니다. 인코더는 단순히 샘플 값을 PNG
데이터스트림에 기록해야 합니다. 이는 gAMA 청크의 값이 1.0이어야 함을 의미하지는 않습니다. 장면 휘도에서 표시
출력까지의 원하는 end-to-end 전달 함수가 반드시 선형인 것은 아니기 때문입니다. 그러나 원하는 gamma value는 아마 1.0에 그리 멀지 않을 것입니다. 이는 렌더링된 장면이 야외 일광 장면인지 실내
장면인지 등에 따라 달라질 수 있습니다.
샘플 값이 하드웨어에서 직접 나오는 경우, 올바른 gAMA 값은 원칙적으로 하드웨어의 전달 함수와 장면의 조명 조건으로부터 추론될 수 있습니다. 비디오 디지타이저("프레임 그래버")의 경우
샘플은 대개 sRGB 색 공간에 있을 가능성이 높습니다. 이미지 스캐너는 덜 예측 가능합니다. CCD 센서는 본래 선형이므로 출력 샘플이 입력 광 강도에 비례할 수 있고, 또는 스캐너
하드웨어가 인쇄의 도트게인을 보정하기 위해 약한 거듭제곱 함수를 이미 적용했을 수도 있으며(지수 약 0.57), 혹은 스캐너가 표시를 위해 샘플을 보정했을 수도 있습니다. 특정 스캐너의
특성을 알기 위해서는 스캐너 매뉴얼을 참고하거나 교정 대상(caledibrated target)을 스캔해야 할 수도 있습니다. 감마는 샘플과 원하는 표시 출력 간의 관계를 다룬다는
점을 기억하세요.
데이터스트림 형식 변환기는 일반적으로 공급된 이미지를 다른 감마로 변환하려고 시도해서는 안 됩니다. 데이터는 변환 없이 PNG 데이터스트림에 저장되어야 하며, 가능한 경우 원본
데이터스트림의 정보를 바탕으로 gamma value를 유추해야 합니다. 데이터스트림 변환 시의 감마 변경은 표현되는 강도 수준 집합의 재양자화를
초래하여 거의 이득 없이 반올림 오차를 추가합니다. 따라서 입력에서 출력으로 샘플 값을 그대로 복사하는 것이 거의 항상 바람직합니다.
원본 데이터스트림이 이미지의 감마 특성을 설명하는 경우, 데이터스트림 변환기는 gAMA
청크를 쓰는 것이 강력히 권장됩니다. 일부 데이터스트림 형식은 표시 지수(이미지 샘플을 표시 출력으로 매핑하는 함수의 지수)를 명시합니다. 원본 파일의 gamma value가 1.0보다 크다면, 이는 아마도 표시 지수일 가능성이 높고, PNG의 gamma value로는 그 역수를 사용해야 합니다. 원본 파일 형식이 이미지 샘플과 표시 출력 이외의 양 사이의
관계를 기록한다면, PNG gamma value를 유추하는 과정은 이보다 복잡할 것입니다.
PNG 인코더나 데이터스트림 변환기가 표시 시스템의 전달 함수를 display_exponent로 근사할 수 있고 그 시스템에서 만족스럽게 이미지가
표시되었음을 알고 있다면, 이미지는 다음과 같은 gamma value로 표시할 수 있습니다:
gamma = 1/display_exponent
정확히 맞는 값을 쓰는 것보다 근사치라도 gAMA 청크를 쓰는 편이 낫습니다. 디코더가 근사값을 추측하도록 강요하는 것보다는
낫습니다. PNG 인코더가 gamma value를 유추할 수 없다면 gAMA
청크를 생략하는 것이 바람직합니다. 만약 추측을 해야 한다면, 이는 PNG 디코더에 맡기는 것이 좋습니다.
감마는 알파 샘플에는
적용되지 않습니다; 알파는 항상 선형으로 표현됩니다.
또한 13.13 디코더 감마 처리를
보십시오.
색 문제에 관한 참조는 C. 감마와 색도를 보십시오.
완전한 색 관리를 수행할 수 있는 PNG 인코더는 여기에서 설명한 것보다 더 정교한 계산을 수행할 수 있으며 iCCP 청크를
사용할 수 있습니다. 이미지 샘플이 sRGB 규격을 준수하는 것으로 알려진 경우 [SRGB]
PNG 인코더는 sRGB 청크를 사용하는 것이 강력히 권장됩니다.
인코더가 소스 디스플레이 프라이머리의 색도(chromaticities)를 결정할 수 있거나 이미지의 출처나 실행 중인 하드웨어에 근거하여 강한 추정을 할 수 있다면, 인코더는 cHRM 청크를 출력하는 것이 강력히 권장됩니다. 그렇게 한다면 gAMA 청크도 함께 써야 합니다; gAMA 청크가 없으면 디코더는 cHRM 청크로 할 수 있는 것이 거의 없습니다.
프라이머리와 화이트 포인트에 대한 여러 권장 사항과 표준이 있으며, 일부는 특정 기술과 연관됩니다. 예를 들어 CCIR 709
표준 [ITU-R-BT.709]
및 SMPTE-C 표준 [SMPTE-170M]
등이 있습니다.
고려해야 할 경우는 세 가지입니다:
- 인코더가 생성 시스템의 일부인 경우;
- 원본 이미지가 카메라나 스캐너로 캡처된 경우;
- PNG 데이터스트림이 다른 형식에서 변환되어 생성된 경우.
손으로 그리거나 디지털로 편집된 이미지의 경우, 제작 시 어떤 모니터에서 보았는지를 결정할 필요가 있습니다. 많은 이미지 편집 프로그램은 사용 중인 모니터 유형을 지정할 수 있게 합니다.
이는 내부적으로 장치 독립적인 공간에서 작업하기 때문인 경우가 많습니다. 그러한 프로그램은 유효한 cHRM 및 gAMA 청크를 쓸 수 있는 충분한 정보를 가지고 있으므로 자동으로 작성하는 것이 강력히 권장됩니다.
인코더가 전체 스펙트럼 렌더링을 수행하는 컴퓨터 이미지 렌더러의 일부로 컴파일되어 있다면, 내부의 장치 독립 색 공간에서 RGB로 변환할 때 사용된 모니터 값을 cHRM 청크에 기록해야 합니다. 선택된 RGB 장치의 색역 밖에 있는 색상은 색역 내로 매핑되어야 합니다; PNG는
색역 밖 색상을 저장하지 않습니다.
컴퓨터 이미지 렌더러가 장치 종속 RGB 공간에서 직접 계산을 수행하는 경우, 장면 설명 및 렌더링 매개변수가 특정 모니터에 맞게 조정되지 않았다면 cHRM 청크는 작성해서는 안 됩니다. 그런 경우 해당 모니터에 대한 데이터를 사용하여 cHRM 청크를 구성해야 합니다.
몇몇 이미지 형식은 보정(calibration) 정보를 저장할 수 있으며, 이를 사용해 cHRM 청크를 채울 수 있습니다.
예를 들어 TIFF 6.0 파일 [TIFF-6.0]는 선택적으로 보정 정보를 저장할 수 있으며, 존재한다면 이를 사용하여 cHRM 청크를 구성해야 합니다.
최근 비디오 장비로 생성된 비디오는 대개 CCIR 709 프라이머리와 D65 화이트 포인트를 사용하며 [ITU-R-BT.709]
이 값들은 Table 29에 제공됩니다.
Table 29
CCIR 709 프라이머리와 D65 화이트포인트
| |
R |
G |
B |
White |
| x |
0.640 |
0.300 |
0.150 |
0.3127 |
| y |
0.330 |
0.600 |
0.060 |
0.3290 |
오래되었지만 여전히 널리 사용되는 비디오 표준으로 SMPTE-C [SMPTE-170M]가
있으며, 이는 Table 30에 나와 있습니다.
Table 30
SMPTE-C 비디오 표준
| |
R |
G |
B |
White |
| x |
0.630 |
0.310 |
0.155 |
0.3127 |
| y |
0.340 |
0.595 |
0.070 |
0.3290 |
데이터스트림 형식 변환기가 공급된 이미지를 다른 RGB 색 공간으로 변환하려고 시도하는 것은 권장되지 않습니다. 데이터는 변환 없이 PNG 데이터스트림에 저장되어야 하며, 알려진 경우 원본
프라이머리 색도를 기록해야 합니다. 데이터스트림 변환 시의 색 공간 변환은 색역 불일치와 반올림 오류 때문에 나쁜 아이디어입니다. 감마 변환과 마찬가지로, 데이터는 무손실로 저장하고
최종적으로 이미지를 표시할 때 한 번의 변환만 하는 것이 낫습니다.
또한 13.14 디코더 색상 처리를
보십시오.
알파 채널은 투명한 부분을 일시적으로 숨기는 마스크로 보거나 비직사각형 이미지를 구성하는 수단으로 볼 수 있습니다. 첫 번째 경우에는 완전 투명한 픽셀의 색상 값은 향후 사용을 위해
보존되어야 합니다. 두 번째 경우에는 투명 픽은 유용한 데이터를 가지지 않으며 PNG가 요구하는 직사각형 이미지 영역을 채우기 위해 단순히 존재합니다. 이 경우에는 최적의 압축을 위해
모든 완전 투명 픽에 동일한 색상 값을 할당해야 합니다.
이미지 작성자는 디코더가 투명도 처리를 완전히 지원하지 않을 가능성을 염두에 두어야 합니다(참조: 13.16 알파 채널 처리). 따라서 가능하다면 투명 픽에 지정된 색상은 합리적인 배경 색상이어야
합니다.
완전한 알파 채널이 필요 없거나 압축 효율상 비용을 감당할 수 없는 응용을 위해 tRNS 투명도 청크도 사용할 수 있습니다.
이미지에 알려진 배경 색이 있다면 이 색은 bKGD 청크에 기록해야 합니다. 투명도를 무시하는 디코더도 bKGD 색을 사용해 남는 화면 영역을 채울 수 있습니다.
원래 이미지가 사전 곱해진(premultiplied, associated) 알파 데이터를 가지고 있다면, 각 샘플 값을 해당 알파 값으로 나눈 다음 이미지 비트 깊이에 대한 최대값을 곱하고
가장 가까운 정수로 반올림하여 PNG의 비사전곱(non-premultiplied) 형식으로 변환할 수 있습니다. 유효한 사전 곱 데이터에서는 샘플 값이 해당 알파 값을 초과하지 않으므로
나눗셈 결과는 항상 0에서 1 범위여야 합니다. 알파 값이 0이면 출력은 검정(0)으로 합니다.
PNG에서 직접 표현할 수 없는 샘플 비트 깊이를 가진 입력 샘플을 인코딩할 때, 인코더는 샘플을 PNG에서 허용되는 샘플 비트 깊이로 스케일 업해야 합니다. 가장 정확한 스케일 방법은
다음의 선형 방정식입니다:
output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5)
여기서 입력 샘플은 0에서 MAXINSAMPLE 범위이고 출력은 0에서 MAXOUTSAMPLE 범위입니다(후자는
2sampledepth-1임).
"왼쪽 비트 복제(left bit replication)"는 선형 스케일 방법을 근사하는 방법으로, 유효한 비트들을 최상위 비트부터 이동시키고 최상위 비트를 빈 비트에 반복하여 채웁니다.
이 방법은 선형 스케일보다 계산이 빠른 경우가 많습니다.
예를 들어 5비트 샘플을 8비트로 스케일한다고 가정합니다. 소스 샘플 값이 27(0-31 범위)이라면 원래 비트는:
4 3 2 1 0
---------
1 1 0 1 1
왼쪽 비트 복제는 222의 값을 줍니다:
7 6 5 4 3 2 1 0
----------------
1 1 0 1 1 1 1 0
|=======| |===|
| Leftmost Bits Repeated to Fill Open Bits
|
Original Bits
이는 선형 방정식으로 계산한 값과 일치합니다. 왼쪽 비트 복제는 보통 선형 스케일과 동일한 값을 주며, 절대 오차는 1을 넘지 않습니다.
덜 정확한 근사는 입력 값을 왼쪽으로 이동시키고 낮은 자리 비트를 0으로 채우는 방법입니다. 이 방식은 최대값에 해당하는 전부 1 비트를 생성하지 못하므로 정확한 흰색을 재현하지 못해
이미지가 약간 어두워지는 효과가 있습니다. 일반적으로 권장되지는 않지만, 특히 8비트 초과 샘플 깊이를 다룰 때 압축을 개선하는 효과가 있습니다. 높은 샘플 깊이에서는 zero-fill로
인한 상대 오차가 작으므로 일부 인코더는 이를 선택할 수 있습니다. 그러나 zero-fill은 많은 디코더가 알파 값이 전부 0이거나 전부 1인 경우를 특수 처리하기 때문에 알파 채널
데이터에 대해서는 사용해서는 안 됩니다. 스케일된 데이터에서 이 값들을 정확히 표현하는 것이 중요합니다.
인코더가 sBIT 청크를 쓸 때는 저장된 샘플의 최상위 비트가 원본 데이터와 일치하도록 스케일링해야 합니다. 즉, sBIT가 S를 지정하면 저장된 데이터의 최상위 S비트는 원래 S비트 데이터 값과 일치해야 합니다. 이는 디코더가
오른쪽으로 시프트하여 원본 데이터를 복원할 수 있게 합니다. 추가된 저위 비트들은 제약을 받지 않습니다. 앞서 언급한 모든 스케일링 방법은 이 제약을 만족합니다.
소스 이미지 데이터를 스케일 업할 때, 저위 비트는 모든 샘플에 대해 일관되게 채우는 것이 권장됩니다; 즉 동일한 소스 값은 모든 픽 위치에서 동일한 샘플 값을 생성해야 합니다. 이는 서로
다른 샘플 값의 수를 줄여 압축을 개선합니다. 이는 필수는 아니며 일부 인코더는 이를 따르지 않을 수 있습니다. 예를 들어 인코더는 저위 비트를 디더링하여 표시 품질을 향상시키는 대신
파일 크기를 증가시킬 수 있습니다.
일부 응용에서는 원본 소스 데이터 범위가 2의 거듭제곱이 아닐 수 있습니다. 이 경우에도 선형 스케일 방정식은 작동하지만 비트 시프트 방식은 작동하지 않습니다. 이러한 이미지에 대해 sBIT 청크를 쓰지 않는 것이 권장됩니다. sBIT는
원본 데이터 범위가 정확히 0..2S-1이었음을 암시하기 때문입니다.
제안된 팔레트는 어떤 PNG 데이터스트림에서는 sPLT 청크로, 또는 PLTE 청크로 truecolor PNG 데이터스트림에 나타날 수 있습니다. 어느 경우든 제안된 팔레트는 image
data의 필수 구성 요소는 아니지만, 인덱스-컬러 디스플레이 하드웨어에서 이미지를 표시하는 데 사용될 수 있습니다. 제안된 팔레트는 truecolour 하드웨어에서 실행되는 뷰어에는 관련이 없습니다.
sPLT 청크로 권장 팔레트를 제공할 경우, 인코더는 빈도 필드(frequency fields)를 모두 0으로 두지 말고
팔레트 항목의 상대적 중요도를 나타내도록 사용하는 것이 권장됩니다. 빈도 값은 근사적으로 "최근접 이웃" 카운트로 계산하는 것이 가장 쉬운데, 즉 디더링이 적용되지 않았을 때 각 RGBA
팔레트 항목의 사용량을 근사하는 값입니다(이 값들은 권장 팔레트를 개발할 때 종종 "무료로" 얻을 수 있습니다). 권장 팔레트는 투명 정보를 포함하므로 합성되지
않은(un-composited) 이미지에 대해 계산해야 합니다.
인덱스 컬러 이미지의 경우에도 sPLT는 모든 색을 표시할 수 없는 뷰어를 위해 대체 축소 팔레트를 정의하는 데 사용할 수
있습니다. PLTE 청크가 나타나되 bKGD 청크가 없는
경우, 색 팔레트가 계산된 상황은 명시되지 않습니다.
truecolor PNG 데이터스트림에 권장 팔레트를 포함하는 오래된 방법은 PLTE 청크를 사용하는 것입니다. 이 방법을
사용할 경우 히스토그램(빈도)은 별도의 hIST 청크에 나타나야 합니다. PLTE 청크는 투명 정보를 포함하지 않으므로, color type 6(truecolor with alpha) 이미지의 경우 bKGD 청크가 나타나고 팔레트와 히스토그램은 지정된 배경 색으로 합성된 이미지에 기초하여 계산되는 것이 권장됩니다. 이는 분수 알파 값을 가지는
픽셀에 대해 유용한 팔레트 항목이 생성되도록 하기 위해 필요합니다. 생성된 팔레트는 동일한 배경 색을 사용하는 뷰어에만 유용할 가능성이 높습니다. PNG
편집기가 bKGD 청크를 변경하거나 삭제하면 해당 팔레트를 삭제하거나 재계산하는 것이 권장됩니다.
color
type 2(truecolor) 이미지의 경우, PLTE 및 hIST 청크는 투명-색 지정은 무시하고 RGB 데이터만을 기준으로 계산하는 것이 권장됩니다. 데이터스트림이 투명도를
사용하면(tRNS 청크가 있는 경우) 뷰어는 생성된 팔레트를 의도한 배경 색에 맞게 쉽게 조정할 수 있습니다(참조: 13.17 히스토그램
및 권장 팔레트 사용).
권장 팔레트를 제공할 때 sPLT 청크는 다음과 같은 점에서 PLTE 청크보다 유연합니다:
- sPLT를 사용하면 여러 권장 팔레트를 제공할 수 있습니다. PNG 디코더는 이름이나 항목 수를 기준으로 적절한
팔레트를 선택할 수 있습니다.
- 데이터스트림이 color type 6(truecolor with
alpha)인 경우 PLTE 청크는 이미 bKGD 색에 대해 합성된 팔레트를
나타내므로 특정 배경 색에 대해서만 유용합니다. 반면에 sPLT는 합성되지 않은 팔레트를 제공하여 디코더가 선택한
배경에 유용합니다.
- sPLT는 보조(ancillary) 청크이므로, PNG 편집기가 안전-복사
불가(unsafe-to-copy)가 아닌 알려지지 않은 청크를 버리지 않고도 권장 팔레트를 추가하거나 수정할 수 있습니다.
- sPLT는 색상 타입 0, 3, 4(그레이스케일 및 인덱스 컬러)에 대해서도 허용되는
반면, PLTE는 이러한 경우에 축소 팔레트를 제공할 수 없습니다.
- sPLT에는 256개 초과의 항목이 나타날 수 있습니다.
sPLT 청크를 사용하는 PNG 인코더는, sPLT를
인식하지 못하는 디코더와의 호환성을 위해 PLTE 및 hIST 청크로 표현된 권장 팔레트를 함께 쓸 수 있습니다.
이 명세는 두 가지 인터레이스 방식을 정의하며 그중 하나는 인터레이스 없음입니다. 인터레이싱은 디코더가 이미지를 점진적으로 표시할 수 있는 편리한 기초를 제공합니다(참조: 13.10 인터레이싱 및 점진적 표시).
color
type 3(인덱스 컬러) 이미지의 경우, 필터 타입 0(None)이 보통 가장 효과적입니다. 색상이 256개 이하인 컬러 이미지는 거의 항상 인덱스
컬러 형식으로 저장하는 것이 좋습니다; truecolor 형식은 훨씬 더 커질 가능성이 큽니다.
비트 깊이가 8 미만인 이미지에는 필터 타입 0이 권장됩니다. 저비트 깊이 그레이스케일 이미지의 드문 경우에는 먼저 이미지를 8비트로 확장한 다음 필터링을 적용하면 더 나은 압축을 얻을 수
있습니다.
truecolor
및 그레이스케일 이미지의 경우 다섯 가지 필터 중 어느 것이 가장 효과적일지 상황에 따라 다릅니다. 인코더가 고정 필터를
사용할 경우 Paeth 필터 타입이 보통 가장 좋습니다.
truecolor
및 그레이스케일 이미지의 최적 압축을 위해, 그리고 압축 효율을 속도보다 우선시하는 경우에는 스캔라인마다 필터 타입을
선택하는 적응형 필터링이 권장됩니다. 각 이미지는 최적으로 작동하는 서로 다른 필터 집합을 가집니다. 인코더는 주어진 이미지에 대해 압축이 가장 좋은 모든 필터 조합을 시도할 수
있습니다. 그러나 전수 탐색이 허용되지 않는 경우, 다음과 같은 일반적 휴리스틱이 충분히 잘 동작할 수 있습니다: 다섯 가지 필터로 출력 스캔라인을 계산하고 출력 바이트의 절대값 합이
가장 작은 필터를 선택합니다(이 테스트에서는 출력 바이트들을 부호 있는 차이로 간주). 이 방법은 보통 단일 고정 필터를 선택하는 것보다 더 나은 성능을 냅니다.
이 권장에 따른 필터링은 이 명세에서 정의한 두 가지 인터레이스 방법 중 어느 것과도 함께 효과적입니다.
인코더는 압축된 데이터스트림을 원하는 방식으로 IDAT 청크로 분할할 수 있습니다. (여러 IDAT 청크는 인코더가 고정된 메모리 양으로 작업할 수 있게 허용합니다; 보통 청크 크기는 인코더의 버퍼 크기에 대응합니다.) 각 IDAT 청크가 단 하나의 데이터 바이트만 포함하는 PNG 데이터스트림도 유효하지만 공간을 극도로 낭비합니다. (제로 길이 IDAT 청크도 유효하지만 더 많이 낭비됩니다.)
각 텍스트 청크에는 비어 있지 않은 키워드가 제공되어야 합니다. 더 나은 설명이 없다면 일반 키워드 "Comment"를 사용할 수 있습니다. 사용자 제공 키워드를 사용하는 경우 인코더는
해당 키워드가 키워드 제한을 충족하는지 확인해야 합니다.
iTXt 청크는 유니코드의 UTF-8 인코딩을 사용하므로 어떤 언어의 텍스트도 저장할 수 있습니다. tEXt 및 zTXt 청크는 Latin-1(ISO
8859-1) 문자 인코딩을 사용하여 이들 청크에서 사용 가능한 문자의 범위를 제한합니다. 인코더는 데이터 손실 없이 넓은 문자 범위를 허용하기 위해 iTXt를 tEXt 및 zTXt보다 선호해야 합니다. 인코더는 로컬 레거시 문자 인코딩을 사용하는 문자를
저장할 때 적절한 인코딩으로 변환해야 합니다.
iTXt 청크를 생성할 때 인코더는 Encoding Standard의 UTF-8
encode를 따라야 합니다.
인코더는 읽기 편의를 돕기 위해 79 유니코드 코드 포인트보다 긴 단일 라인의 텍스트 생성을 억제해야 합니다.
길이 1024 바이트 미만의 텍스트 항목은 비압축 텍스트 청크로 출력하는 것이 권장됩니다. 기본 제목과 작성자 키워드는 비압축 텍스트 청크로 출력하는 것이 권장됩니다. 큰 텍스트 청크를
이미지
데이터(IDAT 청크 이후)에 배치하면 몇몇 상황에서 이미지 표시 속도를 높일 수 있습니다. 디코더가 먼저
이미지
데이터를 디코딩하기 때문입니다. 이미지 제목과 같은 작은 텍스트 청크는 IDAT 청크 앞에 위치시키는 것이
권장됩니다.
인코더는 다른 애플리케이션이 이해할 필요가 없는 정보를 담기 위해 비공개 청크를 사용할 수 있습니다(MAY).
인코더는 실험적 또는 비공개 용도로 비예약된 필드 값을 사용할 수 있습니다(MAY).
모든 보조 청크는 선택 사항이며, 인코더가 반드시 작성할 필요는 없습니다. 그렇지만 정보가 이용 가능할 때 표준 보조 청크를 작성하는 것이 권장됩니다.
이 절은 PNG 디코더 동작과 뷰어 동작에 대한 몇 가지 요구사항과 권장사항을 제공합니다. 뷰어는 디코딩된 PNG 이미지를 사용자에게 표시합니다. 뷰어와 디코더 동작은 밀접하게 연결되어
있으므로 여기에서는 디코더와 뷰어를 함께 다룹니다. PNG 디코더에 대한 유일한 절대적 요구사항은 앞 장들에서 규정한 형식에 부합하는 모든 데이터스트림을 성공적으로 읽을 수 있어야 한다는
것입니다. 그러나 보통 최상의 결과는 아래의 추가 권장사항을 따름으로써 얻을 수 있습니다.
PNG 디코더는 이 국제 표준에서 명시적으로 정의된 모든 유효한 비트 깊이, color type, 압축 방식, filter method, 및 인터레이스 방식을 지원해야
합니다.
PNG 데이터스트림의 오류는 일반적으로 전송 오류와 구문 오류의 두 가지 일반적인 분류로 나뉩니다(자세한 내용은 4.10 Error handling 참조).
전송 오류의 예로는 "text" 또는 "ascii" 모드로의 전송으로 인해 바이트 코드 13 및/또는 10이 데이터스트림 전체에서 추가되거나 삭제되거나 변환되는 경우, 데이터스트림이 잘려
예기치 않게 종료되는 경우, 또는 저장 장치의 물리적 오류로 인해 하나 이상의 블록(보통 512바이트 단위)이 손상되거나 무작위 값으로 채워지는 경우 등이 있습니다. 구문 오류의 예로는
행 필터의 잘못된 값, 잘못된 압축 방식, 잘못된 청크 길이, 인덱스 이미지에서 첫 번째 IDAT 청크 이전에 PLTE 청크가 없는 경우, 또는 여러 개의 gAMA
청크가 존재하는 경우 등이 있습니다. PNG 디코더는 다음과 같이 오류를 처리해야 합니다:
- PNG 시그니처 바이트와 각 청크의 CRC를 사용하여 가능한 한 빨리 오류를 감지합니다. 디코더는 PNG 시그니처의 8바이트가 모두 정확한지 검증해야 합니다. 다음 8바이트가
올바른 청크 길이를 가진 IHDR 청크로 시작하는 경우 데이터스트림 무결성에 대한 추가 확신을 얻을 수 있습니다.
CRC는 청크 데이터를 처리하기 전에 검사해야 합니다. 스트리밍 PNG 디코더가 큰 IDAT 청크를 처리 중인 경우처럼 때로는 이것이 실용적이지 않을 수 있습니다. 이 경우에는 청크의 끝에 도달했을
때 CRC를 검사해야 합니다.
- 가능하면 오류에서 복구하고, 그렇지 않으면 우아하게 실패합니다. 이미지 처리에 거의 또는 전혀 영향을 미치지 않는 오류는 무시할 수 있지만, 중요한 데이터에 영향을 주는 오류는
애플리케이션에 적절한 방식으로 처리되어야 합니다.
- 복구 가능한 오류를 포함하여 오류를 설명하는 유용한 메시지를 제공합니다.
이 철학과 관련된 PNG 청크의 세 가지 분류가 있습니다. 이 분류의 목적상 "알려지지 않은 청크"는 디코더 작성자가 실제로 유형을 알지 못한 청크이거나, 해당 청크 유형의 기본 처리가
프로그램 목적에 충분하다고 작성자가 판단하여 알지 못하는 것으로 처리한 청크를 의미합니다. 나머지 청크는 "알려진 청크"라고 합니다. 이 정의에 따라 세 가지 클래스는 다음과 같습니다:
- 알려진 청크 — 이 명세에서 정의된 모든 필수(critical) 청크를 반드시 포함합니다 (IHDR, PLTE, IDAT, IEND).
- 알려지지 않은 필수 청크(청크 타입 첫 바이트의 비트 5가 0)
- 알려지지 않은 보조(ancillary) 청크(청크 타입 첫 바이트의 비트 5가 1)
청크 명명 규칙에 대한 설명은 5.4 Chunk
naming conventions을 참조하세요.
PNG 청크 타입은 이미지 추출에 필수적인지 여부(예: IHDR, PLTE, IDAT) 또는 데이터스트림 구조를 이해하는 데 필수적인지 여부(예:
IEND)에 따라 "critical" 또는 "ancillary"로 표시됩니다. 이는 특정한 종류의 중요성으로 모든 디코더에
반드시 관련되는 것은 아닙니다. 예를 들어 저작권 정보 같은 텍스트 주석만 추출하는 프로그램은 보기 가능한 이미지가 필요 없지만 UTF-8을 올바르게 디코드해야 합니다. 또 다른 디코더는 tRNS 및 gAMA 청크를 자신의 적절한 실행에
필수적이라고 간주할 수 있습니다.
구문 오류는 항상 알려진 청크와 관련됩니다. 알려지지 않은 청크의 구문 오류는 감지할 수 없기 때문입니다. PNG 디코더는 구문 오류가 치명적(복구 불가)인지 여부를 자신의 요구와 상황에
따라 결정해야 합니다. 예를 들어 대부분의 디코더는 잘못된 IEND 청크를 무시할 수 있고, 텍스트 추출 프로그램은 IDAT의 부재를 무시할 수 있지만, 이미지 뷰어는 인덱스 이미지에서 비어 있는 PLTE 청크로부터 복구할 수 없습니다. 반면 truecolor 이미지의
잘못된 PLTE 청크는 무시할 수 있습니다. 알파 채널을 추출하는 프로그램은 잘못된 gAMA 청크를 무시할 수 있지만, 두 개의 tRNS 청크가 존재하는 것을 치명적
오류로 간주할 수 있습니다. 구문 오류 이외의 이상한 상황은 다음과 같이 처리되어야 합니다:
- 알려지지 않은 보조 청크를 만나는 것은 결코 오류가 아닙니다. 해당 청크는 단순히 무시될 수 있습니다.
- 알려지지 않은 필수 청크를 만나는 것은 데이터스트림에서 이미지를 추출하려는 모든 디코더에 대해 치명적 조건입니다. 디코더가 필수 청크를 무시하면 추출한 이미지가 인코더가 의도한
이미지인지 알 수 없습니다.
- PNG 시그니처 불일치, CRC 불일치, 또는 예기치 않은 스트림 종료는 데이터스트림이 손상되었음을
나타내며 치명적 오류로 간주될 수 있습니다. 디코더는 데이터스트림에서 무언가를 구해보려 시도할 수 있지만 손상의 정도는 알기 어렵습니다.
치명적 조건이 발생하면 디코더는 즉시 실패하고, 적절하다면 사용자에게 오류를 알리며, 선택적으로 이미 사용자에게 표시된 image data를 계속 표시해야
합니다(즉 "우아하게 실패"). 애플리케이션 전체가 종료될 필요는 없습니다.
비치명적 오류가 발생하면 디코더는 적절하면 사용자에게 경고를 알리고 오류에서 복구하여 정상 처리를 계속해야 합니다.
인덱스 컬러 PNG를 디코딩할 때 범위를 벗어난 인덱스가 발견되면, 과거의 디코더들은 이를 처리하는 방식이 다양했습니다. 픽셀을 불투명한
검정으로 표시하는 것은 일반적인 오류 복구 전술 중 하나이며 이 명세에서는 이제 요구됩니다. 오래된 구현은 달라질 수 있으므로 인코더는 이 동작을 신뢰해서는 안
됩니다.
CRC를 계산하지 않는 디코더는 명백한 구문 오류를 손상 표시로 해석해야 합니다(자세한 내용은 13.2 Error checking 참조).
압축된 청크(IDAT, zTXt, iTXt, iCCP)의 오류는 버퍼 오버런으로 이어질 수
있습니다. deflate 압축 해제기 구현자는 이 가능성에 대비해야 합니다.
APNG는 전체 데이터스트림을 모두 읽기 전에 프레임을 점진적으로 표시할 수 있도록
설계되었습니다. 이는 일부 오류가 애니메이션 진행 중에야 감지될 수 있음을 의미합니다. 어떤 오류가 발견되면 디코더는 이후의 모든 프레임을 폐기하고 애니메이션을 중지하며 정적 이미지를
표시하도록 되돌리는 것이 강력히 권장됩니다. 애니메이션이 시작되기 전에 오류를 감지한 디코더는 정적 이미지를 표시해야 합니다. 적절하다면 사용자에게 오류 메시지를 표시할 수 있습니다.
디코더는 순서가 뒤바뀐 APNG 청크를 오류로 처리해야 합니다. APNG-인식 PNG 편집기는 시퀀스 번호를 사용하여 이들을 올바른 순서로 복원해야 합니다.
PNG 오류 처리 철학은 13.1 Error
handling에 설명되어 있습니다.
알려지지 않은 청크 타입은 필수(critical) 청크가 아닌 한 오류로 취급되어서는 안 됩니다.
청크 타입은 네 바이트가 모두 41-5A 및 61-7A(16진수) 범위에 속하는지 확인하여 타당성을 검사할 수 있습니다. 이 검사는 인식되지 않은 청크 타입에 대해서만 수행하면 됩니다.
전체 데이터스트림 크기(파일 시스템 정보, HTTP 프로토콜 등에서 얻음)가 알려진 경우 청크 길이도 타당성 검사할 수 있습니다. CRC를 검사하지 않으면 누락되거나 추가된 바이트 또는
잘못된 청크 길이로 인해 디코더가 동기에서 벗어나 이후 데이터를 청크 헤더로 잘못 해석할 수 있습니다.
IHDR과 같은 고정 길이 청크의 경우, 예상치 못한 청크 길이는 오류로 처리해야 합니다. 이 명세의 향후 확장에서는 기존 청크에 새 필드를 추가하지 않고, 대신 새로운 정보는 새로운 청크
타입을 추가하여 전달할 것입니다.
알려진 청크의 필드에서 예상치 못한 값(예: IHDR 청크의 예기치 않은 압축 방식)은 검사되어 오류로 처리되어야 합니다.
그러나 예상치 못한 필드 값은 critical 청크에서만 치명적 오류로 처리하는 것이 권장됩니다. 보조(ancillary) 청크의 예상치 못한 값은 해당
청크 전체를 알려지지 않은 청크 타입처럼 무시하여 처리할 수 있습니다. (이 권장은 해당 청크의 CRC가
검증되었다고 가정합니다. CRC를 검사하지 않는 디코더에서는 예상치 못한 값을 손상된 데이터스트림의 징후로 처리하는 것이 더 안전합니다.)
표준 PNG 이미지는 압축 방식 0으로 압축되어야 합니다. IHDR 청크의 압축 방식 필드는 향후 표준화 또는 독점 변형을
위해 제공됩니다. 디코더는 이 바이트를 검사하고 인식할 수 없는 코드이면 오류를 보고해야 합니다. 자세한 내용은 10. Compression을 참조하세요.
PNG 데이터스트림은 명시적으로 타입이 지정된 청크들의 모음으로 구성됩니다. 명세에서 내용이 정의된 청크는 실제로 어떤 것이든 포함할 수 있으며 악의적인 코드도 포함할 수 있습니다.
마찬가지로 IEND 청크 이후의 데이터는 어떤 것이든 포함할 수 있으며 악성 코드를 포함할 수 있습니다. 이러한 악성
코드가 PNG 이미지를 디코딩한 결과로 수신자 컴퓨터에서 실행될 위험이 알려진 바는 없습니다. 그러나 악의적 애플리케이션이 무해해 보이는 이미지 파일 속에 이러한 코드를 숨기고 이후
실행할 수는 있습니다.
향후 정의될 청크 타입과 관련된 잠재적 보안 위험은 현재 시점에서 명시하기 어렵습니다. 향후 공개 청크를 정의할 때 보안 문제를 고려할 것입니다. 알려지지 않았거나 구현되지 않은 청크
타입과 관련된 추가 보안 위험은 없습니다. 그러한 청크는 무시되거나 많아야 다른 PNG 데이터스트림에 복사될 뿐입니다.
iTXt, tEXt, 및 zTXt 청크는 키워드와 평문으로 표시될 데이터들을 포함합니다. iCCP 및 sPLT 청크도 평문으로 표시될 키워드를 포함합니다. 디코더가 이러한 텍스트를 제어 문자(특히 ESC(escape)
문자)를 필터링하지 않고 그대로 표시하면 일부 시스템이나 터미널이 바람직하지 않거나 안전하지 않은 방식으로 동작할 수 있습니다. 이 위험을 피하기 위해 디코더는 제어 문자를 필터링하는
것이 권장됩니다. 관련 내용은 13.7 Text
chunk processing을 참조하세요.
eXIf 청크의 경우 Exif 명세는 태그 "value offset" 포인터가 반드시 파일 내의 유효한 주소를 가리켜야 한다고
명시적으로 요구하지 않습니다. 이 요구는 암묵적입니다. (Exif IFD 구조를 설명하는 4.6.2항을 보십시오.) 그럼에도 불구하고 디코더는 잘못된 포인터를 만날 준비를 하고 이를
적절히 처리해야 합니다.
모든 청크는 길이 필드로 시작하므로 버퍼 오버플로우를 방지하는 디코더를 작성하기가 더 쉽습니다. 모든 청크 끝의 CRC는 우발적 손상 데이터에 대해 강력한 방어책을 제공합니다. PNG 시그니처 바이트는 일반적인 파일 전송
오류를 조기에 감지하게 합니다.
CRC를 검사하지 않는 디코더는 데이터 손상에 취약할 수 있습니다. 그러한 손상의 유일한 가능성 있는 결과는 이미지 내의 픽셀 표시 오류일 것입니다. 더 심각한 문제는 IHDR 청크의 CRC를 검사하지 않아 width나 height 필드가 손상되는 경우입니다. 자세한 내용은 13.2 Error checking을 참조하세요.
잘못 작성된 디코더는 청크가 최대 231-1 바이트까지 매우 클 수 있기 때문에 버퍼 오버플로우에 노출될 수 있습니다. 그러나 적절히 작성된 디코더는 큰 청크도 문제없이
처리할 것입니다.
일부 이미지 편집 도구는 과거에 단순히 편집된 영역의 알파 채널을 0으로 설정하여 삭제(redaction)를 수행했으며, 실제 이미지 데이터를 제거하지 않았습니다. 이러한 이미지를
시각적으로만 신뢰하는 사용자는 실제 이미지 데이터를 쉽게 복구할 수 있으므로 개인정보 위험이 있습니다.
마찬가지로 일부 이미지 편집 도구는 IHDR에서 너비와 높이만 다시 써서 잘라내기(clipping)를 수행했으며, 이미지 데이터는 새 너비와
높이를 넘어 확장되어 복구될 수 있습니다.
eXIf 청크를 포함한 이미지는 자동으로 포함된 데이터(예: 사진의 GPS 좌표)를 포함할 수 있으며, 사용자가 PNG 이미지에 이러한
데이터가 포함되어 있다는 사실을 모를 경우 개인정보 위험이 될 수 있습니다. (Exif를 포함하는 다른 이미지 형식들, 예: JPEG/JFIF도 동일한 개인정보 위험을 가집니다.)
디코더는 단순한 네 바이트 리터럴 비교로 청크 타입을 인식해야 합니다; 청크 타입에 대해 대소문자 변환을 수행하는 것은 잘못된 방법입니다. 보조 비트(ancillary bit)가 1인
알려지지 않은 청크를 만나는 디코더는 안전하게 그 청크를 무시하고 이미지를 계속 표시할 수 있습니다. 반면 보조 비트가 0인 알려지지 않은 청크(필수 청크)를 만나는 이미지를 추출하려는
디코더는 해당 이미지를 안전하게 해석할 수 없다는 것을 사용자에게 알려야 합니다.
디코더는 지정된 비트들을 수치적으로 검사하여 알려지지 않은 청크 타입의 속성을 검증해야 합니다. 문자가 대문자인지 소문자인지를 테스트하는 것은 비효율적이며, 로케일별 대소문자 정의를
사용하면 잘못될 수 있습니다.
예약 비트(reserved bit)가 1로 설정되어 있다고 해서 디코더가 오류를 표시해서는 안 됩니다. 향후 PNG 명세의 어떤 버전에서 이 비트에 의미를 부여할 수 있기 때문입니다. 이
비트가 설정된 청크는 다른 알려지지 않은 청크 타입과 동일하게 처리하면 됩니다.
청크 타입의 개인 비트(private bit)는 기능적 의미가 없고 W3C가 정의한 청크와 개인 정의된 청크 간의 충돌을 피하기 위해 사용되므로 디코더가 이를 검사할 필요는 없습니다.
모든 보조(ancillary) 청크는 선택 사항이며 디코더는 이를 무시할 수 있습니다. 그러나 디코더는 적절하고 가능하면 이러한 청크를 해석하는 것이 권장됩니다.
비정사각형 픽셀은 표현될 수 있습니다(참조: 11.3.4.3 pHYs Physical pixel dimensions), 그러나 뷰어가 이를 반드시 반영해야 하는 것은 아닙니다. 뷰어는
PNG 데이터스트림의 픽셀을 정사각형인 것처럼 표시할 수 있습니다.
디스플레이의 픽셀 종횡비가 PNG 데이터스트림에 정의된 물리적 픽셀 치수의 종횡비와 다를 경우, 뷰어는 올바른 표시를 위해 이미지를 재스케일하는 것이 강력히 권장됩니다.
pHYs 청크의 단위 지정자(unit specifier)가 0(단위 불명)인 경우, 디코더의 동작은 두
픽스-퍼-유닛(pixels-per-unit) 값의 비율에 따라 달라질 수 있지만 그 크기 자체에는 의존해서는 안 됩니다. 예를 들어 pHYs 청크에 (ppuX, ppuY, unit) = (2, 1, 0)가 들어 있는 것은
(1000, 500, 0)가 들어 있는 것과 동등합니다. 둘 다 이미지 픽셀이 너비의 두 배 높이임을 나타내는 유효한 신호입니다.
이미지와 디스플레이의 픽셀 종횡비 차이를 처리하는 합리적인 방법 중 하나는 가로 또는 세로 방향 중 하나만 이미지를 확장하는 것입니다. 스케일 팩터는 다음과 같은 부동소수점 계산으로 얻을
수 있습니다:
image_ratio = pHYs_ppuY / pHYs_ppuX
display_ratio = display_ppuY / display_ppuX
scale_factor_X = max(1.0, image_ratio/display_ratio)
scale_factor_Y = max(1.0, display_ratio/image_ratio)
이미지 영역을 유지하는 등의 다른 방법도 합리적일 수 있고 pHYs 청크를 무시하는 것도 허용되므로, 작성자는 모든 뷰잉
애플리케이션이 이 스케일링 방법을 사용할 것이라고 가정해서는 안 됩니다.
픽셀 종횡비 보정 외에도 뷰어는 가로 및 세로 방향 모두에서 추가적인 스케일링을 수행할 이유가 있을 수 있습니다. 예를 들어 표시 장치에 맞지 않을 정도로 큰 이미지를 축소하거나, 고해상도
프린터에 전송되는 이미지를 표시할 때와 같은 크기로 보이게 하기 위해 확장할 수 있습니다.
가능하면 PNG 디코더는 데이터스트림에서 발견된 모든 iTXt, tEXt, 및 zTXt 청크를 사용자에게 표시하는 방법을 제공해야 합니다.
디코더가 특정 텍스트 키워드를 인식하지 못하더라도 사용자가 이해할 수 있을 수 있습니다.
tEXt 및 zTXt 청크를 처리할 때 허용된 문자 이외의
문자를 만날 수 있습니다. 일부 문자는 안전하게 표시할 수 있지만(예: TAB, FF, CR — 16진수 09, 0C, 0D), 다른 문자들, 특히 ESC(16진수 1B) 문자는
디스플레이 하드웨어나 소프트웨어에 의해 예기치 않은 동작을 유발하여 보안 위험을 초래할 수 있습니다. 디코더는 tEXt
또는 zTXt 청크에서 발견되는 비Latin-1 문자를(개행 및 경우에 따라 TAB, FF를 제외하고) 직접 표시하려고
시도해서는 안 됩니다. 대신 무시하거나 "\nnn" 같은 가시적 표기법으로 표시해야 합니다. 관련 내용은 13.3 Security
considerations를 참조하세요.
iTXt 청크를 처리할 때 디코더는 Encoding Standard의 UTF-8
decode를 따라야 합니다.
인코더가 개행을 라인피드(16진수 0A)로 표현하는 것이 권장되지만, 디코더는 이에 의존하지 않는 것이 권장됩니다. CR, LF, CR-LF 등 일반적인 모든 개행 조합을 인식하여 각각을
단일 개행으로 표시하는 것이 가장 좋습니다. TAB은 적절한 수의 공백으로 확장하여 8의 배수 열로 맞출 수 있습니다.
비Latin-1 레거시 문자 인코딩을 사용하는 시스템에서 실행되는 디코더는 Latin-1 문자가 올바르게 표시되도록 문자 코드를 재매핑해야 합니다. 지원되지 않는 문자는 시스템에 적합한
대체 문자(U+FFFD REPLACEMENT CHARACTER, U+003F QUESTION MARK, 또는 U+001A SUB 등)로 교체하거나 "\nnn" 같은
가시 표기법으로 매핑해야 합니다. 문자는 디코딩 시스템에서 인쇄 가능한 문자일 때만 표시되어야 합니다. 일부 바이트 값은 디코딩 시스템에서 제어 문자로 해석될 수 있으므로 보안을 위해
그러한 시스템에서 실행되는 디코더는 이러한 제어 문자를 표시해서는 안 됩니다.
디코더는 인코더가 79자 초과의 라인을 생성하지 않도록 권장되더라도, 개행 문자 사이에 임의 개수의 인쇄 가능한 문자가 포함된 텍스트 청크를 표시할 준비가 되어 있어야 합니다.
이 명세에서 사용하는 압축 기법은 전체 압축 데이터스트림이 준비되기 전에 압축 해제를 시작할 수 있도록 요구하지 않습니다. 따라서 전체 압축 해제 데이터스트림이 준비되기 전에 표시를 시작할
수 있습니다. 향후 버전의 이 명세에서 사용되는 일반 목적 압축 방식이 이 특성을 갖지 않을 가능성은 극히 낮습니다.
IDAT 청크 경계는 의미론적 의미가 없으며 압축 데이터스트림의 어느 지점에나 나타날 수 있다는 점을 강조하는 것이
중요합니다. image data(예: 스캔라인 경계)와 deflate 블록 경계 또는 IDAT 청크 경계 사이에 필수적인 상관관계는 없습니다. 전체 image data는 하나의 zlib 데이터스트림으로
나타나며 이는 여러 개의 IDAT 청크에 저장될 수 있습니다. 디코더가 이것 이상을 가정하는 것은 잘못입니다. 일부 인코더
구현은 이러한 구조들 사이에 실제로 관계를 만들 수 있지만 디코더는 이에 의존해서는 안 됩니다.
필터의 효과를 되돌리기 위해 디코더는 같은 행의 이전 픽셀, 바로 위의 이전 행의 현재 픽셀, 그리고 위쪽 픽의 왼쪽 픽의 디코딩된 값을 사용할 필요가 있습니다. 이는 적어도 한 행 분량의
image
data를 디코더가 항상 저장해야 함을 의미합니다. 일부 필터 타입은 이전 스캔라인을 참조하지 않더라도 디코더는 다음 스캔라인이 그것을 참조할 수 있으므로 각 스캔라인을
디코딩하면서 항상 저장해야 합니다. 자세한 내용은 7.3
Filtering을 참조하세요.
디코더는 인터레이스된 이미지를 읽을 수 있어야 합니다. 참조 이미지가 5열 미만 또는 5행 미만이면 일부 패스가 비어 있을 수 있습니다. 인코더와 디코더는 이 경우를 올바르게 처리해야
합니다. 특히 필터 타입 바이트는 비어 있지 않은 스캔라인에만 연관되며, 비어 있는 축소 이미지에는 필터 타입 바이트가 존재하지 않습니다.
느린 전송 링크에서 이미지를 수신할 때, 뷰어는 인터레이스 이미지를 점진적으로 표시하여 체감 성능을 향상시킬 수 있습니다. 이는 각 축소 이미지가 수신될 때까지 수신된 데이터를 기반으로
전체 이미지의 근사치를 표시하는 것을 의미합니다. 각 수신된 픽을 아직 전송되지 않은 아래쪽 및 오른쪽 픽 위치를 채우는 사각형으로 확장하여 표시하는 간단하지만 보기 좋은 효과를 얻을 수
있습니다. 이 과정은 다음의 ISO C 코드로 설명될 수 있습니다 [ISO_9899]:
int starting_row[7] = { 0, 0, 4, 0, 2, 0, 1 };
int starting_col[7] = { 0, 4, 0, 2, 0, 1, 0 };
int row_increment[7] = { 8, 8, 8, 4, 4, 2, 2 };
int col_increment[7] = { 8, 8, 4, 4, 2, 2, 1 };
int block_height[7] = { 8, 8, 4, 4, 2, 2, 1 };
int block_width[7] = { 8, 4, 4, 2, 2, 1, 1 };
int pass;
long row, col;
pass = 0;
while (pass < 7)
{
row = starting_row[pass];
while (row < height)
{
col = starting_col[pass];
while (col < width)
{
visit(row, col,
min(block_height[pass], height - row),
min(block_width[pass], width - col));
col = col + col_increment[pass];
}
row = row + row_increment[pass];
}
pass = pass + 1;
}
함수 visit(row,column,height,width)는 다음 전송된 픽셀을 얻어 지정된 행과 열의 좌상단 코너를 갖는 지정된 높이와 너비의 사각형을 픽셀의
색으로 칠합니다. 행과 열은 좌상단을 0,0으로 측정한다는 점을 유의하세요.
뷰어가 수신된 이미지를 배경 이미지와 병합하고 있다면, 받은 픽 위치만 칠하는 것이 더 편리할 수 있습니다(visit() 함수는 지정된 행과 열의 픽 하나만 설정하고
전체 사각형을 설정하지 않습니다). 이는 새 이미지가 점차적으로 기존 이미지를 대체하면서 "페이드 인" 효과를 생성합니다. 이 접근의 장점은 각 픽이 교체될 때 적절한 알파 또는 투명도
처리를 수행할 수 있다는 것입니다. 위에서 설명된 대로 사각형을 칠하면 나중에 해당 위치에 수신될 픽들이 완전 또는 부분적으로 투명한 것으로 판명될 경우 필요할 수 있는 배경 이미지 픽을
덮어써 버릴 수 있습니다. 이 문제는 배경 이미지가 오프스크린에 저장되지 않은 경우에만 발생합니다.
PNG의 보편적 교환성 목표를 달성하기 위해, 디코더는 모든 유형의 PNG 이미지를 수용해야 합니다: indexed-color,
truecolor, 및 greyscale. 인덱스-컬러 디스플레이 하드웨어에서 실행되는 뷰어는 truecolor 이미지를 보기 위해 인덱스-컬러로 축소할 수 있어야 합니다. 이 과정을 "색상 양자화(color
quantization)"라고 합니다.
색상 양자화의 간단하고 빠른 방법은 이미지를 고정 팔레트로 축소하는 것입니다. 균일한 색상 간격("color cubes")의 팔레트는 픽셀당 계산을 최소화하기 위해 보통 사용됩니다. 사진과
같은 이미지의 경우, 매끄러운 그라데이션에서 보기 흉한 계단 현상을 피하기 위해 디더링이 권장되지만, 디더링은 눈에 거슬리는 입자감을 도입할 수 있습니다.
렌더링 품질은 이미지에 특화된 팔레트를 사용하는 것으로 크게 향상될 수 있습니다. 색상 큐브는 특정 이미지에서 사용되지 않는 항목이 많은 편이기 때문입니다. 이 접근법은 먼저 팔레트를
선택하는 작업과, 다음으로 개별 픽셀을 가장 가까운 사용 가능한 색상으로 매핑하는 작업에서 더 많은 노력을 요구합니다. PNG는 인코더가 제안 팔레트를 제공하는 것을 허용하지만, 모든
인코더가 이를 수행하는 것은 아니며 제안 팔레트가 적합하지 않을 수도 있습니다(색상이 너무 많거나 너무 적을 수 있음). 따라서 고품질 뷰어는 팔레트 선택 루틴을 갖추고 있어야 합니다.
개별 픽셀을 적절한 속도로 팔레트 항목에 매핑하는 가장 현실적인 방법은 대규모 룩업 테이블인 경우가 많습니다.
색상 양자화의 구현은 수없이 많이 존재합니다. PNG 샘플 구현인 libpng (http://www.libpng.org/pub/png/libpng.html)에는
이를 위한 코드가 포함되어 있습니다.
디코더는 표시를 위해 PNG 데이터를 더 낮은 샘플 깊이(데이터 정밀도)로 축소하고자 할 수 있습니다. 예를 들어, 16비트 데이터는 현재 대부분의 디스플레이 하드웨어에서 사용하기 위해
8비트로 축소될 필요가 있습니다. 8비트 데이터를 5비트로 축소하는 것도 흔합니다.
가장 정확한 스케일링은 다음의 선형 방정식으로 달성됩니다
output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5)
여기서
MAXINSAMPLE = (2sampledepth)-1
MAXOUTSAMPLE = (2desired_sampledepth)-1
약간 덜 정확한 변환은 단순히 (sampledepth - desired_sampledepth)만큼 오른쪽으로 시프트하는 것입니다. 예를 들어 16비트 샘플을 8비트로
줄이려면 저위 바이트를 버리면 됩니다. 많은 상황에서 시프트 방식은 표시 목적에 충분히 정확하며 확실히 훨씬 빠릅니다. (그러나 gamma 보정이 수행되는 경우, 샘플 재스케일링은
gamma 보정 룩업
테이블에 통합될 수 있으며, 이는 13.13
Decoder gamma handling에 예시되어 있습니다.)
디코더가 샘플을 확대해야 하는 경우(예: frame buffer가 PNG 이미지보다 더 큰 샘플 깊이를 가질 때)에는 12.4 Sample depth
scaling에 설명된 것처럼 선형 스케일링 또는 왼쪽 비트 복제(left-bit-replication)를 사용해야 합니다.
sBIT 청크가 존재할 때는, 참조 image data를 sBIT에 지정된 샘플 깊이로 오른쪽 시프트하여 복원할 수 있습니다. 선형 스케일링이 원래 데이터를 반드시 재현하지는 않는다는 점에 유의하세요.
인코더가 데이터를 스케일 업할 때 선형 스케일링을 사용하도록 요구되지 않았기 때문입니다. 그러나 인코더는 최상위 비트를 보존하는 방법을 사용해야 하므로 시프트는 항상 작동합니다. 이는
시프트가 선형 스케일링보다 더 정확하다고 할 수 있는 유일한 경우입니다. 디코더는 sBIT 청크를 무시해도 됩니다; 저장된
이미지는 IHDR 청크에 표시된 샘플 깊이를 가진 유효한 PNG 데이터스트림입니다. 그러나 표시를 위해 원래 샘플을 복원한
다음 디스플레이에 맞게 스케일하는 데 sBIT를 사용하는 것이 무시하는 것보다 더 정확한 표시를 제공하는 경우가 많습니다.
투명 픽셀을 감지하기 위해 tRNS 청크 값과 픽셀 값을 비교할 때, 비교는
정확히 수행되어야 합니다. 따라서 투명 픽 검사(transparent pixel detection)는 샘플 정밀도를 줄이기 전에 수행되어야 합니다.
감마 문제에 대한 간단한 소개는 C. Gamma and
chromaticity를 참조하십시오.
완전한 색 관리를 수행할 수 있는 뷰어는 여기서 설명된 것보다 더 정교한 계산을 수행할 것입니다.
이미지 표시 프로그램이 정확한 톤 재현을 생성하려면 샘플과 표시 출력 간의 관계 및 표시 시스템의 전달 함수를 고려해야 합니다.
이는 다음을 계산함으로써 수행할 수 있습니다:
sample = integer_sample / (2sampledepth - 1.0)
display_output = sample1.0/gamma
display_input = inverse_display_transfer(display_output)
framebuf_sample = floor((display_input * MAX_FRAMEBUF_SAMPLE)+0.5)
여기서 integer_sample은 데이터스트림의 샘플 값이고, framebuf_sample은 frame buffer에 쓸 값이며,
MAX_FRAMEBUF_SAMPLE은 프레임 버퍼 샘플의 최대값(8비트의 경우 255, 5비트의 경우 31 등)입니다. 첫 줄은 정수 샘플을 0.0에서 1.0 범위의
정규화된 부동소수점 값으로 변환하고, 둘째 줄은 원하는 표시 출력 밝기에 비례하는 값으로 변환하며, 셋째 줄은 표시 시스템의 전달 함수를 고려하고, 넷째
줄은 정수 프레임 버퍼 샘플로 변환합니다. 0을 양의 지수로 거듭제곱하면 0입니다.
둘째와 셋째 줄 사이에 단계(step)를 삽입하여 실제 시청 조건과 기준 시청 조건 간의 차이를 조정할 수 있습니다. 그러나 이 조정은 베일링 글레어(veiling glare), 블랙
매핑, 색상 외관 모델을 고려해야 하므로 단일 거듭제곱 함수로 잘 근사할 수 없습니다. 이러한 계산은 여기서 설명하지 않습니다. 시청 조건을 무시하면 오차는 보통 작습니다.
표시 전달 함수는 보통 지수 display_exponent을 갖는 거듭제곱 함수로 근사될
수 있으며, 이 경우 둘째와 셋째 줄은 병합되어:
display_input = sample1.0/(gamma * display_exponent) = sampledecoding_exponent
으로 하여 하나의 거듭제곱 계산만 수행할 수 있습니다. 컬러 이미지의 경우 R, G, B 각각에 대해 전체 계산을 수행합니다.
gamma
value는 gAMA 청크에서 직접 가져올 수 있습니다. 또는 애플리케이션은 사용자가 표시된 이미지의 외관을
조정할 수 있도록 gamma value에 영향을 주게 할 수 있습니다. 예를 들어 사용자가 기본값 1.0인 매개변수
user_exponent을 수동으로 설정하고 애플리케이션은 다음과 같이 설정할 수 있습니다:
gamma = gamma_from_file / user_exponent
decoding_exponent = 1.0 / (gamma * display_exponent)
= user_exponent / (gamma_from_file * display_exponent)
사용자는 중간 톤을 어둡게 하려면 user_exponent를 1보다 크게, 밝게 하려면 1보다 작게 설정할 것입니다.
값이 0인 gAMA 청크는 의미가 없지만 실수로 나타날 수 있습니다. 디코더는 이를 무시해야 하며, 편집기는 이를 폐기하고
사용자에게 경고를 발행할 수 있습니다.
모든 픽셀마다 초월 함수 계산을 수행할 필요는 없습니다. 대신 모든 가능한 샘플 값에 대해 올바른 출력 값을 제공하는 룩업 테이블을 계산할 수 있습니다. 이것은 이미지당 8비트 정확도의
경우 256번의 계산만 필요하며, 픽셀당 계산을 여러 번 하는 것보다 훨씬 효율적입니다. 인덱스-컬러 이미지의 경우 팔레트에 대한 일회성 보정으로 충분하며, 투명도를 사용하고 있고
비균일한 배경에 대해 표시하는 경우가 아니라면 그 정도의 처리로 충분합니다.
부동소수점 계산이 불가능한 경우에도 gamma 보정 테이블은 정수 산술과 미리 계산된 로그 테이블을 사용하여 생성할 수 있습니다. 예시 코드는 [PNG-EXTENSIONS]에
나와 있습니다.
들어오는 이미지의 gamma value(gAMA, sRGB, 및 iCCP가 모두 없는 경우)가 알려지지 않은 경우, 단독 이미지 뷰어는 가능성 있는 기본 gamma value를 선택하되, 결과가
너무 어둡거나 너무 밝으면 사용자가 새 값을 선택할 수 있게 해야 합니다. 기본 gamma value는 이미지가 인터넷에서 왔는지 로컬 시스템에서 왔는지 등의
다른 정보에 따라 달라질 수 있습니다. 일관성을 위해 HTML과 같은 문서 형식이나 SVG 같은 벡터 그래픽의 뷰어는 알 수 없는 gamma value를 가진 포함 또는
연결된 PNG 이미지를 다른 태그 없는 이미지들과 동일하게 처리해야 합니다.
실무에서는 어떤 표시 지수(display exponent)를 사용해야 하는지 결정하기 어려운 경우가 많습니다. 내장된 gamma 보정이 없는 시스템에서는 표시 지수가
전적으로 CRT에 의해 결정됩니다. 상세한 보정 측정값이 없는 한 표시 지수로 2.2를 사용해야 합니다.
많은 현대 프레임 버퍼는 gamma 보정을 수행하는 룩업 테이블을 가지고 있으며, 이러한 시스템에서는 표시 지수 값은 룩업 테이블과 CRT의 지수의
결합입니다. 뷰어 애플리케이션 내부에서 룩업 테이블의 내용을 알 수 없을 수도 있으므로 사용자가 표시 시스템의 지수 값을 제공하도록 요청해야 할 수 있습니다. 불행히도 제조사마다 룩업
테이블에 무엇을 넣을지 지정하는 방식이 다르므로 시스템 gamma value 해석은 시스템에 따라 달라집니다.
실제 디스플레이의 응답은 표시 지수 하나로 완전히 설명될 수 없을 만큼 더 복잡합니다. 만약 전압 입력에 따른 모니터의 광 출력에 대한 실제 측정값이 있다면 위 계산의 셋째와 넷째 줄을
이러한 측정값 룩업으로 대체하여 원하는 밝기를 가장 가깝게 제공하는 실제 frame buffer 값을 찾을 수 있습니다.
색 문제에 대한 참조는 C. Gamma and
chromaticity를 보십시오.
많은 경우 PNG 데이터스트림의 image data는 장치 종속 RGB 값으로 취급되어 적절한 gamma 보정만을 적용한 채 그대로 표시됩니다.
이는 PNG 이미지를 가장 빠르게 표시하는 방법입니다. 그러나 뷰어가 원저작자가 사용한 정확히 동일한 표시 하드웨어를 사용하지 않는 한, 특히 어두운 색상이나 중립에 가까운 색상에서는
원저작자가 본 것과 정확히 동일한 색상이 나오지 않을 수 있습니다. cHRM 청크는 단지 gamma 보정만으로
제공되는 것보다 더 밀접한 색상 매칭을 가능하게 합니다.
cHRM 데이터는 이미지 데이터를 RGB에서 XYZ로 변환하고 이어서 CIE LAB 같은 지각적으로 선형인 색 공간으로
변환하는 데 사용될 수 있습니다. 색상들은 분할되어 최적의 팔레트를 생성할 수 있는데, 이는 CIE LAB에서 두 색상 간의 기하학적 거리가 사람들이 인식하는 색상 차이와 강하게 관련이
있기 때문입니다(예: RGB나 XYZ 공간과는 달리). 생성된 팔레트를 다시 RGB 색 공간으로 변환하면 표시하거나 PLTE 청크에 쓸 수 있습니다.
이미지 처리 애플리케이션의 일부인 디코더는 또한 분석을 위해 이미지 데이터를 CIE LAB 공간으로 변환할 수 있습니다.
제품 설계, 과학적 시각화, 의학, 건축, 광고 등 색상 충실도가 중요한 응용에서는 PNG 디코더가 소스 RGB에서 이미지가 표시될 모니터의 디스플레이 RGB 공간으로 이미지를 변환할 수
있습니다. 이는 소스 RGB → XYZ 행렬과 XYZ → 디스플레이 RGB 행렬을 계산한 다음 이들을 결합하여 전체 변환을 생성하는 것을 포함합니다. PNG 디코더는 가멧 매핑을 구현할
책임이 있습니다.
Color Management System(CMS)을 갖춘 플랫폼에서 실행되는 디코더는 image data, gAMA, 및 cHRM 값을 CMS에 전달하여 표시 또는 추가 처리를 할 수
있습니다.
색상 인쇄 기능을 제공하는 PNG 디코더는 Level 2 PostScript의 기능을 사용하여 보정된 RGB 공간 또는 XYZ와 같은 장치 독립 색 공간에서 이미지 데이터를 지정할 수
있습니다. 이는 단순한 RGB→CMYK 변환보다 더 나은 색상 충실도를 제공합니다. PostScript Language Reference 매뉴얼은 예시를 제공합니다. 그러한 디코더는 소스
RGB( cHRM 청크에 명시된)와 대상 프린터 사이의 가멧 매핑을 구현할 책임이 있으며, PostScript 인터프리터가
필요한 색상을 생성할 책임을 집니다.
PNG 디코더는 cHRM 데이터를 사용하여 컬러 이미지의 정확한 그레이스케일 표현을 계산할 수 있습니다. RGB에서
그레이로의 변환은 XYZ의 Y(휘도) 성분을 계산하는 것과 같으며, 이는 R, G, B 값의 가중 합입니다. 가중치는 모니터 유형, 즉 cHRM 청크의 값에 따라 달라집니다. 디코더는 cHRM 청크가 없는 PNG
데이터스트림에 대해서도 이 작업을 수행할 수 있습니다. 이 경우 합리적인 기본값으로는 CCIR 709 프라이머리를 사용하는 것이 권장됩니다. 원래의 NTSC 프라이머리는 PNG 이미지가
실제로 그러한 모니터에 맞춰 색 보정된 경우가 아니라면 사용해서는 안 됩니다.
bKGD 청크로 지정된 배경 색은 일반적으로 이미지 주변의 사용되지 않는 화면 공간을 채우는 데 사용되며, 이미지 내의 투명
픽셀도 채우는 데 사용됩니다. (따라서 이미지가 투명도를 사용하지 않더라도 bKGD는 유효하고 유용합니다.) bKGD 청크가 없으면 뷰어는 적절한 배경 색을 결정해야 합니다. 다른 정보가 없을 때, 8비트 sRGB 색 공간에서
153과 같은 중간 회색이 합리적인 선택이 될 것입니다. 투명한 검정 또는 흰색 텍스트와 어두운 드롭 섀도우와 같은 일반적인 요소들은 이 배경에서 모두 읽기 쉬울 것입니다.
웹 브라우저와 같이 이미 이미지를 표시할 특정 배경을 가진 뷰어는 bKGD 청크를 무시하여 자체 선호하는 배경 색이나 배경
이미지로 bKGD를 대체해야 합니다.
bKGD 청크로 지정된 배경 색은 tRNS 청크가 지정한
색(또는 인덱스-컬러 이미지의 경우 tRNS가 투명으로 표시한 팔레트 인덱스)과 일치하더라도 투명으로 간주되어서는 안
됩니다. 그렇지 않으면 "배경 뒤에 있는 것"을 상정해야만 그 위에 합성(composite)할 수 있게 됩니다. 배경 색은 배경으로 사용되거나 무시될 뿐이며, PNG 이미지와 다른 배경
사이의 중간 레이어로 간주되지 않습니다.
실제로 bKGD와 tRNS 청크가 동일한 색을 지정하는
경우가 흔할 것입니다. 이 경우 투명도 처리를 구현하지 않는 디코더도 부분 투명 픽이 없을 때 의도된 표시를 제공할 수 있습니다.
알파 채널은 전경 이미지를 배경 이미지 위에 합성(composite)하는 데 사용될 수 있습니다. PNG 데이터스트림은 전경 이미지와 투명도 마스크를 정의하지만
배경 이미지는 정의하지 않습니다. PNG 디코더는 이 가장 일반적인 경우를 반드시 지원해야 하는 것은 아닙니다. 대부분은 단일 배경 색에 대해 합성을 지원할 수 있을 것으로 예상됩니다.
합성된 샘플 값을 계산하는 방정식은 다음과 같습니다:
output = alpha * foreground + (1-alpha) * background
여기서 alpha 및 입력과 출력 샘플 값들은 0에서 1 사이의 분수로 표현됩니다. 이 계산은 강도 샘플(intensity samples)으로 수행되어야 하며, gamma 인코딩된
샘플로 수행해서는 안 됩니다. 컬러 이미지의 경우 R, G, B 샘플 각각에 대해 별도로 계산됩니다.
다음 코드는 전경 이미지를 배경 이미지에 대해 합성하는 일반적인 경우를 보여줍니다. 이 코드는 배경 이미지의 원래 픽셀 데이터가 사용 가능하고 출력이 표시를 위한 frame buffer에 쓰여진다는 가정을 합니다. 다른 변형들도 가능하며 코멘트에 설명이 있습니다. 이 코드는
전경 이미지와 배경 이미지의 샘플 깊이와 gamma values가 서로 다를 수 있고 표시 시스템에 적합하지 않을 수도 있음을 허용합니다. 실제로는 검사
없이 동등성을 가정해서는 안 됩니다.
이 코드는 ISO C 표준에 따른 것으로, 아래 주석에서 참조하기 쉽게 행 번호가 추가되어 있습니다.
01 int foreground[4];
02 int background[3];
03 int fbpix[3];
04 int fg_maxsample;
05 int bg_maxsample;
06 int fb_maxsample;
07 int ialpha;
08 float alpha, compalpha;
09 float gamfg, linfg, gambg, linbg, comppix, gcvideo;
10 fg_maxsample = (1 << fg_sample_depth) - 1;
11 bg_maxsample = (1 << bg_sample_depth) - 1;
12 fb_maxsample = (1 << frame_buffer_sample_depth) - 1;
13 ialpha = foreground[3];
14 if (ialpha == 0) {
15 ;
16 } else if (ialpha == fg_maxsample) {
17 for (i = 0; i < 3; i++) {
18 gamfg = (float) foreground[i] / fg_maxsample;
19 linfg = pow(gamfg, 1.0 / fg_gamma);
20 comppix = linfg;
21 gcvideo = pow(comppix, 1.0 / display_exponent);
22 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
23 }
24 } else {
25 alpha = (float) ialpha / fg_maxsample;
26 compalpha = 1.0 - alpha;
27 for (i = 0; i < 3; i++) {
28 gamfg = (float) foreground[i] / fg_maxsample;
29 linfg = pow(gamfg, 1.0 / fg_gamma);
30 gambg = (float) background[i] / bg_maxsample;
31 linbg = pow(gambg, 1.0 / bg_gamma);
32 comppix = linfg * alpha + linbg * compalpha;
33 gcvideo = pow(comppix, 1.0 / display_exponent);
34 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
35 }
36 }
변형:
- 출력이 frame buffer 대신 다른 PNG 데이터스트림이라면, 21, 22, 33, 34행은 다음과 같이
변경되어야 합니다
gamout = pow(comppix, outfile_gamma);
outpix[i] = (int) (gamout * out_maxsample + 0.5);
또한, 알파가 0일 때 배경 픽셀도 처리해야
하므로 단순히 픽셀을 건너뛰는 대신 배경 픽셀을 처리하도록 15행을 17-23행의 배경 처리 버전으로 대체해야 합니다.
- 출력 파일, 전경 파일, 배경 파일의 샘플 깊이가 모두 같고 세 개의 gamma values도 일치한다면, 14-23행의 비합성 코드는
알파가 1이면 입력 파일에서 출력 파일로 픽셀 값을 복사하고, 알파가 0이면 배경에서 출력으로 복사하는 것으로 단순화됩니다. 이미지의 대부분 픽에서 알파가 0 또는 1인 경우가
많으므로 이는 큰 시간 절약이 됩니다. 대부분의 픽에 대해 gamma 계산이 필요하지 않습니다.
- 샘플 깊이와 gamma values가 모두 일치한다면 감마 디코딩/인코딩(28-31행, 33-34행)을 건너뛰고 32행만
수행하여 감마 인코딩된 샘플 값을 사용하는 것이 매력적으로 보일 수 있습니다. 이 방식이 이미지 품질에 그리 나쁜 영향을 주지는 않지만, 앞에서 권장한 대로 알파 값 0과 1을
특수 경우로 처리하면 시간 절약은 크지 않습니다.
- 배경 이미지의 원래 픽 값이 더 이상 이용 불가능하고 배경 이미지 표시로 남은 것은 처리된 frame buffer 픽들뿐이라면, 30-31행은 프레임 버퍼 픽
값에서 강도(intensity)를 추출해야 하며 다음과 같은 코드가 필요합니다
gcvideo = (float) fbpix[i] / fb_maxsample;
linbg = pow(gcvideo, display_exponent);
하지만 반올림 오류가 발생할 수 있으므로
가능하면 원래 배경 픽을 사용하는 것이 좋습니다.
- 18-22행은 알파 채널이 없는 경우에 수행되는 정확히 동일한 gamma 계산을 수행하고 있다는 점에 유의하세요. 알파가 없는 경우를 룩업 테이블로 처리한다면 동일한 룩업 테이블을
여기서도 사용할 수 있습니다. 28-31행과 33-34행도 (다른) 룩업 테이블로 수행할 수 있습니다.
- 정수 산술은 부동소수점 대신 사용할 수 있으며, 충분한 정밀도를 유지하도록 주의해야 합니다.
Note
참고: 부동소수점에서는 입력 샘플 값이 0에서 1 사이로 보장되고 합성은 항상 입력 값 사이의 결과(포함)만을 낳으므로 오버플로우나 언더플로우 검사가 필요 없습니다.
정수 산술을 사용할 경우 오버플로우나 언더플로우가 없도록 반올림 오차 분석이 필요할 수 있습니다.
풀 알파 채널을 가진 PNG 이미지를 표시할 때는 최소한 검은색 같은 어떤 배경에 대해 이미지를 합성할 수 있어야 합니다. 알파 채널을 무시하면 사전
곱해진(associated-alpha) 표현에서 변환된 PNG 이미지는 올바르게 보이지 않습니다. (물론 알파 채널이 별도의 투명 마스크라면 알파를 무시하는 것이 숨겨진 부분의 이미지를
복구하는 데 유용한 옵션이 될 수 있습니다.)
디코더가 실제 합성 로직을 구현하지 않더라도 알파 값이 0과 1만 포함된 이미지를 처리하는 것은 간단합니다. (이는 greyscale 및 truecolor PNG 데이터스트림에서 tRNS 청크를
사용하는 경우 암시적으로 성립합니다; 인덱스-컬러 PNG 데이터스트림의 경우 tRNS 청크가 0과 255 이외의 값을
포함하는지 확인하기 쉽습니다.) 이 단순한 경우에는 투명 픽은 배경 색으로 대체되고 다른 픽은 변경되지 않습니다.
디코더가 이러한 정도의 투명성 처리만 제공한다면, 풀 알파 채널을 처리할 때 모든 비영(非零) 알파 값을 완전 불투명으로 처리하거나 디더링하여 처리해야 합니다. 어느 쪽도 사전
곱(alpha-associated) 형식에서 변환된 이미지에 대해 매우 좋은 결과를 주지는 않지만 아무 것도 하지 않는 것보다는 낫습니다. 전체 알파를 이진 알파로 디더링하는 것은
그레이스케일을 흑백으로 디더링하는 것과 매우 유사합니다. 단, 완전 투명 및 완전 불투명 픽은 디더링으로 인해 변경되지 않아야 합니다.
인덱스-컬러 하드웨어에서 truecolor 이미지를 출력하려 하거나,
또는 팔레트가 frame buffer에 비해 너무 큰 인덱스-컬러 이미지를 표시하려는 뷰어의 경우,
인코더가 하나 이상의 제안 팔레트(sPLT 청크)를 제공했을 수 있습니다. 크기나 이름 등을 기준으로 적합한 제안 팔레트가
발견되면 PNG 디코더는 해당 팔레트를 사용할 수 있습니다. 디코더가 필요로 하는 샘플 깊이와 다른 샘플 깊이를 가진 제안 팔레트는 샘플 깊이 재스케일링으로 변환할 수 있습니다(참조:
13.12 Sample depth
rescaling).
배경이 단색인 경우, 뷰어는 이미지를 그 단색 배경과 함께 composite하고 제안된 팔레트에 대해 그 결과 이미지를 양자화하여 RGB 팔레트를 얻어야 합니다. 이미지가
투명도를 사용하고 배경이 단색이 아닌 경우에는 제안 팔레트가 유용하지 않을 가능성이 높습니다.
truecolor
이미지의 경우, 제안 팔레트가 PLTE 청크로 제공될 수도 있습니다. 이미지에 tRNS 청크가 있고 배경이 단색인 경우, 뷰어는 원하는 배경 색상에 맞게 제안 팔레트를 조정해야 합니다. 이를 위해서는 tRNS 색상과 가장 가까운 팔레트 항목을 원하는 배경 색으로 교체하거나, 뷰어가 PLTE 항목 수보다 더 많은 색을 처리할 수 있다면 배경 색에 대한 팔레트 항목을 추가할 수 있습니다.
color
type 6(truecolor with
alpha) 이미지의 경우, 어떤 PLTE 청크도 bKGD 청크로 지정된 단일 배경 색에 대한 표시를 염두에 두고 설계되었어야 합니다. 뷰어가 다른 배경을 사용하려 하거나 bKGD 청크가 없으면 팔레트를 무시하는 것이 바람직할 것입니다. 뷰어는 원래 의도된 배경과 다른 배경에 대해 제안
팔레트를 사용할 수 있지만, 그 결과가 좋지 않을 수 있습니다.
뷰어가 투명한 truecolor 이미지를 단일 색보다 복잡한 배경 위에 표시한다면, 제안 팔레트는 합성(composite)된 이미지에 대해 최적이 아닐 가능성이 높습니다. 이 경우에는 truecolor PNG 이미지와 배경 이미지에 대해 먼저 truecolor 합성 단계를 수행한 다음, 그
결과 이미지를 색상 양자화하는 것이 최선입니다.
truecolor
PNG 데이터스트림에서 PLTE와 sPLT 청크가 모두
나타나면, PNG 디코더는 둘이 제안하는 팔레트들 중에서 선택할 수 있으며 위에 설명된 서로 다른 투명도 의미론을 고려해야 합니다.
sPLT 및 hIST 청크의 빈도 정보는 뷰어가 PNG
데이터스트림에 사용된 만큼의 색을 제공할 수 없을 때 유용합니다. 뷰어가 몇 개의 색만 부족한 경우에는 보통 팔레트에서 가장 적게 사용된 색을 제거하는 것으로 충분합니다. 색 수를 크게
줄여야 할 때는 기존 팔레트의 부분집합을 쓰려고 하기보다 전혀 새로운 대표 색들을 선택하는 것이 낫습니다. 이는 새로운 색상 양자화 단계를 수행하는 것과 같지만, 기존 팔레트와
히스토그램을 입력 데이터로 사용하면 IDAT 청크의 image data를 다시 스캔하지 않아도
됩니다.
제안 팔레트가 제공되지 않는 경우, 디코더는 자체 팔레트를 개발할 수 있지만 이는 IDAT 청크의 image
data를 한 번 더 통과해야 하는 비용이 듭니다. 또는 기본 팔레트(보통 색상 큐브)를 사용할 수도 있습니다.
또한 12.5 Suggested
palettes를 참조하십시오.
