반응형


위대하신 나님 가로되, 윈도우 개객끼!


지난 포스팅에 이어지는 글이자, 위 트윗들 보고 어이 없어서 쓰는 포스팅.

물론, 위의 트윗들은 아래 트윗의 답글 중 일부다.



저 트윗을 쓴 분의 얘기는 그러니까…


1. 윈도우의 jpeg encoder는 DCT 변환 테이블을 잘못 만들었다고 추정함


2. C언어는 math.h의 오류로 sin/cos 함수는 오차가 꽤 나올 수 있음


대략 이렇게 정리될 수 있고, 요약하면 MS의 프로그래머들은 등신이라 저런 오류가 실제로 발생한다는 얘기다.




정말 저런 결과를 보여주는지 확인하기 위해 앞의 포스팅과 같은 기능을 하는 프로그램을 C#으로 만들었다.



이 프로그램은 이전의 프로그램과 사실상 동일한 기능을 한다. 딱 한 가지만 빼고.

믿을 수 있고, 수많은 사람들이 검증한 mozjpeg 대신 믿을 수 없고, 버그가 충만한 MS의 JpegBitmapEncoder를 사용한다는 것.


이 프로그램으로 지난번과 같은 소스를 놓고, 동일한 테스트를 해봤다.


같은 소스


품질을 바꿔가며 500번씩 저장해보는 것.

결과는 아래와 같다.


C#에서 JpegBitmapEncoder로 500번씩 저장한 결과


참고로, mozjpeg으로 테스트한 결과는 아래와 같다.


mozjpeg 라이브러리로 500번씩 저장한 결과


어? 뭔가 이상하다. 둘의 테스트 결과가 달라야 하는데, 거의 동일[각주:1]하다.

심지어 Q가 올라갈 수록 빨간 선이 왜곡되는 것도 똑같다.


그럴리가 없다. 멍청하고 아둔한 MS의 프로그래머들이 만든 jpeg 인코더는 노이즈를 마구 유발해야 되는 것인데!!!

혹시나 모르니까 PSNR의 변화를 확인해보자. MS의 jpeg 인코더가 엉망이기를 바라면서.


012


다시 한 번 mozjpeg으로 돌렸을 때의 PSNR을 꺼내보자.


012


이런! 이게 뭔가!

일정 횟수 이상으로 저장할 때 일정한 값으로 수렴하는 패턴부터 동일하다.

Q=40일 때는 아예 두 그래프가 일치하고, Q=90/100일 때는 심지어 C# 쪽이 PSNR이 더 크기[각주:2]까지 하다!


이 시험으로 내릴 수 있는 결론은 아래와 같다.


1. MS의 JpegBitmapEncoder는 mozjpeg와 거의 같은 코드[각주:3]를 사용함


2. MS의 프로그래머들이 저지른 DCT 테이블의 실수 같은 건 존재하지 않음


3. C언어의 math.h 얘긴 언급할 가치가 없음. 그게 맞으면 트위터가 아니라 IEEE에 제보해서 수정 요구하고 논문 써야 됨


4. 확실한 근거도 없으면서 MS 프로그래머 씹지 말라. 당신들의 수준은 훨씬 넘어서는 사람들만 모여있다.



덧1. 이번에도 다양한 이미지 파일에 대해 테스트해봤는데, 본 포스트의 내용을 넘어서는 결과는 나오지 않았음.


덧2. 이전 포스트의 덧2에 링크한 글헛소리임. MS의 인코더가 특별히 더 낮은 화질을 보여주지 않음. 전혀.



  1. 아주 엄밀히는 살짝 다르다. 두 PNG 파일은 크기도 몇 바이트 차이가 난다. [본문으로]
  2. PSNR이 클수록 왜곡이 적고 원본에 가깝다는 뜻임 [본문으로]
  3. 아마도 MS는 libjpeg를 라이센싱해서 사용한 것 같고, mozjpeg에서 보여준 미묘한 차이는 최적화 과정의 산물이라 보는 게 타당함 [본문으로]
반응형

공유하기

facebook twitter kakaoTalk kakaostory naver band