PNG

다른 뜻에 대해서는 PNG (동음이의) 문서를 참고하십시오.

포터블 네트워크 그래픽스

8비트 투명 채널을 사용한 PNG 그림을 격자 무늬 배경에 오버레이했을 때의 모습. 투명도를 표시하기 위해 그래픽스 소프트웨어에 보통 사용된다.
파일 확장자	.png
인터넷 미디어 타입	image/png
타입 코드	PNGf PNG
UTI	public.png
매직 넘버	89 50 4e 47 0d 0a 1a 0a
개발	PNG Development Group (W3C에 기부)
발표일	1996년 10월 1일(1996-10-01)
포맷 종류	비손실 비트맵 이미지 포맷
다음으로 확장	APNG, JNG, MNG
표준	ISO/IEC 15948, IETF RFC 2083
오픈 포맷?	예

포터블 네트워크 그래픽스(Portable Network Graphics; PNG, /pɪŋ/)는 손실 없는 데이터 압축을 지원하는 래스터 그래픽스 파일 형식이다. PNG는 GIF의 개선된, 특허 없는 대체 형식으로 개발되었다.

PNG는 팔레트 기반 이미지(RGB 24비트 또는 RGBA 32비트 색상의 팔레트 포함), 회색조 이미지(투명도용 알파 채널 유무에 관계없이), 그리고 풀 컬러 비팔레트 기반 RGB 또는 RGBA 이미지를 지원한다. PNG 워킹 그룹은 전문가 수준의 인쇄용 그래픽이 아닌 인터넷에서 이미지를 전송하기 위한 형식으로 PNG를 설계했기 때문에, CMYK와 같은 비-RGB 색 공간은 지원되지 않는다. PNG 파일은 기본 화소 및 텍스트 주석, 무결성 검사와 같은 기타 정보를 RFC 2083에 문서화된 청크의 확장 가능한 구조로 인코딩한 단일 이미지를 포함한다.

PNG 파일은 ".png" 파일 확장자와 "image/png" MIME 미디어 타입을 갖는다. PNG는 1997년 3월 정보 RFC 2083으로, 2004년에는 ISO/IEC 15948 표준으로 발표되었다.

역사 및 개발

 GIF § Unisys and LZW patent enforcement 문서를 참고하십시오.

PNG 형식 생성 동기는 1994년 12월 28일 GIF 형식 구현에 유니시스의 GIF에 사용된 Lempel-Ziv-Welch(LZW) 데이터 압축 알고리즘 특허로 인해 로열티를 지불해야 한다는 발표였다. 이로 인해 유즈넷 사용자들로부터 비난이 쇄도했다. 그 중 한 명인 토마스 부텔은 1995년 1월 4일 유즈넷 뉴스그룹 "comp.graphics"에 GIF의 무료 대안에 대한 계획을 세우는 선행 토론 스레드를 게시했다. 해당 스레드의 다른 사용자들은 나중에 최종 파일 형식의 일부가 될 많은 제안을 내놓았다. 인기 있는 JPEG 뷰어 QPEG의 저자 올리버 프롬은 PING이라는 이름을 제안했으며, 이는 결국 PNG가 되었고, 이는 PING is not GIF를 의미하는 재귀 약자이다. 그리고 .png 확장자도 제안했다. 나중에 구현된 다른 제안으로는 디플레이트 압축 알고리즘과 24비트 컬러 지원이 포함되었는데, GIF에서 후자가 없었던 것도 팀이 자체 파일 형식을 만들도록 동기를 부여했다. 이 그룹은 PNG 개발 그룹으로 알려지게 되었고, 논의가 빠르게 확장되면서 나중에는 컴퓨서브 포럼과 관련된 메일링 리스트를 사용했다.

PNG의 전체 사양은 1996년 10월 1일 월드 와이드 웹 컨소시엄 (W3C)의 승인 하에 발표되었고, 이후 1997년 1월 15일 RFC 2083으로 발표되었다. 이 사양은 1998년 12월 31일 버전 1.1으로 개정되었고, 감마 보정 및 색 보정에 대한 기술적 문제를 다루었다. 1999년 8월 11일 출시된 버전 1.2는 iTXt 청크를 사양의 유일한 변경 사항으로 추가했으며, 1.2의 재포맷된 버전은 2003년 11월 10일 W3C 표준의 두 번째 에디션으로, 2004년 3월 3일 국제 표준(ISO/IEC 15948:2004)으로 출시되었다.

GIF는 컴퓨터 애니메이션을 허용하지만, PNG는 처음에 단일 이미지 형식으로 결정되었다. 2001년에 PNG 개발자들은 애니메이션을 지원하는 멀티플 이미지 네트워크 그래픽스(MNG) 형식을 발표했다. MNG는 중간 정도의 애플리케이션 지원을 받았지만, 주류 웹 브라우저에서는 충분하지 않았고 웹 사이트 디자이너나 게시자들 사이에서는 전혀 사용되지 않았다. 2008년에 일부 모질라 개발자들은 비슷한 목표를 가진 APNG 형식을 발표했다. APNG는 게코 및 프레스토 기반 웹 브라우저에서 기본적으로 지원되는 형식이며, 소니의 플레이스테이션 포터블 시스템에서 썸네일로도 일반적으로 사용된다(일반 PNG 파일 확장자 사용). 2017년, 크로미엄 기반 브라우저가 APNG 지원을 채택했다. 2020년 1월, 마이크로소프트 엣지가 크로미엄 기반이 되면서 APNG 지원을 상속받았다. 이로써 모든 주요 브라우저가 이제 APNG를 지원한다.

PNG 워킹 그룹은 2021년 9월 14일부터 W3C의 승인을 받아 PNG 사양을 유지하고 개발하는 임무를 맡게 되었다. APNG, 높은 동적 범위(HDR) 및 Exif 데이터에 대한 적절한 지원을 추가한 PNG 사양의 세 번째 에디션은 2022년 10월 25일에 첫 번째 공개 작업 초안으로 그리고 2025년 6월 24일에 최종적으로 W3C 권고안으로 발표되었다.

PNG 워킹 그룹

원래 PNG 사양은 컴퓨터 그래픽스 전문가 및 애호가로 구성된 임시 그룹이 작성했다. 형식에 대한 논의와 결정은 이메일로 진행되었다. RFC 2083에 나열된 원래 저자는 다음과 같다.

• 편집자: 토마스 부텔
• 기여 편집자: 톰 레인
• 저자 (성별 알파벳순): 마크 애들러, 토마스 부텔, 크리스천 브룬첸, 애덤 M. 코스텔로, 리 다니엘 크로커, 안드레아스 딜거, 올리버 프롬, 장-루 가일리, 크리스 허보스, 알렉스 야쿨린, 닐 케틀러, 톰 레인, 알렉산더 레만, 크리스 릴리, 데이브 마틴데일, 오웬 모텐센, 키스 S. 피켄스, 로버트 P. 풀, 글렌 랜더스-페어슨, 그레그 로엘프스, 빌렘 반 스하이크, 가이 샬나트, 폴 슈미트, 팀 웨그너, 제레미 볼

파일 형식

우분투용 헥사 편집기 애플리케이션으로 본 PNG 이미지

파일 헤더

PNG 파일은 8바이트 시그니처로 시작한다. (오른쪽의 헥사 편집기 이미지 참조):

값 (16진수)	목적
89	8비트 데이터를 지원하지 않는 전송 시스템을 감지하고 텍스트 파일이 PNG로 잘못 해석되거나 그 반대의 경우를 줄이기 위해 최상위 비트가 설정되어 있다.
504E47	ASCII로 PNG 글자이며, 텍스트 편집기에서 볼 때 형식을 쉽게 식별할 수 있다.
0D 0A	데이터의 DOS-유닉스 줄 끝 변환을 감지하는 DOS 스타일 줄 끝(CRLF).
1A	명령 type이 사용되었을 때 DOS에서 파일 표시를 중지하는 바이트(파일 끝 문자).
0A	유닉스-DOS 줄 끝 변환을 감지하는 유닉스 스타일 줄 끝(LF).

파일 내의 "청크"

헤더 다음에는 이미지에 대한 특정 정보를 전달하는 일련의 청크가 온다. 청크는 필수 또는 보조로 선언되며, 이해하지 못하는 보조 청크를 만난 프로그램은 이를 안전하게 무시할 수 있다. 이러한 청크 기반 저장 계층 구조는 컨테이너 형식 또는 아미가'의 교환 파일 형식(IFF)과 개념적으로 유사하며, PNG 형식이 이전 버전과의 호환성을 유지하면서 확장될 수 있도록 설계되었다. 이는 상위 호환성을 제공하며, 동일한 파일 구조(다른 시그니처 및 청크 포함)는 관련 MNG, JNG, 및 APNG 형식에도 사용된다.

청크는 길이(4바이트, 빅 엔디언), 청크 타입/이름(4바이트), 청크 데이터(길이 바이트) 및 CRC(순환 중복 코드/체크섬; 4바이트)로 구성된다. CRC는 청크 타입과 청크 데이터에 대해 계산되지만 길이는 제외한 네트워크 바이트 순서의 CRC-32이다.

길이	청크 타입	청크 데이터	CRC
4바이트	4바이트	길이 바이트	4바이트

청크 타입은 네 글자의 대소문자 구분 ASCII 타입/이름으로 지정된다. FourCC와 비교한다. 이름의 다른 글자들의 대소문자(문자의 숫자 값의 비트 5)는 비트 필드로, 디코더에게 이해하지 못하는 청크의 성격에 대한 일부 정보를 제공한다.

첫 번째 글자의 대소문자는 청크가 필수인지 아닌지를 나타낸다. 첫 번째 글자가 대문자이면 청크는 필수이다. 그렇지 않으면 청크는 보조이다. 필수 청크는 파일을 읽는 데 필요한 정보를 포함한다. 디코더가 인식하지 못하는 필수 청크를 만나면 파일을 읽는 것을 중단하거나 사용자에게 적절한 경고를 제공해야 한다.

두 번째 글자의 대소문자는 청크가 "공개"(사양 또는 특수 목적 공개 청크 레지스트리에 있음)인지 "비공개"(표준화되지 않음)인지를 나타낸다. 대문자는 공개이고 소문자는 비공개이다. 이는 공개 및 비공개 청크 이름이 서로 충돌하지 않도록 보장한다(두 개의 비공개 청크 이름이 충돌할 수 있음).

세 번째 글자는 PNG 사양을 따르기 위해 대문자여야 한다. 이는 미래 확장을 위해 예약되어 있다. 디코더는 소문자 세 번째 글자를 가진 청크를 다른 인식되지 않는 청크와 동일하게 처리해야 한다.

네 번째 글자의 대소문자는 인식하지 못하는 편집기에 의해 청크가 안전하게 복사될 수 있는지 여부를 나타낸다. 소문자이면 파일에 대한 수정 정도에 관계없이 청크를 안전하게 복사할 수 있다. 대문자이면 수정 사항이 필수 청크를 건드리지 않은 경우에만 복사할 수 있다.

필수 청크

디코더는 PNG 파일을 읽고 렌더링하기 위해 필수 청크를 해석할 수 있어야 한다.

• IHDR은 첫 번째 청크여야 하며, 다음 정보를 (이 순서대로) 포함한다.
  • 너비 (4바이트)
  • 높이 (4바이트)
  • 비트 깊이 (1바이트, 값 1, 2, 4, 8 또는 16)
  • 컬러 타입 (1바이트, 값 0, 2, 3, 4 또는 6)
  • 압축 방식 (1바이트, 값 0)
  • 필터 방식 (1바이트, 값 0)
  • 인터레이스 방식 (1바이트, 값 0 "인터레이스 없음" 또는 1 "아담7 인터레이스") (총 13 데이터 바이트).

월드 와이드 웹 컨소시엄에 명시된 대로, 비트 깊이는 "샘플당 또는 팔레트 인덱스당 비트 수(픽셀당 아님)"로 정의된다.

• PLTE는 팔레트: 색상 목록을 포함한다.
• IDAT는 이미지를 포함하며, 여러 IDAT 청크로 분할될 수 있다. 이러한 분할은 파일 크기를 약간 증가시키지만, 스트리밍 방식으로 PNG를 생성할 수 있게 한다. IDAT 청크는 압축 알고리즘의 출력 스트림인 실제 이미지 데이터를 포함한다.
• IEND는 이미지 끝을 표시한다. IEND 청크의 데이터 필드는 0바이트/비어 있다.

PLTE 청크는 컬러 타입 3 (인덱스 컬러)에 필수적이다. 컬러 타입 2와 6 (트루컬러 및 알파가 있는 트루컬러)에는 선택 사항이며, 컬러 타입 0과 4 (회색조 및 알파가 있는 회색조)에는 나타나서는 안 된다.

보조 청크

PNG 파일에 저장될 수 있는 다른 이미지 속성으로는 감마 값, 배경색, 텍스트 메타데이터 정보가 있다. PNG는 또한 ICC 색상 프로파일을 포함하여 색 관리를 지원한다.

• bKGD는 기본 배경색을 제공한다. 이는 독립 실행형 이미지 뷰어(웹 브라우저는 아님; 자세한 내용은 아래 참조)와 같이 더 나은 선택이 없을 때 사용하기 위한 것이다.
• cHRM은 디스플레이 원색 및 화이트 포인트의 색도 좌표를 제공한다.
• cICP는 ITU-T H.273에 정의된 색 공간, 전송 함수 및 행렬 계수를 지정한다. 이는 색상 프로파일 없이 HDR 이미지와 함께 사용하기 위한 것이다.
• dSIG는 디지털 서명을 저장하기 위한 것이다.
• eXIf는 Exif 메타데이터를 저장한다.
• gAMA는 감마를 지정한다. gAMA 청크는 4바이트만 포함하며, 그 값은 감마 값에 100,000을 곱한 것을 나타낸다. 예를 들어, 감마 값 1/3.4는 29411.7647059((1/3.4)*100,000)로 계산되어 정수(29412)로 변환되어 저장된다.
• hIST는 이미지의 각 색상에 대한 히스토그램 또는 총량을 저장할 수 있다.
• iCCP는 ICC 색상 프로파일이다.
• iTXt는 키워드와 UTF-8 텍스트를 포함하며, 압축 및 번역 가능성에 대한 인코딩은 IETF 언어 태그로 표시된다. XMP는 'XML:com.adobe.xmp' 키워드를 사용하여 이 청크를 사용한다.
• pHYs는 의도된 픽셀 크기(또는 픽셀 종횡비)를 포함한다. pHYs는 "단위당 픽셀, X축"(4바이트), "단위당 픽셀, Y축"(4바이트) 및 "단위 지정자"(1바이트)를 포함하여 총 9바이트이다.
• sBIT(유효 비트)는 원본 데이터의 색상 정확도를 나타낸다. 이 청크는 색상 유형에 따라 총 1바이트에서 5바이트 사이를 포함한다.
• sPLT는 전체 색상 범위를 사용할 수 없는 경우 사용할 팔레트를 제안한다.
• sRGB는 표준 sRGB 색 공간이 사용됨을 나타낸다. sRGB 청크는 1바이트만 포함하며, 이는 "렌더링 의도"(렌더링 의도를 위해 0, 1, 2, 3의 4가지 값이 정의됨)에 사용된다.
• sTER은 스테레오스코피 이미지용 스테레오 이미지 표시 청크이다.
• tEXt는 ISO/IEC 8859-1로 표현될 수 있는 텍스트를 저장할 수 있으며, 각 청크에 대해 하나의 키-값 쌍을 갖는다. "키"는 1자에서 79자 사이여야 한다. 구분자는 널 문자이다. "값"은 키워드 길이와 구분자를 제외한 최대 청크 크기까지 임의의 길이를 가질 수 있으며, 0바이트일 수도 있다. "키"와 "값" 모두 널 문자를 포함할 수 없다. 선행 또는 후행 공백도 허용되지 않는다.
• tIME은 이미지가 마지막으로 변경된 시간을 저장한다.
• tRNS는 투명도 정보를 포함한다. 인덱싱된 이미지의 경우, 하나 이상의 팔레트 항목에 대한 알파 채널 값을 저장한다. 트루컬러 및 회색조 이미지의 경우, 완전히 투명한 것으로 간주될 단일 픽셀 값을 저장한다.
• zTXt는 압축된 텍스트(및 압축 방식 마커)를 포함하며, tEXt와 동일한 제한을 갖는다.

픽셀 형식

색상 유형 및 비트 깊이의 허용된 조합

색상 유형	채널	채널당 비트
		1	2	4	8	16
인덱스	1	1	2	4	8
회색조	1	1	2	4	8	16
회색조 및 알파	2				16	32
트루컬러	3				24	48
트루컬러 및 알파	4				32	64

PNG 이미지의 픽셀은 팔레트의 샘플 데이터 인덱스이거나 샘플 데이터 자체일 수 있는 숫자이다. 팔레트는 PLTE 청크에 포함된 별도의 테이블이다. 단일 화소의 샘플 데이터는 1개에서 4개 사이의 숫자 튜플로 구성된다. 픽셀 데이터가 팔레트 인덱스를 나타내든 명시적 샘플 값을 나타내든, 이 숫자들은 채널이라고 불리며 이미지의 모든 숫자는 동일한 형식으로 인코딩된다.

허용되는 형식은 각 숫자를 고정된 비트 수(PNG 사양에서는 비트 깊이라고 함)를 사용하여 부호 없는 정수 값으로 인코딩한다. 이는 일반적으로 각 채널이 아닌 각 픽셀의 총 비트 수를 나타내는 색 깊이와는 다르다. 허용되는 비트 깊이는 표에 각 픽셀에 사용되는 총 비트 수와 함께 요약되어 있다.

채널 수는 이미지가 회색조인지 색상인지, 그리고 알파 채널을 가지고 있는지 여부에 따라 달라진다. PNG는 컬러 타입이라고 불리는 다음과 같은 채널 조합을 허용한다.

PNG 파일의 색 깊이 시연(채널당 비트). 왼쪽: 8비트; 오른쪽: 16비트. 아티팩트에 주목하고, 선명도를 위해 대비를 조정했다.

0 (0002)	회색조
2 (0102)	빨강, 초록, 파랑: rgb/트루컬러
3 (0112)	인덱스: 색상 팔레트의 인덱스를 포함하는 채널
4 (1002)	회색조 및 알파: 각 픽셀의 불투명도 수준
6 (1102)	빨강, 초록, 파랑 및 알파

색상 유형은 8비트 값으로 지정되지만 하위 3비트만 사용되며, 위에서 나열된 5가지 조합만 허용된다. 따라서 색상 유형이 유효하다면 인접한 표에 요약된 대로 비트 필드로 간주될 수 있다.

PNG 색상 유형

색상 유형	이름	이진				마스크
			A	C	P
0	회색조	0	0	0	0
2	트루컬러	0	0	1	0	color
3	인덱스	0	0	1	1	color, palette
4	회색조 및 알파	0	1	0	0	alpha
6	트루컬러 및 알파	0	1	1	0	alpha, color

• 비트 값 1: 이미지 데이터는 팔레트 인덱스를 저장한다. 이는 비트 값 2와의 조합에서만 유효하다.
• 비트 값 2: 이미지 샘플은 삼색형 색을 인코딩하는 세 개의 데이터 채널을 포함하며, 그렇지 않으면 이미지 샘플은 상대 휘도를 인코딩하는 하나의 데이터 채널을 포함한다.
• 비트 값 4: 이미지 샘플은 픽셀의 불투명도를 선형으로 측정한 알파 채널도 포함한다. 이는 비트 값 1과의 조합에서는 유효하지 않다.

인덱스 색상 이미지의 경우, 팔레트는 항상 채널당 8비트(팔레트 항목당 24비트) 깊이로 삼색형 색상을 저장한다. 또한, 팔레트 항목에 대한 8비트 알파 값 목록을 선택적으로 포함할 수 있다. 포함되지 않거나 팔레트보다 짧은 경우, 나머지 팔레트 항목은 완전히 불투명한 것으로 간주된다. 팔레트는 이미지 비트 깊이가 허용하는 것보다 많은 항목을 가질 수 없지만, 더 적을 수 있다(예: 8비트 픽셀을 가진 이미지가 90가지 색상만 사용하는 경우 256가지 색상 모두에 대한 팔레트 항목이 필요하지 않음). 팔레트는 이미지에 존재하는 모든 픽셀 값에 대한 항목을 포함해야 한다.

표준은 인덱스 색상 PNG가 픽셀당 1, 2, 4 또는 8비트를 가질 수 있도록 허용한다. 알파 채널이 없는 회색조 이미지는 픽셀당 1, 2, 4, 8 또는 16비트를 가질 수 있다. 다른 모든 것은 채널당 비트 깊이를 8 또는 16으로 사용한다. 허용되는 조합은 위 표에 나와 있다. 표준은 디코더가 지원되는 모든 색상 형식을 읽을 수 있어야 한다고 요구하지만, 많은 이미지 편집기는 그 중 일부만 생성할 수 있다.

이미지의 투명도

PNG는 다양한 투명도 옵션을 제공한다. 트루컬러 및 회색조 이미지의 경우 단일 픽셀 값을 투명하게 선언하거나 알파 채널을 추가할 수 있다(부분 투명도 사용 가능). 팔레트 이미지의 경우 팔레트 항목에 알파 값을 추가할 수 있다. 저장되는 이러한 값의 수는 총 팔레트 항목 수보다 적을 수 있으며, 이 경우 나머지 항목은 완전히 불투명한 것으로 간주된다.

이진 투명도를 위한 픽셀 값 스캔은 의도치 않게 픽셀이 투명해지는 것을 방지하기 위해 어떤 색상 감소보다 먼저 수행되어야 한다. 이는 16비트-채널 이미지를 디코딩할 수 있지만(사양 준수를 위해 필요) 채널당 8비트만 출력하는 시스템(최고급 시스템을 제외한 모든 시스템의 표준)에서 가장 큰 문제가 될 수 있다.

알파 저장은 "연관"(미리 곱셈) 또는 "비연관"일 수 있지만, PNG는 이미지에 알파 인코딩이 되어 있지 않음을 의미하는 "비연관"("비미리 곱셈") 알파를 표준화했다. 이는 오버 작업이 RGB 방출에 알파를 곱할 것이며, 방출과 폐색을 적절하게 나타낼 수 없음을 의미한다.

압축

PNG는 두 단계 압축 과정을 사용한다.

• 사전 압축: 필터링(예측)
• 압축: DEFLATE

PNG는 LZ77과 허프먼 코딩의 조합을 포함하는 특허가 없는 손실 없는 데이터 압축 알고리즘인 DEFLATE를 사용한다. 관대한 라이선스를 가진 DEFLATE 구현체는 널리 사용 가능하다.

JPEG와 같은 손실 압축 형식과 비교할 때, 평균보다 높은 압축 설정을 선택하면 처리 시간이 지연되지만 파일 크기가 크게 줄어들지는 않는 경우가 많다.

필터링

PNG의 필터 메소드 0은 픽셀 A, B, C의 데이터를 사용하여 X의 값을 예측할 수 있다.

256가지 색상의 PNG로, 사전 필터링을 사용하면 251바이트에 불과하다. 같은 이미지를 GIF로 만들면 13배 이상 커질 것이다.

DEFLATE를 적용하기 전에 데이터는 예측 방법을 통해 변환된다. 전체 이미지에 대해 단일 필터 방법이 사용되는 반면, 각 이미지 라인에 대해 데이터를 보다 효율적으로 압축할 수 있도록 필터 유형이 선택된다. 스캔라인에 사용되는 필터 유형은 인라인 압축 해제를 가능하게 하기 위해 스캔라인 앞에 추가된다.

현재 PNG 사양에는 하나의 필터 방법(방법 0으로 표시)만 있으며, 따라서 실제로는 각 줄에 어떤 필터 유형을 적용할지 선택하는 것뿐이다. 이 방법의 경우, 필터는 이전 인접 픽셀의 값을 기반으로 각 픽셀의 값을 예측하고, DPCM과 같이 예측된 픽셀 색상 값을 실제 값에서 뺀다. 이 방식으로 필터링된 이미지 줄은 원시 이미지 줄보다 더 압축 가능한 경우가 많다. 특히 위 줄과 유사한 경우, 예측과의 차이가 일반적으로 0 주변에 모여들고 가능한 모든 이미지 값에 퍼지지 않기 때문이다. 이는 DEFLATE가 이미지를 2D 개체로 이해하지 않고 단순히 바이트 스트림으로 보기 때문에 별도의 행을 연결하는 데 특히 중요하다.

필터 메서드 0에는 5가지 필터 유형이 있다. 각 유형은 왼쪽 픽셀(A), 위 픽셀(B), 왼쪽 위 픽셀(C) 또는 이들의 조합에 해당하는 바이트를 기반으로 각 바이트(필터링 전 이미지 데이터의) 값을 예측하고, 예측 값과 실제 값 간의 차이를 인코딩한다. 필터는 픽셀이 아닌 바이트 값에 적용된다. 픽셀 값은 1 또는 2바이트일 수 있거나 바이트당 여러 값일 수 있지만, 바이트 경계를 넘지 않는다. 필터 유형은 다음과 같다.

유형 바이트	필터 이름	예측 값
0	None	0 (원시 바이트 값이 변경되지 않고 통과함)
1	Sub	바이트 A (왼쪽)
2	Up	바이트 B (위)
3	Average	바이트 A와 B의 평균을 반올림
4	Paeth	p = A + B − C에 가장 가까운 A, B 또는 C

Paeth 필터는 앨런 W. 패스의 알고리즘을 기반으로 한다. 무손실 JPEG에서 사용되는 DPCM 버전과 1 × 2, 2 × 1 또는 (Paeth 예측기의 경우) 2 × 2 창 및 하르 웨이블릿을 사용하는 이산 웨이블릿 변환과 비교한다.

압축은 라인별로 필터 유형을 적응적으로 선택함으로써 더욱 향상된다. 이러한 개선과 PNG 작성 소프트웨어에서 일반적으로 사용되는 경험적 구현 방법은 리 다니엘 크로커에 의해 만들어졌으며, 그는 형식 생성 중에 많은 이미지에서 이러한 방법을 테스트했다. 필터 선택은 아래에서 논의하는 파일 크기 최적화의 구성 요소이다.

인터레이싱이 사용되는 경우, 인터레이싱의 각 단계는 별도로 필터링되어 각 단계가 수신됨에 따라 이미지가 점진적으로 렌더링될 수 있다. 그러나 인터레이싱은 일반적으로 압축 효율성을 떨어뜨린다.

인터레이싱

16x16 이미지에 대한 Adam7 인터레이싱의 예시

PNG는 선택적인 2차원, 7패스 인터레이싱 스킴인 아담7 알고리즘을 제공한다. 이는 GIF의 1차원, 4패스 스킴보다 더 정교하며, 특히 쌍입방 보간법과 같은 보간 알고리즘이 사용될 경우 전송 초기에 더 선명한 저해상도 이미지를 볼 수 있게 한다.

그러나 7패스 스킴은 단순한 스킴보다 데이터의 압축성을 더 감소시키는 경향이 있다.

애니메이션

APNG(애니메이션 PNG) 파일(일부 웹 브라우저에서는 정적 이미지로 표시됨)

핵심 PNG 형식은 애니메이션을 지원하지 않는다. MNG는 PNG 그룹 구성원들이 설계한 PNG 확장으로 애니메이션을 지원한다. MNG는 PNG의 기본 구조와 청크를 공유하지만, 훨씬 더 복잡하며 표준 PNG 디코더와 호환되지 않는 다른 파일 시그니처를 가지고 있다. 이는 대부분의 웹 브라우저와 애플리케이션이 MNG를 지원하지 않거나 지원을 중단했다는 것을 의미한다.

MNG의 복잡성으로 인해 모질라 재단 개발자들이 APNG를 제안하게 되었다. APNG는 PNG를 기반으로 하며, 애니메이션을 지원하고 MNG보다 간단하다. APNG는 APNG를 지원하지 않는 PNG 디코더를 위해 단일 이미지 표시로 폴백 기능을 제공한다. 현재 APNG 형식은 모든 주요 웹 브라우저에서 지원된다. APNG는 Firefox 3.0 이상, Pale Moon (모든 버전), 그리고 Safari 8.0 이상에서 지원된다. 크로미엄 59.0은 APNG 지원을 추가했고, 이어서 구글 크롬도 지원했다. Opera는 10-12.1 버전에서 APNG를 지원했지만, 15버전에서 Blink 렌더링 엔진으로 전환하면서 지원이 중단되었다. 이후 Opera 46에서 재지원되었다(크로미엄 59에서 상속). 마이크로소프트 엣지는 크로미엄 기반 엔진으로 전환한 79.0 버전부터 APNG를 지원하고 있다.

PNG 그룹은 2007년 4월 APNG를 채택하지 않기로 결정했다. ANG, aNIM/mPNG, "PNG in GIF", 그리고 그 하위 집합인 "RGBA in GIF"를 포함한 여러 대안이 논의 중이었다. 그러나 현재는 APNG만이 널리 지원되고 있다.

2025년 6월 PNG 워킹 그룹에서 유지보수하는 PNG 사양의 세 번째 에디션이 출시되면서, APNG는 마침내 확장 기능으로 사양에 포함되었다.

예시

매우 간단한 PNG 파일의 구조

89 50 4E 47 0D 0A 1A 0A PNG 시그니처

IHDR 이미지 헤더

IDAT 이미지 데이터

IEND 이미지 끝

빨간색 픽셀 하나를 나타내는 최소 PNG 파일의 내용

16진수	문자
89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 00 01 00 00 00 01 08 02 00 00 00 90 77 53 DE 00 00 00 0C 49 44 41 54 08 D7 63 F8 CF C0 00 00 03 01 01 00 18 DD 8D B0 00 00 00 00 49 45 4E 44 AE 42 60 82	.PNG........IHDR ..............wS .....IDAT..c.... .............IEN D.B`.

IHDR 청크

청크 내 오프셋	16진수 값	10진수 값	텍스트	의미
0	0x0D	13		IHDR 청크는 13바이트의 내용을 가짐
4	0x49484452		IHDR	헤더 청크 식별
8	0x01	1		이미지 너비 1픽셀
12	0x01	1		이미지 높이 1픽셀
16	0x08	8		픽셀당 8비트 (채널당)
17	0x02	2		컬러 타입 2 (RGB/트루컬러)
18	0x00	0		압축 방식 0 (유일하게 허용되는 값)
19	0x00	0		필터 방식 0 (유일하게 허용되는 값)
20	0x00	0		인터레이스 없음
21	0x907753DE			청크의 타입과 내용에 대한 CRC (길이는 제외)

IDAT 청크

청크 내 오프셋	16진수 값	의미
0	0x0C	IDAT 청크는 12바이트의 내용을 가짐
4	0x49444154	데이터 청크 식별
8	0x08	256바이트 윈도우를 사용하는 DEFLATE 압축 방식
9	0xD7	Zlib FCHECK 값, 사전 미사용, 최대 압축 알고리즘
10	0x63F8CFC00000	0x00 0xFF 0x00 0x00으로 디코딩되는 정적 허프먼 코드를 사용하는 압축된 DEFLATE 블록
16	0x03010100	ZLIB 체크 값: 압축되지 않은 데이터의 애들러-32 체크섬
20	0x18DD8DB0	청크의 타입과 내용에 대한 CRC (길이는 제외)

헥사 편집기 방식으로 표시되며, 왼쪽에는 16진수 형식으로 바이트 값이 표시되고, 오른쪽에는 인식되지 않는 제어 문자가 점으로 대체된 ISO/IEC 8859-1 해당 문자가 표시된다. 또한 PNG 시그니처와 개별 청크는 색상으로 표시된다. 인간이 읽을 수 있는 타입 이름(이 예시에서는 PNG, IHDR, IDAT, IEND)으로 인해 쉽게 식별할 수 있다.

장점

PNG를 사용하는 이유:

• 이식성: 소프트웨어 및 하드웨어 플랫폼에 관계없이 전송 가능.
• 완전성: 트루 컬러, 인덱스 컬러, 회색조 이미지를 표현할 수 있음.
• 직렬 코딩 및 디코딩: 직렬 통신을 통해 데이터 스트림을 직렬로 생성하고 읽을 수 있으며, 이는 이미지의 생성 및 시각화에 사용되는 데이터 스트림 형식이다.
• 점진적 표시: 전체 이미지의 초기 근사치인 데이터 흐름을 전송하고 데이터 흐름이 수신됨에 따라 점진적으로 개선할 수 있음.
• 전송 오류에 대한 건전성: 데이터 스트림의 전송 오류를 정확하게 감지.
• 무손실: 손실 없음: 필터링 및 압축은 모든 정보를 보존.
• 효율성: 모든 점진적 이미지 표시, 압축 및 필터링은 효율적인 디코딩 및 표시를 추구.
• 압축: 이미지를 효율적이고 일관되게 압축할 수 있음.
• 용이성: 표준 구현이 용이.
• 호환성: 표준을 따르는 모든 PNG 디코더는 모든 PNG 데이터 스트림을 읽을 수 있음.
• 유연성: 이전 지점에 영향을 주지 않고 향후 확장 및 비공개 추가를 허용.
• 법적 제한으로부터의 자유: 사용되는 알고리즘은 자유롭고 접근 가능.

다른 파일 형식과의 비교

 이 부분의 본문은 그래픽 파일 형식 비교입니다.

GIF

• 작은 이미지에서는 GIF가 PNG보다 더 높은 압축률을 달성할 수 있다(아래 파일 크기 섹션 참조).
• 위 경우를 제외한 대부분의 이미지에서 GIF 파일은 인덱스 PNG 이미지보다 크기가 더 크다.
• PNG는 알파 채널 투명도를 포함하여 GIF보다 훨씬 다양한 투명도 옵션을 제공한다.
• GIF는 8비트 인덱스 컬러로 제한되는 반면, PNG는 24비트(채널당 8비트) 및 48비트(채널당 16비트) 트루컬러를 포함하여 훨씬 더 넓은 색상 깊이 범위를 제공하여 더 높은 색상 정확도, 더 부드러운 페이드 등을 허용한다. 알파 채널이 추가되면 픽셀당 최대 64비트(압축 전)까지 가능하다.
• PNG 형식에서 GIF로 이미지를 변환할 때, PNG 이미지가 256가지 이상의 색상을 가지고 있다면 포스터화로 인해 이미지 품질이 저하될 수 있다.
• GIF는 본질적으로 애니메이션 이미지를 지원한다. PNG는 확장 기능을 통해서만 애니메이션을 지원한다(위 애니메이션 섹션 참조).

PNG 이미지는 오래된 브라우저에서 덜 널리 지원된다. 특히 IE6은 PNG를 제한적으로 지원한다.

JPEG

JPEG의 손실 압축과 PNG의 비손실 압축을 비교한 복합 이미지: JPEG 아티팩트는 이러한 종류의 이미지 데이터 배경에서 쉽게 볼 수 있지만, PNG 이미지는 단색이다.

JPEG (Joint Photographic Experts Group) 형식은 사진 (및 사진과 유사한) 이미지의 경우 PNG보다 더 작은 파일을 생성할 수 있다. JPEG는 일반적으로 부드럽고 대비가 낮은 전환과 어느 정도의 노이즈 또는 유사한 불규칙한 구조가 지배적인 사진 이미지 데이터를 위해 특별히 설계된 손실 인코딩 방식을 사용하기 때문이다. 이러한 이미지에 고품질 JPEG 대신 PNG를 사용하면 파일 크기가 크게 증가하고 품질 향상은 무시할 수준이 된다. 이에 비해, 텍스트, 선화 또는 그래픽(선명한 전환과 넓은 단색 영역이 있는 이미지)을 포함하는 이미지를 저장할 때는 PNG 형식이 JPEG보다 이미지 데이터를 더 많이 압축할 수 있다. 또한 PNG는 무손실인 반면 JPEG는 고대비 영역 주변에 시각적 아티팩트를 생성한다. (이러한 아티팩트는 JPG 압축에 사용되는 설정에 따라 달라지며, 낮은 품질[높은 압축] 설정이 사용될 때 상당히 눈에 띌 수 있다.) 이미지가 선명한 전환과 사진 부분을 모두 포함하는 경우, 두 가지 효과 중에서 선택해야 한다. JPEG는 투명도를 지원하지 않는다.

JPEG의 손실 압축은 또한 세대 손실을 겪는다. 이미지를 저장하기 위해 반복적으로 디코딩하고 재인코딩하면 매번 정보 손실이 발생하여 이미지가 저하된다. PNG는 무손실이므로 편집할 이미지를 저장하는 데 적합하다. PNG는 사진 이미지를 압축할 때 합리적으로 효율적이지만, 사진 이미지를 위해 특별히 설계된 무손실 압축 형식, 예를 들어 무손실 WebP 및 Adobe DNG (디지털 네거티브)도 있다. 그러나 이러한 형식은 널리 지원되지 않거나 독점적이다. 이미지를 무손실로 저장하고 배포용으로만 JPEG 형식으로 변환할 수 있으므로 세대 손실이 발생하지 않는다.

PNG 사양은 디지털 카메라와 같은 소스에서 Exif 이미지 데이터를 포함하는 표준을 명시적으로 포함하지 않지만, PNG에 EXIF 데이터를 포함하는 선호되는 방법은 비필수 보조 청크 레이블인 eXIf를 사용하는 것이다.

초기 웹 브라우저는 PNG 이미지를 지원하지 않았다. JPEG와 GIF가 주요 이미지 형식이었다. JPEG는 GIF의 제한된 색상 깊이 때문에 웹 페이지용 그라데이션이 포함된 이미지를 내보낼 때 일반적으로 사용되었다. 그러나 JPEG 압축은 그라데이션을 약간 흐리게 만든다. PNG 형식은 주어진 비트 깊이에 대해 그라데이션을 가능한 한 정확하게 재현하면서 파일 크기를 작게 유지한다. 웹 브라우저의 형식 지원이 향상되면서 PNG는 작은 그라데이션 이미지에 최적의 선택이 되었다. 최신 브라우저에서는 CSS를 사용하여 그라데이션을 생성할 수 있으므로 그라데이션을 표시하기 위해 이미지가 전혀 필요하지 않다.

JPEG-LS

JPEG-LS는 Joint Photographic Experts Group의 이미지 형식이지만, 위에서 논의된 다른 손실 JPEG 형식보다 훨씬 덜 알려져 있고 지원된다. 이는 PNG와 직접 비교할 수 있으며, 표준 테스트 이미지 세트를 가지고 있다. JPEG-LS는 워털루 레퍼토리 컬러세트(JPEG-LS 적합성 테스트 세트와 관련 없는 표준 테스트 이미지 세트)에서 일반적으로 PNG보다 10-15% 더 나은 성능을 보이지만, 일부 이미지에서는 PNG가 50-75% 더 우수한 성능을 보인다. 따라서 이 두 형식이 모두 옵션이고 파일 크기가 중요한 기준이라면 이미지에 따라 둘 다 고려해야 한다.

JPEG XL

JPEG XL은 PNG와 같은 비손실 형식을 대체하기 위해 개발된 또 다른, 훨씬 개선된, 비손실 또는 손실 형식으로, 안타깝게도 지원이 훨씬 적다. JPEG XL은 JPEG보다 50% 이상 작으며, 비손실일 때도 이렇게 작을 수 있으므로 PNG보다도 더 작다. 또한 높은 동적 범위, 넓은 색 영역, 그리고 큰 색 깊이를 지원한다. JPEG XL은 또한 디코딩 효율성이 매우 뛰어나며, 대체하려는 형식에서 부드러운 전환을 제공하고, JPEG에서 손실 없이 변환할 수 있다. 또한 충실도를 손상시키지 않고 압축하는 데 탁월하다.

TIFF

태그 이미지 파일 형식(TIFF)은 매우 광범위한 옵션을 포함하는 형식이다. 이는 TIFF를 전문 이미지 편집 응용 프로그램 간의 일반적인 교환 형식으로 유용하게 만들지만, 응용 프로그램에 대한 지원을 추가하는 것을 훨씬 더 큰 작업으로 만들고 따라서 이미지 조작과 관련 없는 응용 프로그램(예: 웹 브라우저)에서는 거의 지원되지 않는다. 높은 확장성 수준은 또한 대부분의 응용 프로그램이 가능한 기능의 일부만 제공하여 사용자 혼란 및 호환성 문제를 잠재적으로 야기한다는 것을 의미한다.

TIFF와 함께 사용되는 가장 일반적인 범용 비손실 압축 알고리즘은 Lempel-Ziv-Welch(LZW)이다. 이 압축 기술은 GIF에서도 사용되었으며 2003년까지 특허에 의해 보호되었다. TIFF는 PNG가 사용하는 압축 알고리즘(즉, 압축 태그 0008₁₆ '어도비 스타일')도 중간 정도의 사용률과 응용 프로그램 지원을 제공한다. TIFF는 또한 CCITT 그룹 IV와 같은 특수 목적의 비손실 압축 알고리즘을 제공하며, 이는 PNG의 압축 알고리즘보다 바이너리 이미지(예: 팩스 또는 흑백 텍스트)를 더 잘 압축할 수 있다.

PNG는 미리 곱셈이 없는 알파만 지원하는 반면 TIFF는 "연관"(미리 곱셈) 알파도 지원한다.

WebP

WebP는 구글이 개발한 형식으로, PNG, JPEG, GIF를 대체하기 위해 고안되었다. WebP 파일은 손실 및 비손실 압축을 모두 허용하는 반면, PNG는 비손실 압축만 허용한다. WebP는 또한 애니메이션을 지원하며, 이는 이전에 GIF 파일만 가능했던 기능이었다.

그러나 WebP가 PNG보다 주요 개선점은 파일 크기가 크게 줄어들어 웹사이트에 삽입될 때 로딩 시간이 빨라진다는 것이다. 구글은 비손실 WebP 이미지가 PNG 파일보다 26% 더 작다고 주장한다.

WebP는 PNG와 달리 다양한 이미지 편집 프로그램 및 소셜 미디어 웹사이트와의 호환성 문제로 비판을 받아왔다. 또한 WebP는 모든 웹 브라우저에서 지원되지 않아 웹 이미지 호스팅 업체에서 사용자에게 표시할 대체 이미지를 생성해야 할 수 있으며, 이는 WebP의 잠재적인 저장 공간 절약을 무효화한다.

AVIF

AVIF는 오픈 미디어 연합이 개발한 이미지 형식이다. AVIF는 PNG, GIF, WebP를 포함한 다른 이미지 코덱의 단점을 보완하기 위해 재단에서 설계되었다.

AVIF는 일반적으로 WebP와 PNG보다 크기가 작다. AVIF는 PNG가 지원하지 않는 애니메이션을 지원한다.

그러나 WebP와 마찬가지로 AVIF는 PNG보다 적은 응용 프로그램에서 지원된다.

소프트웨어 지원

PNG 형식의 공식 참조 구현은 프로그래밍 라이브러리 libpng이다. 이는 관대한 자유 소프트웨어 라이선스 조건에 따라 자유 소프트웨어로 게시된다. 따라서 일반적으로 자유 운영 체제에서 중요한 시스템 라이브러리로 발견된다.

비트맵 그래픽 편집기의 PNG 지원

 이 부분의 본문은 래스터 그래픽스 편집기 비교입니다.

PNG 형식은 어도비 포토샵, 코렐의 Photo-Paint 및 Paint Shop Pro, 김프, 그래픽컨버터, 헬리콘 필터, 이미지매직, 잉크스케이프, 이르판뷰, Pixel 이미지 편집기, Paint.NET 및 Xara Photo & Graphic Designer 등 많은 그래픽 프로그램(온라인 그래픽 디자인 플랫폼 Canva 포함)에서 널리 지원된다. 인기 있는 운영체제에 번들로 제공되는 일부 PNG 지원 프로그램으로는 마이크로소프트의 Paint와 애플의 Photos/아이포토 및 Preview가 있으며, 김프도 인기 있는 리눅스 배포판에 자주 번들로 제공된다.

어도비 파이어웍스(이전 매크로미디어)는 PNG를 기본 파일 형식으로 사용하여 다른 이미지 편집기 및 미리보기 유틸리티가 플랫 이미지(flattened image)를 볼 수 있게 한다. 그러나 파이어웍스는 기본적으로 레이어, 애니메이션, 벡터 데이터, 텍스트 및 효과에 대한 메타데이터도 저장한다. 이러한 파일은 직접 배포되어서는 안 된다. 파이어웍스는 웹 페이지 등에서 사용할 수 있도록 추가 메타데이터가 없는 최적화된 PNG로 이미지를 내보낼 수 있다.

웹 브라우저의 PNG 지원

 이 부분의 본문은 웹 브라우저 이미지 형식 지원입니다.

PNG 지원은 1997년에 처음 등장했으며, 인터넷 익스플로러 4.0b1(NT용 32비트 전용) 및 넷스케이프 4.04에서 지원되었다.

자유 소프트웨어 재단과 월드 와이드 웹 컨소시엄 (W3C)의 요청에도 불구하고, gif2png와 같은 도구와 Burn All GIFs와 같은 캠페인에도 불구하고, 인터넷 익스플로러의 늦고 버그가 있는 지원, 특히 투명도와 관련하여 웹사이트에서의 PNG 채택은 상당히 느렸다. PNG는 2018년부터 웹에서 가장 많이 사용되는 이미지 파일 형식이다.

PNG 호환 브라우저에는 Apple Safari, 구글 크롬, 모질라 파이어폭스, Opera, 카미노, 인터넷 익스플로러, 마이크로소프트 엣지, 그리고 다른 많은 브라우저가 포함된다. 전체 비교는 웹 브라우저 비교 (이미지 형식 지원)를 참조하라.

특히 9.0 (2011년 출시) 이전 버전의 인터넷 익스플로러 (윈도우)는 PNG 이미지를 올바르게 렌더링하지 못하게 하는 수많은 문제를 가지고 있었다.

• 4.0은 큰 PNG 청크에서 충돌한다.
• 4.0은 .png 파일을 볼 수 있는 기능을 포함하지 않지만, 레지스트리 수정이 있다.
• 5.0과 5.01은 깨진 OBJECT 지원을 가지고 있다.
• 5.01은 Windows 98에서 팔레트 이미지를 검정색(또는 진한 회색) 배경으로 인쇄하며, 때로는 색상이 급격히 변경된다.
• 6.0은 4097 또는 4098바이트 크기의 PNG 이미지를 표시하지 못한다.
• 6.0은 하나 이상의 길이가 0인 IDAT 청크를 포함하는 PNG 파일을 열 수 없다. 이 문제는 보안 업데이트 947864 (MS08-024)에서 처음 해결되었다. 자세한 내용은 Microsoft 기술 자료의 이 문서: 947864 MS08-024: Internet Explorer용 누적 보안 업데이트를 참조하라.
• 6.0은 때때로 PNG를 표시하는 기능을 완전히 잃지만, 다양한 해결 방법이 있다.
• 6.0 이하는 알파 채널 투명도 지원이 깨져 있다(기본 배경색 대신 표시됨).
• 7.0 이하는 부분적으로 투명한 부분을 검정색으로 채우지 않고 8비트 알파 투명도와 요소 불투명도(CSS – 필터: Alpha (opacity=xx))를 결합할 수 없다.
• 8.0 이하는 일관성 없는/깨진 감마 지원을 가지고 있다.
• 8.0 이하는 색 보정 지원이 없다.

PNG 아이콘의 운영체제 지원

PNG 아이콘은 1999년부터 리눅스 대부분의 배포판에서 그놈과 같은 데스크톱 환경에서 지원되었다. 2006년에는 마이크로소프트 윈도우에서 PNG 아이콘 지원이 윈도우 비스타에 도입되었다. PNG 아이콘은 아미가OS 4, AROS, MacOS, IOS, 모르프OS에서도 지원된다. 또한 안드로이드는 PNG를 광범위하게 사용한다.

파일 크기 및 최적화 소프트웨어

PNG 파일 크기는 인코딩 및 압축 방식에 따라 크게 달라질 수 있다. 이에 대한 논의와 몇 가지 팁은 PNG: The Definitive Guide에 나와 있다.

GIF와 비교

GIF 파일과 비교할 때, 동일한 정보(256색, 보조 청크/메타데이터 없음)를 가진 PNG 파일은 효율적인 압축기로 압축하면 일반적으로 GIF 이미지보다 크기가 작다. 파일과 압축기에 따라 PNG는 약간 작거나(10%), 상당히 작거나(50%), 약간 클 수도(5%) 있지만, 큰 이미지에서는 거의 상당히 크지 않다. 이는 GIF의 LZW에 비해 PNG의 DEFLATE 성능과, PNG의 예측 필터의 추가 사전 압축 계층이 2차원 이미지 구조를 고려하여 파일을 추가로 압축하기 때문이다. 필터링된 데이터는 픽셀 간의 차이를 인코딩하므로, 가능한 모든 이미지 값에 분산되기보다 0 주변에 모이는 경향이 있어 DEFLATE에 의해 더 쉽게 압축된다. 그러나 어도비 포토샵, 코렐드로, MS Paint의 일부 버전은 PNG 압축이 좋지 않아 GIF가 더 효율적이라는 인상을 줄 수 있다.

파일 크기 요인

PNG 파일 크기는 여러 요인에 따라 달라진다.

색 깊이

색 깊이는 픽셀당 1비트에서 64비트까지 다양하다.

보조 청크

PNG는 메타데이터를 지원한다. 이는 편집에 유용할 수 있지만, 웹사이트에서와 같이 보기에 불필요할 수 있다.

인터레이싱

아담7 알고리즘의 각 패스는 개별적으로 필터링되므로 파일 크기가 증가할 수 있다.

필터

사전 압축 단계로, 각 라인은 예측 필터에 의해 필터링되며, 이는 라인마다 달라질 수 있다. 최종 DEFLATE 단계는 이미지 전체의 필터링된 데이터에 대해 작동하므로, 이를 행별로 최적화할 수 없다. 따라서 각 행에 대한 필터 선택은 매우 가변적일 수 있지만, 휴리스틱이 존재한다.

압축

추가 계산을 통해 DEFLATE 압축기는 더 작은 파일을 생성할 수 있다.

따라서 높은 색 깊이, 최대 메타데이터(색 공간 정보 및 디스플레이에 영향을 미치지 않는 정보 포함), 인터레이싱, 압축 속도(모두 큰 파일을 생성함)와 낮은 색 깊이, 적거나 없는 보조 청크, 인터레이싱 없음, 튜닝되었지만 계산 집약적인 필터링 및 압축 간에는 파일 크기 트레이드오프가 있다. 다른 목적을 위해 다른 트레이드오프가 선택된다. 최대 파일은 아카이빙 및 편집에 가장 적합할 수 있고, 스트립다운된 파일은 웹사이트 사용에 가장 적합할 수 있으며, 마찬가지로 빠르지만 압축률이 낮은 압축은 파일을 반복적으로 편집하고 저장할 때 선호되는 반면, 느리지만 압축률이 높은 압축은 파일이 안정적일 때(아카이빙 또는 게시할 때) 선호된다. 인터레이싱은 트레이드오프이다. 대용량 파일의 초기 렌더링 속도를 극적으로 높이지만(대기 시간 개선), 특히 작은 파일의 경우 파일 크기를 증가시킬 수 있다(처리량 감소).

손실 PNG 압축

PNG는 무손실 형식임에도 불구하고, PNG 인코더는 PNG 압축을 개선하기 위해 손실 방식으로 이미지 데이터를 전처리할 수 있다. 예를 들어, 트루컬러 PNG를 256색으로 양자화하면 인덱스 색상 유형을 사용하여 파일 크기를 줄일 수 있다.

이미지 편집 소프트웨어

일부 프로그램은 PNG 파일을 저장할 때 다른 프로그램보다 효율적이다. 이는 프로그램에서 사용되는 PNG 압축 구현과 관련이 있다.

많은 그래픽 프로그램(예: 애플의 Preview 소프트웨어)은 웹 보기에 일반적으로 불필요한 많은 메타데이터 및 색 보정 데이터를 포함하여 PNG를 저장한다. 어도비 파이어웍스에서 최적화되지 않은 PNG 파일도 이미지 편집 가능한 옵션을 포함하므로 악명 높다. 또한 코렐드로(최소 11버전)는 때때로 인터넷 익스플로러(6-8버전)에서 열리지 않는 PNG를 생성한다.

어도비 포토샵의 PNG 파일 성능은 웹용 저장 기능(명시적인 PNG/8 사용도 허용)을 사용할 때 CS Suite에서 향상되었다.

어도비 파이어웍스는 기본적으로 다른 많은 프로그램보다 큰 PNG 파일을 저장한다. 이는 저장 형식의 메커니즘에서 비롯된다. 파이어웍스의 저장 기능으로 생성된 이미지에는 완전한 레이어 및 벡터 정보를 포함하는 크고 비공개적인 청크가 포함된다. 이는 추가 무손실 편집을 가능하게 한다. 내보내기 옵션으로 저장될 때, 파이어웍스의 PNG는 다른 이미지 편집기에서 생성된 PNG와 경쟁할 수 있지만, 플랫 비트맵 외에는 편집할 수 없다. 파이어웍스는 크기가 최적화된 벡터 편집 가능한 PNG를 저장할 수 없다.

PNG 압축 성능이 좋지 않은 다른 주목할 만한 예는 다음과 같다.

• Microsoft's Paint for Windows XP
• 마이크로소프트 픽쳐 잇! 포토 프리미엄 9

압축 불량은 PNG 파일 크기를 증가시키지만, 이미지 품질이나 다른 프로그램과의 파일 호환성에는 영향을 미치지 않는다.

트루컬러 이미지의 색 깊이를 8비트 팔레트로 줄이면(GIF에서처럼), 결과 이미지 데이터는 일반적으로 훨씬 더 작아진다. 따라서 트루컬러 PNG는 일반적으로 색상이 줄어든 GIF보다 크지만, PNG는 색상이 줄어든 버전을 비슷한 크기의 팔레트 파일로 저장할 수 있다. 반대로, 일부 도구는 이미지를 PNG로 저장할 때, 원본 데이터가 8비트 색상만 사용하더라도 자동으로 트루컬러로 저장하여 파일을 불필요하게 부풀린다. 이 두 가지 요인 모두 PNG 파일이 동등한 GIF 파일보다 크다는 오해를 불러일으킬 수 있다.

최적화 도구

PNG 파일을 최적화하는 데 사용할 수 있는 다양한 도구가 있다. 이들은 다음을 통해 이를 수행한다.

• (선택적으로) 보조 청크 제거,
• 색 깊이 감소, 다음 중 하나:
  • 이미지가 256색 이하인 경우 (RGB 대신) 팔레트 사용,
  • 이미지가 2, 4 또는 16색인 경우 더 작은 팔레트 사용, 또는
  • (선택적으로) 원본 이미지의 일부 데이터를 손실적으로 버림,
• 라인별 필터 선택 최적화, 그리고
• DEFLATE 압축 최적화.

도구 목록

• Pngcrush는 인기 있는 PNG 최적화 도구 중 가장 오래된 것이다. 필터 선택 및 압축 인수에 대해 여러 번의 시도를 허용하고, 최종적으로 가장 작은 것을 선택한다. 이 작업 모델은 거의 모든 png 최적화 도구에서 사용된다.
• advpng와 유사한 advdef 유틸리티는 AdvanceCOMP 패키지에서 PNG IDAT를 재압축한다. 선택된 압축 수준에 따라 다른 DEFLATE 구현이 적용되어 속도와 파일 크기 간의 균형을 맞춘다. zlib는 수준 1, libdeflate는 수준 2, 7-zip의 LZMA DEFLATE는 수준 3, Zopfli는 수준 4이다.
• pngout은 저자 자신의 디플레이터(저자의 zip 유틸리티인 kzip과 동일)로 만들어졌으며, 색상 감소/필터링의 모든 기능을 유지한다. 그러나 pngout은 한 번의 실행에서 여러 번의 필터 시도를 허용하지 않는다. 상용 GUI 버전인 pngoutwin을 사용하거나, 래퍼와 함께 사용하여 시도를 자동화하거나, 자체 디플레이터를 사용하여 필터를 라인별로 유지하면서 재압축하는 것이 좋다.
• Zopflipng도 자체 디플레이터인 zopfli로 만들어졌다. 이 도구는 pngcrush가 가진 모든 최적화 기능(자동 시도 포함)을 제공하며, 매우 좋지만 느린 디플레이터를 제공한다.

이들의 기능에 대한 간단한 비교는 아래에 나열되어 있다.

최적화 도구	청크 제거	색상 감소	필터링	필터 재사용	한 번의 실행에서 여러 필터 시도	디플레이터
advpng	예	아니요	0	아니요	해당 없음	(다중)
advdef	아니요	아니요	이전 필터 세트 재사용	항상	해당 없음	(다중)
pngcrush	예	예	0–4 또는 적응형	아니요	예	zlib
pngout	예	예	0–4 또는 적응형	예	아니요	kzip
zopflipng	예	예	2가지 다른 알고리즘을 사용한 0–4 또는 적응형, 또는 무차별 방식	예	예	zopfli

zopflipng가 나오기 전에는 최적의 압축을 위해 두 가지 도구를 순차적으로 사용하는 것이 효과적인 png 최적화 방법이었다. 하나는 필터를 최적화하고(보조 청크 제거), 다른 하나는 DEFLATE를 최적화하는 방식이었다. pngout은 둘 다 제공하지만, 한 번의 실행에서 한 가지 필터 유형만 지정할 수 있으므로, pngcrush와 함께 래퍼 도구 또는 advdef처럼 재디플레이터 역할을 하는 방식으로 사용할 수 있다.

보조 청크 제거

보조 청크를 제거하기 위해 대부분의 PNG 최적화 도구는 PNG 파일에서 모든 색 보정 데이터(감마, 화이트 밸런스, ICC 색상 프로파일, 표준 RGB 색상 프로파일)를 제거하는 기능을 가지고 있다. 이는 종종 훨씬 더 작은 파일 크기를 초래한다. 예를 들어, 다음 명령줄 옵션은 pngcrush로 이를 달성한다.

pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB InputFile.png OutputFile.png

필터 최적화

pngcrush, pngout, zopflipng는 모두 필터 유형 0-4 중 하나를 전역적으로 적용하거나("유사 필터" 번호 5 사용), 각 라인에 대해 적응형 알고리즘을 사용하여 필터 유형 0-4 중 하나를 선택하는 옵션을 제공한다. zopflipng는 무차별 대입 검색을 포함하여 3가지 다른 적응형 방법을 제공하며, 이는 필터링을 최적화하려고 시도한다.

`pngout`과 `zopflipng`는 입력 이미지에 존재하는 라인별 필터 세트를 보존/재사용하는 옵션을 제공한다.

`pngcrush`와 `zopflipng`는 한 번의 실행에서 다양한 필터 전략을 시도하고 최적의 것을 선택하는 옵션을 제공한다. `pngout`의 프리웨어 명령줄 버전은 이를 제공하지 않지만, 상용 버전인 `pngoutwin`은 제공한다.

DEFLATE 최적화

Zopfli와 LZMA SDK는 성능을 희생하는 대신 Zlib 참조 구현보다 더 높은 압축률을 생성할 수 있는 DEFLATE 구현을 제공한다. AdvanceCOMP의 `advpng` 및 `advdef`는 이러한 라이브러리 중 하나를 사용하여 PNG 파일을 재압축할 수 있다. 또한 PNGOUT은 자체 독점 DEFLATE 구현을 포함한다.

`advpng`는 필터를 적용하는 옵션이 없으며 항상 필터 0을 전역적으로 사용한다(이미지 데이터를 필터링하지 않은 상태로 둠). 따라서 이미지에 필터링이 크게 도움이 되는 경우에는 사용해서는 안 된다. 이와 대조적으로, 같은 패키지의 `advdef`는 PNG 구조를 다루지 않고 재디플레이터 역할만 하며, 기존 필터 설정을 유지한다.

아이콘 최적화

Windows Vista 및 이후 버전을 위한 아이콘이 PNG 하위 이미지를 포함할 수 있으므로, 이러한 아이콘에도 최적화를 적용할 수 있다. 적어도 하나의 아이콘 편집기인 Pixelformer는 ICO 파일을 저장할 때 특별한 최적화 패스를 수행하여 크기를 줄일 수 있다.

macOS용 아이콘도 PNG 하위 이미지를 포함할 수 있지만, 이러한 도구는 현재 없다.

같이 보기

• APNG

각주

내용주

외부 링크

• PNG 홈페이지
• libpng 홈페이지
• PNG를 지원하는 브라우저 - 여러 웹 브라우저들의 PNG 지원 현황. 윈도 IE 4.0b1, 넷스케이프 4.04부터 PNG를 지원한다.