# 새로운 PNG 스펙 릴리즈 > Clean Markdown view of GeekNews topic #21649. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=21649](https://news.hada.io/topic?id=21649) - GeekNews Markdown: [https://news.hada.io/topic/21649.md](https://news.hada.io/topic/21649.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-06-26T08:34:36+09:00 - Updated: 2025-06-26T08:34:36+09:00 - Original source: [programmax.net](https://www.programmax.net/articles/png-is-back/) - Points: 9 - Comments: 2 ## Summary **HDR 지원, APNG(애니메이션), Exif 메타데이터** 등 최신 기술을 통합한 새로운 PNG 파일 포맷 스펙이 약 20년 만에 개정되었습니다. ## Topic Body - **PNG 파일 포맷**이 20년 만에 새롭게 개정되며 과거의 위상을 되찾음 - 이번 사양에는 **HDR 지원, APNG(애니메이션), Exif 데이터** 공식 지원 등 최신 기술이 다수 반영됨 - **Adobe, Apple, Google 등 주요 IT 기업과 브로드캐스트 업체**가 공동으로 참여하여 개발 진행 - 최신 사양은 **Chrome, Safari, Photoshop** 등 여러 프로그램에서 이미 지원 중임 - 앞으로 더 나은 **압축 기술과 병렬 인코딩/디코딩** 추가 등 추가 업데이트 계획이 있음 --- ### 서론: PNG의 부활 및 중요성 - 최근 **PNG 파일 포맷**이 약 20년간의 정체를 딛고 새 사양으로 업데이트됨 - 미국 의회도서관, 캐나다 도서관 및 아카이브, 호주 국립 아카이브 등 주요 기관에서 **공식 권장 포맷**으로 PNG를 채택하고 있음 - 새로운 사양을 통해 PNG가 시장에서 **경쟁력**을 되찾고 혁신성을 보여줌 ### 새로운 기능과 특징 #### 적절한 HDR 지원 및 미래 호환성 - 새로운 PNG는 **HDR(High Dynamic Range)** 지원을 제공함 - Rec. 2020과 Rec. 709 색 영역 비교 이미지에서, 더 넓은 영역(바깥 삼각형)이 HDR 이미지가 표현하는 컬러임을 보여줌 - 이 HDR 정보는 4바이트(및 기존 PNG 청크 오버헤드)만을 추가로 필요로 함 - Chris Lilley 등 초기 저자 및 주요 기술 전문가가 참여하여 신기술을 명확히 설명함 #### APNG(애니메이션 PNG)의 공식 인식 - Mozilla에서 처음 제안되고 Firefox가 지원한 **애니메이션 PNG(APNG)** 도 공식 사양에 반영됨 - 이전에는 일부 소프트웨어만 지원했으나, 현재 다양한 프로그램에서 널리 채택되고 있음 #### Exif 데이터 공식 지원 - Exif를 통해 **저작권, 카메라 정보, GPS 정보** 등 메타데이터 저장 가능 - 이미지 제작과 보관, 저작권 관리 등에서 높은 효용성이 보장됨 #### 전반적 개선 및 오류 수정 - 기존 사양의 **오류(Errata) 수정과 명확화**도 함께 이루어짐 ### 배경 및 개발 과정 - 마지막 PNG 사양은 약 20년 전 공개됨(아이폰 출시 3년 반 전) - W3C Timed Text Working Group(자막 기술 표준화)이 PNG에 HDR 지원 필요성을 제기하면서 개발 재개 - 제안이 이루어지자 **Adobe, Apple, BBC, Google, MovieLabs, W3C 등 주요 기술 기업**이 공동 참여 - 강력한 컨소시엄이 결성되어 차세대 이미지 포맷으로 거듭남 - 현재 **두 개의 후속 업데이트** 역시 이미 준비 중임 ### 이미 널리 적용된 현황 - **Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer** 등 다양한 프로그램에서 최신 PNG 사양 지원 - 브로드캐스트 업체 및 관련 하드웨어, 툴링에서도 지원 확대 - 뉴 스크롤, 스포츠 점수 배너 등 방송 이미지는 새로운 HDR PNG 활용 사례임 ### 앞으로의 계획 - 다음 판에서는 **HDR & SDR 호환성**을 더욱 개선할 계획 - 추가적으로 **더 향상된 압축 방식, 병렬 인코딩/디코딩**도 추진되고 있음 - 네 번째 에디션은 비교적 짧은 업데이트가 될 예정이며, 이후 압축 기술 연구를 바탕으로 다섯 번째 에디션 개발 예정 ## Comments ### Comment 40640 - Author: carnoxen - Created: 2025-06-26T11:40:01+09:00 - Points: 1 Apng 처음에 단체에서 이미지에 대한 표준 아니라고 거부하다가 이제서야 인정했군요 ### Comment 40622 - Author: neo - Created: 2025-06-26T08:34:37+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=44365754) - 저자임을 밝힘과 동시에 질문이 있으면 언제든 환영임을 알림 - 이번 PNG는 완전히 새로운 포맷이 아니라 기존 포맷의 업데이트 버전임을 강조 - 매우 높은 하위 호환성을 제공함을 밝힘 - 오래된 프로그램들도 새로운 PNG 파일을 최대한 잘 읽을 수 있고, 예를 들어 빨간 사과 사진이란 점은 그대로 인식 가능함을 설명 - PNG 내부 작동 방식에 혼동이 있을 수 있어 핵심을 정리함 - PNG 파일은 다양한 데이터 청크(chunks)로 구성됨 - 각 청크는 이름을 갖고 있어 프로그램이 모르거나 필요 없는 청크는 그냥 건너뛸 수 있음 - 이미지 스트림은 단 하나만 존재함을 명시 - 새로운 PNG 스펙의 기능을 활용한 예시 파일이 있는지, 특히 애니메이션이나 HDR 이미지를 직접 다운로드해서 프로그램 호환성을 테스트해 볼 수 있는 데모 페이지가 있으면 좋겠다는 바람을 이야기함 - 나는 메타포맷과 범용 툴링을 지지함을 밝힘 - Office Open XML이나 ePub처럼 단지 zip과 XML 라이브러리만 있으면 파싱이 되는 구조를 예로 듦 - PNG도 거의 Interchange File Format(이하 IFF)과 유사한 구조를 가지고 있지만, 기존에는 미묘하게 규격이 달라 완전히 범용 IFF 파서로 PNG와 IFF 계열 파일을 동시에 파싱하는 게 불가능했음을 경험에서 설명 - IFF는 쉽게 구현할 수 있고 데이터 압축에 강점이 있지만, 지금껏 구식 게임 데이터, AIFF·RIFF 오디오 등 제한된 용도로만 쓰여왔고, 범용 툴링이 만들어지지 않은 이유 가운데 하나로 PNG와 IFF의 호환성 아쉬움을 지적 - PNGv3는 PNG 파일이 공식적으로 IFF 파일이 된다면, PNG의 대중성을 발판으로 범용 IFF 생태계(예: libiff 같은)가 확장되고 새로운 포맷 정의에도 쓸 수 있을 거란 바람을 밝힘 - 실제 PNG/IFF 파서를 직접 만들어 봤고, 단순히 PNG를 수정해서 IFF 호환성을 갖추기는 어렵고, 하위 호환성(특히 하드웨어 파서)도 유지해야 함을 언급하면서 - 나는 PNG가 사용하고 있는 변형된 IFF 구조를, 새로운 메타포맷(IFF 2.0) 표준으로 별도 문서화할 것을 제안 - IFF 2.0은 PNGv2가 호환되는 프로필, AIFF/RIFF 등 IFFv1도 커버하는 프로필을 공식화해 범용 IFF 툴링을 추진하길 바람 - 나아가 새로운 그린필드 프로필(최신 환경에 맞춘 신포맷)에선, 예를 들어 CRC 대신 현대적 해시로 무결성 체크, 청크 이름 문자세트 확장, 각 청크 속성정보를 효율적으로 담는 구조를 도입할 수도 있음 - 이런 구조들은 IFFv1과 PNGv2를 모두 변환(transcode) 가능하도록 하고, 실제 HTML5에서 HTML4와 XHTML을 조합·호환하는 식의 전략적 프로필 선언이 바람직하다고 봄 - 결론적으로, 세부 사항보다 디자인 목표(기존과 새 포맷 간 이질성 최소화 및 도구 생태계 확장)에 중점을 뒀음을 강조함 - 내 웹 기반 드로잉 툴에서는 문서의 JSON 표현을 PNG의 주석 필드에 저장하는 트릭을 씀 - 이렇게 하면 저장한 파일이 바로 이미지로도 쓸 수 있고, 다시 에디터에 불러올 수도 있음 - 다운로드 폴더에 알아보기 힘든 JSON 파일이 쌓이지 않는 장점이 있음 - 재미있긴 한데, 사용자가 왜 파일이 .png로 저장되는지, 또는 Paint 등에서 열었다 저장하면 왜 데이터가 사라지는지 설명하기가 애매함 - Krita도 붓 설정을 이렇게 저장하는데, 데이터가 너무 많을 때 예상치 못한 문제를 일으킬 수 있음 - 관련 이슈: [Krita-Brushes 이슈 #4](https://github.com/Draneria/Metallics-by-Draneria_Krita-Brushes/issues/4), [Memileo Impasto Brushes 대화](https://krita-artists.org/t/memileo-impasto-brushes/92952/116) - Macromedia Fireworks는 20년 전부터 PNG를 기본 저장 포맷으로 사용했었음 - 물론 그때는 JSON을 넣었던 건 아님 - 많은 AI 이미지 생성 프론트엔드도 비슷하게 사용함 - 이미지 주석(comment)에 프롬프트나 세팅을 저장해서, 이미지만 열어도 설정을 가져오거나 ComfyUI처럼 전체 워크플로우를 불러오는 식임 - 사실 이미지 다루는 툴들은 이런 방식이 꽤 보편적으로 쓰인다고 생각함 - Macromedia Fireworks는 PNG에 Fireworks 파일을 저장했고, - Adobe의 Illustrator(AI) 파일은 실제로는 PDF이고, - Photoshop의 PSD 파일도 TIFF 내부에 저장 가능함 - 이 때문에 Photoshop에서는 여러 레이어가 보이지만, 다른 소프트웨어에서는 한 레이어만 나오는 현상이 있음 - 이 스펙은 이미 널리 구현된 것에 대한 명시화에 가까움 - 차세대 PNG라 해도 새로운 디코더가 필요하다면 PNG2라고 했어도 됐을 것 같음 - JPEG-XL은 이미 대부분이 원하는 무손실 코덱의 조건을 충족함 - 문제는 인코딩/디코딩 속도와 자원임 - 현재 무손실 이미지 코덱의 최고는 HALIC임 - 자세한 논의: [HN HALIC 토론](https://news.ycombinator.com/item?id=38990568) - [HALIC 토론 스레드](https://encode.su/threads/4025-HALIC-(High-Availability-Lossless-Image-Compression))를 보면 실제로는 LEA 0.5가 더 우수하다고 함 - [이미지 무손실 압축 벤치마크](https://github.com/WangXuan95/Image-Compression-Benchmark)에서 HALIC은 최상위권이 아님 - 솔직히 말해 JPEG XL을 한동안 "초대형 이미지" 용도로만 쓰는 줄 알고 무시했었음 - 나는 컴퓨터 비전 이미지 어노테이션 툴([XLabel](https://github.com/VoxleOne/XLabel))에서 png를 사용함 - 클래스 레이블을 이미지 메타데이터에 직접 저장해 텍스트 파일을 따로 두지 않아도 됨 - 앞으로 이런 용도에 맞는 확장 포맷을 만들고 싶음 - WebP의 무손실 압축은 업계 최고 수준이면서도 널리 쓰이지 않음 - 무손실 압축에서 최고 성능을 내는 것 자체가 중요한 게 아니라, 오히려 생태계 채택이 더 큰 과제임을 시사함 - 인코딩/디코딩 속도 문제는 시간이 지나면 개선될 수 있음 - 이는 과거 jpg 생태계에서 실제로 일어난 변화임 - 공식적으로 Exif 데이터 지원이 반영된 점이 최고의 소식임 - 이전에도 헤더에 커스텀 데이터를 쓸 수 있었지만, Exif 지원은 매우 환영임 - 참고로 Exif에 자이로스코프(회전)나 가속도(중력) 관련 필드가 있는지 궁금함 - 구글 카메라 앱으로 찍은 사진에 이런 정보가 빠져있어서, 이후 자동 보정이나 파노라마 합성 때 아쉬운 경우가 많았음 - 가속도 필드(Exif.Photo.Acceleration)와 고도를 위한 필드(Exif.Photo.CameraElevationAngle)는 있지만, 3축 전부를 지원하지 않음 - 환경 센서(주변 조건)는 있지만, 스펙 작성자들이 지정한 특정 항목만 반영됨 - Exif.Photo.MakerNote는 제작사에서 원하는 정보를 저장하는 자유로운 영역으로, 9축 데이터를 기록해도 충분할 정도로 크기 제한이 큼 - Exif는 이미지 렌더링에서 회전 처리 방식에 따라 혼선을 불러올 수 있음 - 구버전과 신버전 디코더가 Exif 회전 유무에 따라 서로 다르게 이미지를 보여줄 수 있음 - Exif 회전에 대한 구체적인 디코더 권장사항이 없다 보니, 이중 회전(예: 데스크탑 환경과 라이브러리가 각자 처리) 같은 버그도 빈번히 발생함 - "디코더가 Exif 데이터의 신뢰 여부를 별개로 알지 못하면, Exif 데이터는 기록적 가치로만 간주해야 한다"는 애매한 권장문구만 있을 뿐 - 완전한 하위 호환을 위해선 "절대로 회전하지 마라" 같은 명확한 지침이 필요하다고 생각함 - 카메라의 가속도계나 관성항법장치 데이터를 기록하는 표준 필드는 없음 - Exif 필드 목록: [exiv2 공식 태그 설명](https://exiv2.org/tags.html) - 실제로 많은 웹사이트가 Exif 데이터 대부분을 업로드 시 삭제함 - 일부 필드는 개인정보나 위치추적에 악용될 소지가 있기 때문임 - 개인적으로는 사람들이 Exif 대신 XMP를 쓰기를 바람 - Exif는 구조가 이상하고 본질적으로 TIFF 이미지를 PNG 내에 박아넣는 꼴임 - 이번 PNG 스펙은 이미 널리 통용되는 방식을 공식적으로 명문화함 - 최고의 코덱은 어디서나, 어떤 앱이든, OS 쉘이나 API, Linux 등에서도 작동해야 함 - HEIC나 AV1 같은 포맷은 OS 단의 지원이 없으면 파일을 미리 보기조차 힘듦 - 제대로 통용되지 않는 포맷은 플랫폼 기본값이 되어선 안 됨 - 나는 여러 이미지 포맷, 특히 특정 분야에서만 쓰는 희귀 포맷까지 다루는 업무를 함 - 다양한 포맷을 정말 지원하는 건 매우 큰 도전임 - 라이브러리도 표면적으로는 jpg/tif/heic 지원이라 써 있지만, 가령 30GB짜리 jpeg나 모든 메타데이터 지원까지 문제없이 되느냐 하면 그렇지 않음 - 이 새로운 스펙은 오히려 HEIC이나 AV1보다 더 혼란스러울 수 있음 - PNG 안에 어떤 코덱이 들어있는지 파일을 열어보기 전엔 전혀 알 수 없음 - 지금까지 HDR이 명확하게 밝기·명암 범위(contrast ratio) 확장 의미가 아닌, "더 넓은 색 공간"의 의미로 사용된 걸 처음 봄 - 너무 늦었는지 의문임 - 그리고 JPEG XL은 이미 모든 기능(손실/무손실 압축, 애니메이션, HDR, Exif 등)과 고급 압축 기술(유한 상태 기호 엔트로피, ZStandard 등)을 제공 중 - 별도의 PNG 업데이트는 필요 없고 그냥 JPEG XL을 쓰면 된다고 생각함 - "그냥 채택하면 된다"는 게 안 되는 현실 - [JPEG XL 브라우저 지원 현황](https://caniuse.com/jpegxl): 5년이 지났지만 지원하는 브라우저가 한 곳뿐임 - 브라우저 공급업체가 구현하지 않으면 개발자나 유저가 새 포맷을 쓸 수 없는 것이 현실임 - "고급 압축기법(ZStandard 등)" 언급에 대하여 - ZStandard는 일정한 변화폭을 가진 숫자(예: 그라데이션)를 압축하는 데는 오히려 좋지 않을 수 있음 - Bzip2는 이 방면에서 더 낫고, 예시처럼 두 변수(내부, 외부 반복)가 컬러 채널에 대응할 때 더 적합함 - 현실 데이터는 노이즈 때문에 단순하지 않지만, 이런 알고리즘 비교는 여전히 실제와 차이가 있음 - 참고: [관련 Mastodon 토론](https://chaos.social/@luc/114531687791022934) - "PNG 업데이트 필요 없다, JPEG XL만 채택하면 된다" - 그럴 거면 구글에 얘기해야 함 - 실제로 구글이 Chrome에서 JPEG XL 지원을 포기했고([관련 이슈](https://issues.chromium.org/issues/40168998#comment85)), 이로 인해 생태계 확장이 막혀버림 - 왜 또 다른 표준(파생형)을 만드는지 이해 못하겠음 - 이미 충분히 혼란스러운데, 독특한 판매 포인트도 없는 새로운 표준만 계속 늘어남을 한탄함 - 이제 GIF를 APNG(알파 블렌딩 + 투명 배경 + 무손실 압축)로 대체할 수 있게 되어 2000년대 웹 감성이 다시 살아날 수 있음 - Animated SVG도 표준이 있는지 궁금함 - 예전에 자바스크립트 기반 SVG 애니메이션(챗봇 아바타 같이)을 본 적 있는데, 표준 프레임워크가 있는지 잘 모르겠음 - Animated SVG는 존재함 - 주요 SVG 애니메이션 요소: set, animate, animateTransform, animateMotion - 자세한 설명: [SVG 애니메이션 관련 자료](https://www.w3schools.com/graphics/svg_animation.asp) - 요즘 GIF 대신 음성 없는 동영상(예: mp4)이 더 잘 압축돼 많이 쓰이는 걸로 알고 있음 - Animated PNG가 AV1 등 동영상 포맷에 비해 경쟁력이 있는지 궁금함 - GIF 업로드를 지원하는 대부분의 서비스에서 APNG나 animated WEBP 지원은 거의 전무함 - 백엔드 지원이 사실상 0에 가까워 매우 답답함 - 짧은 영상을 애니메이션 그래픽으로 변환하면, WEBP가 APNG보다 원래 더 좋았음 - GIF를 중간 포맷으로 쓰면 그나마 APNG가 경쟁력이 있음 - 요즘은 AVIF가 최고의 선택임 - 몇 년 전엔 Lottie(Bodymovin) 라이브러리 사용 경험이 있음 - Adobe After Effects에서 애니메이션을 만들고, svg와 json으로 내보낸 후 lottie JS로 웹에서 쉽게 애니메이션 적용 - 벡터 웹 애니메이션에서 제대로 된 도구나 DX(개발 경험)가 부족하다고 느꼈음 - animated PNG 쪽 도구 및 DX 정보도 궁금 - PR에서 "많은 프로그램이 새로운 PNG 스펙을 이미 지원한다"는 주장 중 - Photoshop이 APNG를 지원한다는 언급은 잘못됨 - APNG 인식이 What's new의 두 번째 항목임에도 불구하고 실제론 Photoshop에서 지원하지 않아 실망스러웠음 - Photoshop은 HDR 부분은 지원하지만, APNG 부분은 지원하지 않음 - 누군가 사람들이 시간/날짜 불확실성을 소프트웨어적으로 일치시켜 관리해야 한다고 언급 - "사진은 2025년 스캔, 내용은 부활절 무렵, 1920~1940년 사이" 같은 모호한 시간 정보 관리 필요성 - EXIF에는 DateTimeDigitized 필드가 있음 - 애매한 날짜 표기에 대해선 EDTF 스펙이 존재 - 참고: [EXIF 필드 설명](https://www.media.mit.edu/pia/Research/deepview/exif.html), [EDTF 스펙 공식문서](https://www.loc.gov/standards/datetime/) - 구글 포토와 애플 포토에서 직접 날짜를 지정할 수 있지만, 실제로 EXIF에는 저장하지 않음 - 플랫폼 이동시, EXIF가 없는 이미지들은 날짜 정보도 같이 사라지는 문제가 발생함