LITTLEImg
형식 이미지 압축
ENKO

방법론

이 페이지는 도구가 내부적으로 어떻게 동작하는지 설명합니다. 맞바꿈이 무엇인지 이해하고 결과를 스스로 판단하실 수 있도록 하기 위해서입니다. 한계가 있는 부분은 나중에 발견하시도록 남겨 두지 않고 한계라고 적었습니다.

브라우저 기반 처리

모든 이미지는 createImageBitmap()으로 디코딩하고, 캔버스(지원되는 환경에서는 Web Worker 안의 OffscreenCanvas)에 그린 뒤, canvas.toBlob()으로 다시 인코딩합니다. 워커가 메인 스레드를 비워 두기 때문에 큰 사진을 인코딩하는 동안에도 페이지가 반응하고, 파일은 기기를 벗어나지 않습니다. 보낼 업로드 엔드포인트 자체가 없습니다.

OffscreenCanvas나 워커를 쓸 수 없는 환경, 그리고 DOM으로 안전하게 해석해야 하는 SVG는 같은 파이프라인을 메인 스레드에서 실행합니다. 결과는 동일하고 페이지의 반응성만 달라집니다.

형식 지원

각 형식을 읽고 쓸 수 있는지, 그리고 무엇이 살아남는지.
형식 읽기 쓰기 투명도 애니메이션
JPG가능가능형식이 지원하지 않음없음
PNG가능가능온전한 알파, 유지됨없음
WebP가능가능온전한 알파, 유지됨첫 프레임만
AVIF브라우저가 디코딩하면 가능브라우저가 인코딩할 때만온전한 알파, 유지됨첫 프레임만
GIF가능불가1비트, 출력에서는 온전한 알파로첫 프레임만
BMP가능불가거의 없음, 디코딩되면 유지없음
SVG정리 후 가능불가PNG·WebP로 쓸 때 유지없음
HEIC이 빌드에서는 비활성불가——

JPG로 쓰면 투명도가 설정 패널에서 고른 배경색 위로 합쳐집니다. 바꾸지 않으면 흰색이며, 조용히 검정으로 채우는 일은 없습니다. 움직이는 GIF와 WebP는 첫 프레임으로 처리되고, 나머지를 조용히 버리는 대신 페이지가 그렇다고 알려 드립니다.

JPEG 압축

JPEG은 브라우저에 내장된 손실 인코더를 사용합니다. 품질 값(0~100)은 고주파 디테일을 얼마나 버릴지 조절합니다. 저희는 제공하신 원본에서 압축하며, 이전 JPEG 저장이 이미 없앤 디테일을 되살릴 수는 없습니다. 그래서 내보낸 파일을 다시 압축하는 것보다 가지고 계신 가장 좋은 원본에서 작업하는 편이 언제나 결과가 낫습니다.

PNG 최적화

PNG 출력은 무손실입니다. 그래서 PNG를 선택하면 품질 슬라이더를 살려 둔 채 무시하는 대신 비활성화합니다. PNG를 줄이는 방법은 무손실로 다시 인코딩하거나, 미디언 컷 양자화로 색상 팔레트를 줄이거나(그러데이션과 부드러운 가장자리에 띠가 생길 수 있습니다), WebP로 변환하는 것입니다. 어느 쪽이든 투명도는 유지됩니다.

WebP와 AVIF

WebP는 알파 채널과 함께 손실·무손실 모드를 지원합니다. AVIF는 보통 압축률이 더 좋지만 인코딩이 느리고, 만드는 기능의 지원 범위가 보여 주는 기능보다 훨씬 좁습니다. 저희는 실행 시점에 브라우저를 검사해 그 검사가 통과할 때만 AVIF 출력을 제공합니다. 옵션을 보여 준 뒤 실패하는 일이 없도록 하기 위해서입니다.

EXIF 방향

디코딩할 때 imageOrientation: 'from-image'를 요청하므로, 회전 정보가 붙은 사진은 다른 작업이 시작되기 전에 픽셀 자체가 똑바로 세워집니다. 그래서 메타데이터를 지운 이미지가 옆으로 눕지 않습니다. 회전이 이미 반영되어 있기 때문입니다.

색상 프로파일(ICC)

이것은 실제 한계이며 전문적인 작업을 처리하기 전에 알아 두실 필요가 있습니다. 캔버스 파이프라인은 브라우저의 캔버스 색 공간에서 동작하며, 인코딩된 결과에는 원본 파일에 포함되어 있던 ICC 프로파일이 옮겨지지 않습니다. 이미 sRGB인 대다수 이미지에서는 눈에 보이는 변화가 없습니다. 다만 광색역 원본 (Display P3, Adobe RGB, ProPhoto)에서는 채도가 높은 색이 달라질 수 있으며, 결과물은 sRGB 사본으로 보시는 편이 맞습니다. 색 관리가 중요한 작업이라면 원본을 보관하고 프로파일을 명시적으로 다루는 데스크톱 프로그램을 사용하세요.

SVG 처리

SVG는 픽셀만이 아니라 코드입니다. 그래서 그리기 전에 해석하고 정리합니다. script, foreignObject, iframe, embed, object, audio, video와 애니메이션 요소를 제거하고, 모든 on… 이벤트 속성을 떼어내며, href는 같은 문서 내 참조와 인라인 data:image/ 값으로만 제한합니다. @import를 쓰거나 원격 URL을 가져오는 내장 스타일시트는 삭제하고, 문서 밖을 가리키는 url()이 들어 있는 속성은 모두 제거합니다. 래스터화는 blob URL을 불러오는 <img> 요소를 통해 이뤄지는데, 이는 명세상 스크립트를 실행하지도 하위 리소스를 가져오지도 않습니다. 정리 과정은 유일한 방어선이 아니라 두 번째 층입니다.

크기 조절

크기 조절에는 고품질 캔버스 리샘플링을 사용합니다. 맞추기는 이미지 전체를 지정 범위 안에 넣고, 채우기는 가운데를 기준으로 잘라 범위를 덮으며, 정확히와 비율 모드도 제공합니다. 확대는 기본으로 꺼져 있습니다. 보간은 애초에 담기지 않은 디테일을 만들어낼 수 없기 때문입니다. 확대한 이미지는 더 흐릿한 이미지이고, 도구는 그렇지 않은 척하는 대신 그렇다고 말합니다.

메타데이터 제거

결과물은 원시 픽셀에서 다시 만들어지므로 EXIF, GPS, 카메라, 시각 정보가 옮겨지지 않습니다. 형식에 따라 컨테이너 고유의 데이터가 남을 수 있으며, 이 점은 부풀리지 않고 그대로 밝힙니다. 메타데이터 검사기는 찾아낸 묶음의 이름만 표시합니다. 값은 표시하지 않으므로 GPS 좌표가 제거되는 과정에서 화면에 뜨는 일은 없습니다.

목표 용량

목표 용량 모드는 0.3과 사용자가 정한 품질 사이에서 인코더 품질을 이진 탐색하며, 최대 여덟 단계까지 진행하고 탐색 구간이 0.02보다 좁아지면 멈춥니다. 그 범위의 가장 낮은 품질로도 목표를 넘는다면 해상도를 한 번에 15%씩, 최대 여섯 번까지 줄이며 가로세로 64 px를 하한으로 두고 매 단계마다 다시 인코딩합니다.

정확한 용량은 보장하지 않습니다. 인코더는 그렇게 동작하지 않습니다. 결과는 목표 이하이면 도달, 목표보다 15% 이내로 크면 근접, 그 밖이면 실패로 보고하며, 그 과정에서 해상도를 줄여야 했다면 그 사실도 함께 알려 드립니다.

결과가 원본보다 커질 때

이런 일은 생기며 버그가 아닙니다. 이미 잘 압축된 파일을 다시 인코딩하면 대개 바이트가 줄기보다 늘고, 사진을 PNG로 바꾸거나 작은 이미지를 헤더가 큰 형식으로 옮길 때도 마찬가지입니다. 모든 도구가 두 용량을 비교해, 결과가 더 클 때는 경고 색으로 증가라고 표시하고 원본을 선택된 상태로 두며 다른 출력 형식을 권합니다. 성공적인 최적화로 포장하는 일은 없습니다.

일괄 처리와 제한

여러 파일은 동시 실행 수가 제한된 큐를 통해 처리되므로 고해상도 이미지가 한꺼번에 메모리로 디코딩되지 않습니다. Object URL, 비트맵, 캔버스는 작업이 끝나는 대로 해제되고, 취소하면 인코딩 중인 파일이 끝나기를 기다리지 않고 워커를 즉시 종료합니다.

이 제한은 서버가 아니라 사용자의 브라우저를 보호하기 위한 것입니다. 처리 경로에 서버가 없습니다. 메모리가 부족해 탭이 죽으면 작업 목록 전체를 잃게 되는데, 그것은 두 번에 나눠 처리해 달라는 안내보다 훨씬 나쁜 결과입니다.

가이드의 수치를 다루는 기준

저희는 자체 압축률 수치를 발표하지 않습니다. 그것을 정당화할 문서화된 반복 가능한 테스트를 돌린 적이 없기 때문입니다. 가이드에 나오는 모든 수치는 다음 셋 중 하나입니다:

인용한 연구의 범위 값은 이미지 모음 전체에 대한 평균입니다. 사용자의 이미지는 모음이 아닙니다. 도구는 본인 파일의 실제 전후 용량을 보여 주며, 믿을 값은 그 숫자입니다.

편집 원칙과 정정

가이드는 LITTLEImg 편집팀이 작성하고 검토합니다. 전문가 이름, 후기, 평점, 수상 내역을 지어내지 않으며, 이 사이트 어디에도 그런 것은 없습니다. 어느 페이지든 틀렸거나, 오래됐거나, 도구가 실제로 하지 않는 내용을 발견하시면 알려 주세요. 사실 관계 오류는 해당 페이지에서 바로 고치고, 가이드의 갱신일도 함께 바뀝니다.

알려진 한계와 브라우저 차이