Chrome에서 아주 작은 JPEG가 다르게 보이는 이유

Chrome에서 아주 작게 표시한 JPEG가 Firefox보다 두껍게 보이는 현상은 부분 IDCT 스케일링과 후속 축소 알고리듬이 함께 만든 결과임 큰 JPEG를 모두 압축 해제한 뒤 축소하면 메모리 낭비가 큼. 2000×2000 비트맵은 약 12MB지만 최종 20×20 이미지는 약 1.2KB에 불과함 JPEG는 이미지를 8×8 블록으로 나누고 DCT를 적용해 평탄한 색부터 체크무늬까지 주파수 성분별 계수로 저장함 Chrome의 Skia와 libjpeg-turbo는 목표 크기에 가까운 분모가 8인 비율로 저주파 데이터만 디코딩한 뒤 일반적인 다운샘플링으로 원하는 크기까지 줄임 1/8 크기에서는 상수 성분만 남아 경계의 부드러움과 그라데이션이 사라질 수 있으므로, 사진 인지에 맞춰 설계된 JPEG는 아이콘에 적합하지 않음 브라우저마다 달라 보인 작은 로고 15px로 렌더링한 로고가 Firefox보다 Chrome에서 더 두껍고 원본에도 덜 충실하게 보였음 SVG로 교체하자 차이가 사라졌으며, 원인은 Chrome이 작은 JPEG를 처리할 때 적용하는 디코딩 최적화에 있었음 예시에 사용된 이미지는 당시의 원본이 아니라 현상을 재현하려고 새로 만든 이미지임 전체 압축 해제의 비용 JPEG를 작은 크기로 표시하는 직관적인 방법은 전체 이미지를 메모리에 압축 해제한 뒤 축소하는 것임 2000×2000 JPEG를 20×20으로 표시할 경우 전체 비트맵은 약 12MB, 최종 이미지는 약 1.2KB를 차지함 축소하면서 큰 이미지의 정보 대부분이 사라지므로, 전체 크기로 먼저 디코딩하는 방식은 비효율적일 수 있음 축소할 때 사라지는 정보 이미지를 크게 축소하면 픽셀마다 빠르게 변하는 고주파 세부 정보가 주로 사라짐 잎과 거친 나무껍질이 있는 나무를 20×10으로 줄이면 잎은 녹색 덩어리, 줄기는 갈색 막대처럼 남음 일부 고주파 정보는 세부 요소들이 서로 섞이면서 제한적으로 유지될 수 있음 JPEG의 8×8 블록과 DCT JPEG 압축은 이미지를 8×8 블록으로 나눈 뒤 이산 코사인 변환(DCT)을 적용해 주파수 영역으로 옮김 각 블록의 주파수 표현은 여러 기저 함수(basis functions) 로 구성됨 가장 낮은 주파수에는 값이 변하지 않는 평탄한 색인 상수 성분이 있음 가장 높은 주파수는 값이 최대한 빠르게 변하는 체크무늬 형태임 그 사이의 패턴들이 나머지 주파수 영역을 나타냄 DCT는 각 8×8 블록에 패턴이 얼마나 포함됐...