libjpeg에서 이미지를 읽어들이는 부분의 코드(example.c)는 아래와 같다. /* Here we use the library's state variable cinfo.output_scanline as the * loop counter, so that we don't have to keep track ourselves. */ while (cinfo.output_scanline < cinfo.output_height) { /* jpeg_read_scanlines expects an array of pointers to scanlines. * Here the array is only one element long, but you could ask for * more than one scanline a..
최초 단초가 됐던 트윗에 나와 앞의 테스트들에 사용됐던 이미지들의 원출처를 확인했다. hadto.net의 GENERATION LOSS란 글이다. 글의 핵심은 최고 화질에서 조금씩 낮춰가며 jpeg 포맷으로 계속 읽었다 저장했을 때의 화질 저하를 확인하는 것. 같은 방식으로 사진 하나를 저장한 뒤 그 결과를 동영상으로 만들어봤다.우선, 사진을 하나 준비… 이 사진을 Q를 100에서 0까지 줄여가며 저장하면 아래와 같은 영상을 뽑을 수 있다. 위 영상을 보면 Q가 50 이하로 줄어들면 화면이 다소 심하게 깨지는 결과를 확인할 수 있다.그런데, 이 동영상/사진은 자칫 오독의 우려가 있다. 해당 이미지를 Q=30으로만 50번 저장한 결과를 보자. 그런데, 서서히 줄여가며 저장한 경우 Q=30으로 저장한 이미지는..
jpeg 인코더들의 화질 관련 마지막 포스팅. 이전 포스팅들에서 확인했듯이, jpeg로 수백번씩 읽었다 저장해도 심각한 수준의 화질 저하는 없었다.그런데, 바로 앞 포스팅에서 잠깐 확인해봤던 서로 다른 jpeg 인코더로 반복하는 경우를 조금 더 확인을 해보기로 했다.앞 포스팅의 그래프엔 샘플링 간격이 짝수이기 때문에 한 쪽 인코더의 결과만 나와있다는 점도 신경쓰였고. 선택한 인코더는 jpeglib-turbo와 mozjpeg.두 인코더를 번갈아가며 100회 저장한 결과의 PSNR은 아래 그래프와 같다. 뭔가 이상하다. 일정한 범위에서 계속 진동하는 결과를 보여준다.이건 좀 생각해볼 필요가 있는 묘한 부분이다. 더불어 앞의 포스팅 때 시험한 결과를 70회 반복 저장하면서, 저장 간격을 조금 다르게 출력해서 ..
Mozilla JPEG Encoder ProjectThis project's goal is to reduce the size of JPEG files without reducing quality or compatibility with the vast majority of the world's deployed decoders. 나는 jpeg 라이브러리로 mozjpeg을 사용한다.이 라이브러리는 위에서 보는 것과 같이 같은 화질에서 품질의 저하 없이 파일의 크기를 줄이는 목적으로 시작된 프로젝트다. 첫 버전이 출시되었을 때는 libjpeg-turbo에 jpegcrush 기능을 추가한 형태였는데, 이 때는 정말로 화질의 변화가 전혀 없었다. 그런데, 이제 3.0까지 업데이트되었고, 확인해보니 화질의 저하도 약..
발단은 한 줄의 트윗이었다.jpeg로 반복 저장을 600회하면 원래 없던 붉은 점이 가득 끼며 화질이 열화되는 것을 넘어 박살이 난다는 얘기다…이 트윗에 대한 답글로 온갖 이론이 난무하고, 결국 MS의 jpeg 인코더가 범인이라는 아무런 근거 없는 결론(?)이 났다. 근데, 근본적으로 생각해봤다.jpeg는 이미지를 저장할 때 코사인을 기반으로 하는 DCT 변환을 하고, 고주파 성분을 제거하는 방식으로 손실압축을 한다.즉, jpeg에서 화질의 열화는 있는 성분이 사라지는 것이지, 없던 게 태어나는 게 아니다.좀 쉽게 표현하면 날카로움이 사라지고, 흐릿해지며, 두리뭉실해지는 것이다. 반복 저장을 하면 화질이 열화되는 건 당연한데, 결코 저런 방식일 수가 없는 것이다. 이론은 이론일 뿐이고, 과연 얼마나 손상..
인터넷 환경이 아무리 빨라지더라도 그 바닥(?) 중요 테마 중 하나는 전송량을 줄이는 것이다.그리고, 전송량 중에서 이미지가 차지하는 비중은 굉장히 높다. 다양한 이미지 포맷이 있지만, 인터넷(특히 웹)에서는 JPEG과 PNG이 압도적으로 많이 쓰인다. JPEG가 1992년, PNG이 1996년에 발표됐으니 20년정도 지났고, 나올만한 기술은 다 나왔다고 봐야 된다. 즉, 이제 두 포맷의 압축률은 거의 한계점이라 보는 것이 정설이다. 많은 사람들이 그런 줄 알았다… 하지만, 현실은 언제나 외계인이 지배하는 법… 1. PNG 압축의 여력이 더 큰 쪽은 PNG이다.기본적으로 PNG은 무손실 압축이기 때문에 전처리를 거의 하지 않는다. 필터링 단계가 있기는 하지만, 큰 영향을 주는 정도는 아니다. PNG 파일..
2년쯤 전에 libjpeg 6b-SIMD와 libjpeg-turbo 등을 비교해본 적이 있었다. (JPEG 라이브러리 성능 비교)VCPP6에서도 컴파일되는 6b-SIMD와 VS2005 이상에서만 되지만 탁월한 성능의 turbo 등을 비교했었다. 그 때에 비해서 libjpeg-turbo의 성능이 훨씬 빨라진 것 같다.같은 이미지를 100번 읽었다 쓰는 테스트를 두 라이브러리를 이용해서 해본 결과…6b-SIMD에서는 28.689초 걸렸고… libjpeg-turbo에서는 21.918초 걸렸다. 즉, 현재 버전(1.3.0)은 6b-SIMD에 비해 1.3배 빠른 성능을 보여준다.요즘은 무슨 오픈 소스 만들 때도 외계인 몇 명 갈아넣는 거 같다… ㄷㄷㄷㄷ 덧1. libjpeg-turbo는 구글 크롬에서도 사용되는 ..