내가 처음 mp3 파일을 구했을 때가 대략 1996년 초였다.윈도우 3.1에서 돌아가는 최초의 mp3 파일 플레이어인 WinPlay3을 어디선가 구했고, 이 때 mp3 파일 몇 개를 함께 구했었다. 이 무렵의 환경은 대략 이러했다. 1. 이전에는 재생 가능하면서 괜찮은 음질을 지원하는 오디오는 mp2 파일밖에 없었는데, mp3보다 파일은 크고 음질은 낮았음 2. WinPlay3이 나오기 전에는 mp3를 실시간으로 재생할 수 있는 프로그램이 없었고, wav 포맷 등으로 변환해야 들을 수 있었음 그렇게 처음 구한 mp3 플레이어는 훌륭한 음질을 들려는 줬다.하지만, 한계가 있었으니… 앞뒤로 이동하는 기능이 없어 한번 듣기 시작하면 끝까지 듣거나 중단하는 수밖에 없었다. 이 문제는 결국 전설의 Winamp가 ..
며칠간 삽질한 것을 잊지 않으려고 적는 포스팅 jpeg 파일에서 다양한 정보를 담는 Exif영역은 IFD로 구분되고, 제일 먼저 등장하는 것이 IFD0이다. 그리고, 각 IFD와 데이터의 저장 위치는 TIFF 헤더로부터의 offset으로 위치를 표현한다. 그리고, IFD0의 offset는 당연하게도 8이다. 자작 프로그램들 중에 exif를 수정하는 프로그램들은 이 값을 8로 하드코딩해서 만들었다. 그런데, 이 값이 8이 아닌 jpeg 파일을 만나게 됐다. 당연히 프로그램은 오류를 유발하고 exif 영역이 망가졌다. 결국 8로 하드코딩한 부분을 모두 정상적으로 읽어서 처리하도록 수정해서 문제 해결.
최초 단초가 됐던 트윗에 나와 앞의 테스트들에 사용됐던 이미지들의 원출처를 확인했다. 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까지 업데이트되었고, 확인해보니 화질의 저하도 약..
2015/04/05 - jpeg#1 : 같은 이미지를 jpeg로 반복 저장하면 정말로 박살나는가? 지난 포스팅에 이어지는 글이자, 위 트윗들 보고 어이 없어서 쓰는 포스팅. 물론, 위의 트윗들은 아래 트윗의 답글 중 일부다. 저 트윗을 쓴 분의 얘기는 그러니까… 1. 윈도우의 jpeg encoder는 DCT 변환 테이블을 잘못 만들었다고 추정함 2. C언어는 math.h의 오류로 sin/cos 함수는 오차가 꽤 나올 수 있음 대략 이렇게 정리될 수 있고, 요약하면 MS의 프로그래머들은 등신이라 저런 오류가 실제로 발생한다는 얘기다. 정말 저런 결과를 보여주는지 확인하기 위해 앞의 포스팅과 같은 기능을 하는 프로그램을 C#으로 만들었다. 이 프로그램은 이전의 프로그램과 사실상 동일한 기능을 한다. 딱 한 ..
발단은 한 줄의 트윗이었다.jpeg로 반복 저장을 600회하면 원래 없던 붉은 점이 가득 끼며 화질이 열화되는 것을 넘어 박살이 난다는 얘기다…이 트윗에 대한 답글로 온갖 이론이 난무하고, 결국 MS의 jpeg 인코더가 범인이라는 아무런 근거 없는 결론(?)이 났다. 근데, 근본적으로 생각해봤다.jpeg는 이미지를 저장할 때 코사인을 기반으로 하는 DCT 변환을 하고, 고주파 성분을 제거하는 방식으로 손실압축을 한다.즉, jpeg에서 화질의 열화는 있는 성분이 사라지는 것이지, 없던 게 태어나는 게 아니다.좀 쉽게 표현하면 날카로움이 사라지고, 흐릿해지며, 두리뭉실해지는 것이다. 반복 저장을 하면 화질이 열화되는 건 당연한데, 결코 저런 방식일 수가 없는 것이다. 이론은 이론일 뿐이고, 과연 얼마나 손상..
까먹지 않으려고 포스팅 함. ffmpeg은 그야말로 만능 오디오/비디오 트랜스 코더다. 오디오 변환 시 항상 ffmpeg를 사용하는데, 심지어 직접 변환을 못 하는 경우에도 커다란 도움을 준다. 예컨데, 비디오에 들어있는 2번째 오디오를 AAC로 변환[각주:1]하려면 다음과 같이 하면 된다. ffmpeg -i test.mkv -map 0:2 -vn -acodec pcm_s32le -f wav - | neroAacEnc -lc -if - -ignorelength -of out.aac 또, 2번째 오디오가 32비트/5.1CH이고 스테레오로 변환한 뒤 AAC로 변환하려면 이렇게 하면 된다. ffmpeg -i test.mkv -map 0:2 -vn -acodec pcm_s32le -f wav - | ffmpeg..
멍청하게 실수한 내용을 정리해서 나중에 똑같은 반복을 하지 않기 위해 기록 디카들로 찍은 사진을 손쉽게 정리하기 위해 디카 사진 정리 도구 FPO(Family Photo Organizer)를 만들어 쓰고 있다. 한땀 한땀 만든 코드라, 버그가 없다고 착각생각하며 쓰고 있었는데…치명적인 버그를 발견했다.실수로 Exif에서 GPS 위치 정보를 삭제하도록 만든 것이다. 더 미치는 건, 깔끔하게 GPS 정보를 날리는 게 아니라 계산 오류로 GPS 정보 필드를 반토막… lllorz 1. 아이 클라우드 일단 PC로 복사하고 폰에서 삭제한 사진들의 백업본을 뒤져봤다.잡스 느님의 은혜로우신 작품 아이 클라우드가 있어 사진들이 다 백업되어있…을줄 알았다.하지만, 뒤져보니 70장 정도밖에 백업이 안 되어있었다. 일단 이 ..
2014/03/08 - 이미지 파일 크기 축소에 대한 단상 이전 글에서 언급했듯, PNG 압축의 대마왕 tinyPNG는 pngquant의 웹 프론트엔드이다.재미있는 건 tinyPNG는 유료 플러그인도 판매되고 있지만, 정작 pngquant는 오픈소스라는 점. - 소스는 github에서 공개되고 있으며, 라이센스는 BSD-like License. - 소스는 C99로 작성되어 있기 때문에 Visual Studio 2013 이상으로만 컴파일 가능함. OTL - 소스는 실행파일/라이브러리 모두 제공함 - 실행파일도 별도로 공개하고 있으며, 윈도우 용은 여기서 받을 수 있음. - Floyd-Steinberg 디더링 여부를 선택할 수 있는데, 안 쓰는 쪽이 좀 더 자연스럽다는 느낌. - 압축 후에 OptiPNG 등..
인터넷 환경이 아무리 빨라지더라도 그 바닥(?) 중요 테마 중 하나는 전송량을 줄이는 것이다.그리고, 전송량 중에서 이미지가 차지하는 비중은 굉장히 높다. 다양한 이미지 포맷이 있지만, 인터넷(특히 웹)에서는 JPEG과 PNG이 압도적으로 많이 쓰인다. JPEG가 1992년, PNG이 1996년에 발표됐으니 20년정도 지났고, 나올만한 기술은 다 나왔다고 봐야 된다. 즉, 이제 두 포맷의 압축률은 거의 한계점이라 보는 것이 정설이다. 많은 사람들이 그런 줄 알았다… 하지만, 현실은 언제나 외계인이 지배하는 법… 1. PNG 압축의 여력이 더 큰 쪽은 PNG이다.기본적으로 PNG은 무손실 압축이기 때문에 전처리를 거의 하지 않는다. 필터링 단계가 있기는 하지만, 큰 영향을 주는 정도는 아니다. PNG 파일..
iTrans에서 함께 배포하는 mp4box의 버전은 0.4.6-DEV이다. 이 프로그램은 변환 최종단계에서 비디오와 오디오/자막을 합치는(muxing), 가장 중요한 툴이다. 그런데, 현재 정식 배포되는 버전은 0.5.0이고, 0.5.1이 하루에도 몇번씩 업데이트되고 있다. 그럼에도 불구하고, 구버전을 함께 배포하는 이유는 간단하다. 최신버전들에선 구버전에 없던 오류가 계속 발생하기 때문이다. 그간 만난 굵직한 오류들은 대략 다음과 같다. - avi+AC3 오디오 파일에서 비디오를 추출하지 못함 - 5.1ch AAC 오디오를 muxing하면 결과 파일을 아무런 프로그램으로도 읽을 수 없음 너무나 흔하게 발생하는 상황인데, 이를 처리하지 못한다. 어쩌면 프로그램이 안정화가 덜된 게 아니라, 핵심 개발자가 ..
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는 구글 크롬에서도 사용되는 ..
