▲
GN⁺ 3달전 | parent | ★ favorite | on: Chromium이 JpegXL을 병합함(chromium-review.googlesource.com)
Hacker News 의견들

  • Cloudinary 블로그 글을 봤는데, webp, jpegxl, avif, jpeg 등을 비교한 오래된 명작 글임
    차트가 잘 정리되어 있고, AVIF는 매우 느림

    • JPEG을 가장 낮은 품질로 설정했을 때가 여기서는 훨씬 보기 좋았음
      관련 섹션 링크
    • 이 사이트가 정확히 뭘 하려는 건지 모르겠음
      스크린샷 참고
    • 인용된 문장처럼 JPEG XL이 현재 손실/무손실 모두에서 최고의 코덱 위치를 굳혔다면, JPEG과 PNG를 하나로 대체할 수 있는 큰 발전임
    • 다만 이 테스트는 하드웨어 가속 인코더/디코더를 사용하지 않음

  • jxl-rs 라이브러리는 JPEG XL의 Rust 구현체임
    비교적 새 프로젝트지만 Rust 덕분에 보안 안정성 면에서 안심이 됨
    예전 Chromium 논의 때는 이 라이브러리가 없었음

    • Google이 JPEG XL을 거부한 이유가 ‘관심 부족’ 때문이었던 걸로 기억함. 보안 문제 때문은 아니었던 듯함
    • “Rust가 보안 걱정을 덜어준다”는 말에 동의하지 않음. 메모리 안전성은 보안 그 자체가 아님
      Rust가 과신을 불러올 수 있고, 위협 모델링을 생략하는 경우가 생김
      오히려 주의 깊은 C 프로그래머가 더 안전할 수도 있음
    • 실제로 unsafe 코드가 얼마나 있는지 확인해봤음
      검색 결과 링크

  • 최근 WebP와 AVIF를 비교해봤는데, WebP는 거의 즉시 인코딩되는 반면 AVIF는 1MP 이미지에 20초 이상 걸림
    JXL은 아직 지원이 적어서 실제로는 못 쓰지만, WebP 수준의 속도에 더 나은 품질을 기대함

    • rav1e는 업데이트가 수년째 멈춘 상태라서 aom이나 svt-av1 같은 인코더를 쓰는 게 낫다고 함
    • AVIF는 CPU 사용 파라미터를 조정해야 함. 기본 설정이 너무 높은 CPU 레벨을 써서 느림
      내 환경에서는 2MP AVIF를 100ms 정도에 생성함

  • JPEG XL의 공개 명세(spec) 가 자유롭게 접근되지 않는 게 아쉬움

    • 비공개 표준을 유지하는 건 부끄러운 일이라고 생각함
    • ISO, IEC 같은 기관의 수많은 문서가 유료 벽(paywall) 뒤에 있는 현실이 문제임

  • 또 하나의 새 이미지 포맷을 받았는데, 결국 변환 없이는 못 쓰는 상황이 반복될까 걱정됨

    • 그래도 Microsoft조차 JPEG XL 애드온을 냈고, Google이 물러난 지금은 진짜 기회가 있다고 봄
      Microsoft Store 링크
    • 실제로는 이미 많은 앱이 지원함 — Affinity, Photoshop, Microsoft Photos, Gimp, 그리고 iOS 17+/macOS 12+의 시스템 전역 지원까지 있음
      Chromium이 오히려 늦은 편임
    • 물론 새로운 포맷은 항상 10년 정도의 도입 기간이 필요함

  • 위키에서 본 JPEG XL의 기능 목록을 읽어보니, 다중 채널 이미지나 멀티페이지 문서 같은 흥미로운 기능이 있음
    좋은 점도 있지만, 점점 TIFF처럼 복잡해지는 느낌임

  • JPEG과 JPEG-XL 사이에는 여전히 많은 공통점이 있음
    새 구현체가 기존 JPEG 지원까지 통합하면 코드 크기 절감이 가능하지 않을까 궁금함

    • 실제로 그 기능을 위한 이슈가 JPEG-XL Rust 저장소에 열려 있음
      이슈 #513 링크

  • 개인적으로는 WEBP처럼 새로운 포맷보다 기존 JPEG을 계속 쓰려 함
    대부분의 프로그램이 지원하고, 일반 사용자에게는 JPEG + PNG면 충분함
    간단한 애니메이션은 GIF, 복잡한 건 영상으로 처리하면 됨

    • “JPEG XL”은 이름과 달리 단순히 JPEG 확장판이 아님
      PNG보다 작은 용량으로 무손실 인코딩이 가능하고, 기존 JPEG을 20% 더 압축하면서 복원 가능한 트랜스코딩도 지원함
      HDR, 와이드 감마, 점진적 로딩 등 다양한 기능이 있어 웹 전송에도 이상적임
      jpegxl.info 참고
    • WebP는 이제 사실상 표준 포맷으로 봐도 됨
      Safari 14 이후 모든 주요 브라우저가 지원하고, Windows 10·macOS Big Sur 이후 기본 탑재됨
      지원 현황, 소프트웨어 목록 참고
    • GIF는 이제 비효율적임. 동영상으로 대체하는 게 5~10배 효율적임
      관련 글

  • JPEG XL, WebP, AVIF 논쟁을 오래 들어왔지만 잘 몰랐음
    벤치마크를 보면 JpegXL이 WebP보다 압축 속도와 크기 모두 우수한데, 왜 Chromium은 채택을 주저했는지 궁금함

    • WebP와 AVIF는 VP8/AV1과 코드가 공유되어 브라우저 통합이 쉬움, 반면 JPEG-XL은 별도 코드베이스라 구현 부담이 큼
      또한 libjxl은 C++ 10만 줄이 넘는 코드라 보안 취약점 위험이 있었음
      Rust 구현이 성숙해지면서 Chrome이 다시 검토하는 듯함
    • JPEG XL은 점진적 디코딩을 지원함
      데모 영상
    • Google은 “비슷한 포맷이 여러 개면 보안 위험만 늘어난다”며 AVIF 하나면 충분하다고 주장했음
    • AVIF는 낮은 bpp(저화질)에서는 좋지만 무손실은 약함, 반면 JXL은 고화질·무손실에서 강함
    • 과거 JPEGXL C++ 라이브러리가 유지보수 중단 상태였는데, Rust 버전이 등장하면서 브라우저 채택이 가능해졌음

  • JPEG XL이 애니메이션을 지원하는지 궁금했음

    • 지원은 하지만 프레임 간 압축이 없어 비효율적이라 일반 영상보다 용량이 큼
    • Chrome 플랫폼 상태 페이지에 따르면 애니메이션, HDR, 점진적 디코딩 모두 지원함
      상세 링크
    • 실제로 Canary 브라우저에서 테스트했더니 애니메이션이 잘 작동했음
    • 누군가 농담처럼 말하길, WebP는 사실상 “비디오 포맷인 이미지”인데, JPEG XL은 “이미지 포맷인 비디오”라서 역설적인 대칭 구조가 생겼다고 함 😄