▲

새로운 PNG 스펙 릴리즈

(programmax.net)
6P by GN⁺ 9시간전 | ★ favorite | 댓글 2개
  • 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 호환성을 더욱 개선할 계획
  • 추가적으로 더 향상된 압축 방식, 병렬 인코딩/디코딩도 추진되고 있음
  • 네 번째 에디션은 비교적 짧은 업데이트가 될 예정이며, 이후 압축 기술 연구를 바탕으로 다섯 번째 에디션 개발 예정
▲
carnoxen 6시간전  [-]

Apng 처음에 단체에서 이미지에 대한 표준 아니라고 거부하다가 이제서야 인정했군요

답변달기
▲
GN⁺ 9시간전  [-]
Hacker News 의견

  • 저자임을 밝힘과 동시에 질문이 있으면 언제든 환영임을 알림

    • 이번 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도 붓 설정을 이렇게 저장하는데, 데이터가 너무 많을 때 예상치 못한 문제를 일으킬 수 있음

    • 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임

    • HALIC 토론 스레드를 보면 실제로는 LEA 0.5가 더 우수하다고 함

    • 솔직히 말해 JPEG XL을 한동안 "초대형 이미지" 용도로만 쓰는 줄 알고 무시했었음

    • 나는 컴퓨터 비전 이미지 어노테이션 툴(XLabel)에서 png를 사용함

      • 클래스 레이블을 이미지 메타데이터에 직접 저장해 텍스트 파일을 따로 두지 않아도 됨
      • 앞으로 이런 용도에 맞는 확장 포맷을 만들고 싶음

    • WebP의 무손실 압축은 업계 최고 수준이면서도 널리 쓰이지 않음

      • 무손실 압축에서 최고 성능을 내는 것 자체가 중요한 게 아니라, 오히려 생태계 채택이 더 큰 과제임을 시사함

    • 인코딩/디코딩 속도 문제는 시간이 지나면 개선될 수 있음

      • 이는 과거 jpg 생태계에서 실제로 일어난 변화임

  • 공식적으로 Exif 데이터 지원이 반영된 점이 최고의 소식임

    • 이전에도 헤더에 커스텀 데이터를 쓸 수 있었지만, Exif 지원은 매우 환영임

    • 참고로 Exif에 자이로스코프(회전)나 가속도(중력) 관련 필드가 있는지 궁금함

      • 구글 카메라 앱으로 찍은 사진에 이런 정보가 빠져있어서, 이후 자동 보정이나 파노라마 합성 때 아쉬운 경우가 많았음

    • 가속도 필드(Exif.Photo.Acceleration)와 고도를 위한 필드(Exif.Photo.CameraElevationAngle)는 있지만, 3축 전부를 지원하지 않음

      • 환경 센서(주변 조건)는 있지만, 스펙 작성자들이 지정한 특정 항목만 반영됨
      • Exif.Photo.MakerNote는 제작사에서 원하는 정보를 저장하는 자유로운 영역으로, 9축 데이터를 기록해도 충분할 정도로 크기 제한이 큼

    • Exif는 이미지 렌더링에서 회전 처리 방식에 따라 혼선을 불러올 수 있음

      • 구버전과 신버전 디코더가 Exif 회전 유무에 따라 서로 다르게 이미지를 보여줄 수 있음
      • Exif 회전에 대한 구체적인 디코더 권장사항이 없다 보니, 이중 회전(예: 데스크탑 환경과 라이브러리가 각자 처리) 같은 버그도 빈번히 발생함
      • "디코더가 Exif 데이터의 신뢰 여부를 별개로 알지 못하면, Exif 데이터는 기록적 가치로만 간주해야 한다"는 애매한 권장문구만 있을 뿐
      • 완전한 하위 호환을 위해선 "절대로 회전하지 마라" 같은 명확한 지침이 필요하다고 생각함

    • 카메라의 가속도계나 관성항법장치 데이터를 기록하는 표준 필드는 없음

    • 실제로 많은 웹사이트가 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 브라우저 지원 현황: 5년이 지났지만 지원하는 브라우저가 한 곳뿐임
      • 브라우저 공급업체가 구현하지 않으면 개발자나 유저가 새 포맷을 쓸 수 없는 것이 현실임

    • "고급 압축기법(ZStandard 등)" 언급에 대하여

      • ZStandard는 일정한 변화폭을 가진 숫자(예: 그라데이션)를 압축하는 데는 오히려 좋지 않을 수 있음
      • Bzip2는 이 방면에서 더 낫고, 예시처럼 두 변수(내부, 외부 반복)가 컬러 채널에 대응할 때 더 적합함
      • 현실 데이터는 노이즈 때문에 단순하지 않지만, 이런 알고리즘 비교는 여전히 실제와 차이가 있음

    • "PNG 업데이트 필요 없다, JPEG XL만 채택하면 된다"

      • 그럴 거면 구글에 얘기해야 함
      • 실제로 구글이 Chrome에서 JPEG XL 지원을 포기했고(관련 이슈), 이로 인해 생태계 확장이 막혀버림

    • 왜 또 다른 표준(파생형)을 만드는지 이해 못하겠음

      • 이미 충분히 혼란스러운데, 독특한 판매 포인트도 없는 새로운 표준만 계속 늘어남을 한탄함

  • 이제 GIF를 APNG(알파 블렌딩 + 투명 배경 + 무손실 압축)로 대체할 수 있게 되어 2000년대 웹 감성이 다시 살아날 수 있음

    • Animated SVG도 표준이 있는지 궁금함

      • 예전에 자바스크립트 기반 SVG 애니메이션(챗봇 아바타 같이)을 본 적 있는데, 표준 프레임워크가 있는지 잘 모르겠음

    • Animated SVG는 존재함

    • 요즘 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 필드가 있음

    • 구글 포토와 애플 포토에서 직접 날짜를 지정할 수 있지만, 실제로 EXIF에는 저장하지 않음

      • 플랫폼 이동시, EXIF가 없는 이미지들은 날짜 정보도 같이 사라지는 문제가 발생함
답변달기