형식 논쟁은 대개 코덱에서 출발해 바깥으로 뻗어 나갑니다. 순서가 거꾸로입니다. 알맞은 형식은 그림 안에 무엇이 있느냐로 정해지고, 그다음에야 받는 쪽 시스템이 무엇을 허용하느냐로 정해집니다.
사진: JPEG 아니면 WebP
얼굴이나 풍경처럼 그러데이션과 노이즈가 이어지는 연속 톤 이미지는 손실 코덱으로 잘 압축됩니다. 복잡한 영역에서는 눈이 작은 오차를 잘 알아채지 못하기 때문입니다. 어디서나 받아 주기 때문에 JPEG이 안전한 기본값입니다. 손실 WebP는 같은 체감 화질을 눈에 띄게 적은 바이트로 냅니다. 받는 쪽이 허용하기만 한다면 WebP가 이깁니다.
ToolZool로 이 작업을 하신다면 한 가지 단서가 있습니다. 저희 압축 도구는 WebP를 무손실 모드로만 씁니다. 사진에서는 JPEG보다 몇 배 큰 파일이 나온다는 뜻입니다. 용량 제한이 걸린 사진이라면 여기서는 JPEG을 고르세요. 그 차이가 생기는 이유는 압축 도구 페이지에 적어 두었습니다. 라이선스가 맞지 않거나 C 툴체인이 필요한 것뿐이라, 저희가 실어 보낼 수 있는 손실 WebP 인코더가 없습니다.
단색 그래픽과 글자: PNG
로고와 아이콘, 다이어그램, 화면 캡처는 또렷한 경계선과 같은 색이 넓게 이어지는 면으로 이뤄져 있습니다. 손실 코덱은 또렷한 경계선을 잘 다루지 못합니다. 글자 주변에 눈에 보이는 물결무늬가 생기고, 그렇게 생긴 잡음 자체가 인코딩 비용이 비싸서 같은 이미지의 무손실 PNG보다 파일이 더 커지는 일이 흔합니다.
투명도가 있으면 선택지가 좁아집니다
JPEG에는 알파 채널이 없습니다. 투명한 PNG를 JPEG으로 바꾸면 투명했던 영역이 불투명해집니다. 보통 검정, 가끔 흰색, 원하시던 색인 경우는 드뭅니다. PNG와 WebP는 둘 다 알파를 지원하므로, 이미지에 투명도가 있다면 후보는 이 둘로 줄어듭니다.
AVIF는 어디에 놓이나
같은 화질이라면 AVIF가 WebP보다 파일이 작습니다. 특히 낮은 비트레이트에서 그렇고, 요즘 브라우저는 모두 AVIF를 표시할 수 있습니다. 문제는 인코딩입니다. JPEG이나 WebP보다 훨씬 느리고 훨씬 무겁습니다. 인코딩이 빌드 서버가 아니라 휴대폰에서 일어난다면 이 차이가 중요해집니다.
ToolZool은 오늘 AVIF를 읽지도 쓰지도 못합니다. 양쪽 모두 AV1 코덱이 필요한데, 관리되고 있는 구현은 하나같이 WebAssembly로 빌드되지 않는 C 라이브러리입니다. 그래서 AVIF 파일은 다른 곳에서 먼저 변환해 오셔야 합니다. 대부분의 아이폰이 기본으로 만드는 HEIC도 사정이 같습니다.
이 모든 것을 뒤엎는 질문
그 양식이 무엇을 받아 주나요? 거부당하는 더 나은 형식은 더 나은 형식이 아닙니다. 허용 목록을 먼저 읽고, 그 안에서 최적화하세요. 조건을 다 만족하는 것 같은 파일이 계속 거부된다면 업로드 양식이 파일을 계속 거부하는 이유에서 양식이 실제로 돌리는 네 가지 검사를 짚어 봅니다. 형식 사이를 오가셔야 한다면 이미지 압축 도구가 JPG와 PNG, WebP를 읽고 JPEG과 PNG, 무손실 WebP를 쓰므로 그 범위 안에서는 변환기 노릇도 합니다.
