소프트웨어 구글 GUETZLI 품질 저하없이 JPG 압축효율 최대 35% 향상

오픈소스이므로 그래픽툴 제작사에서 JPG 저장부분에 소스를 적용할수 있습니다

Freeware만 가능할 겁니다.  shareware이상의 제품을 만들땐 오픈소스를 사용할 수 없죠.

아파치 라이센스라 상업용으로도 사용할 수 있을 거예요.

컴 사항만 높다면....

웹서버같은건 어차피 시퓨 거의 놀고 있으니 서버에 있는 파일들 대량으로 변환 걸어두고, 몇일후 결과물만 회수해도 서버 용량 줄어듭니다

그렇긴 한데, 제가 TEUS.me님의 테스트 결과보고 간단히 비교해본 봐로는, 느린데 비해 전혀 메리트가 없는 것 같습니다.

https://lite.parkoz.com/zboard/view.php?id=express_freeboard2&no=429594

추가 : 다른 테스트를 해보니 최대한 손실률을 줄이면서도 압축률을 높이려고 하는 것 같습니다.

https://lite.parkoz.com/zboard/view.php?id=express_freeboard2&no=429597

tinypng는 png 파일을 8bpp로 압축하는 것이고, guetzli는 jpeg를 압축하는 거라 대상 포맷 자체가 다릅니다.

수고하셨습니다

용량이 줄어드는 만큼 화질 열화가 극심해지면 그다지 효용성이 없어보이네요 (옛날에 압축 방식에 따른 효율성 변화 확인하느라 시험(일정치 넘어가니 시간은 기하급수적으로 증가했지만, 용량은 거의 안 줄어듬)해봤을때 결과가 떠오르는군요)

연산 성능 문제는 시간이 지나면 해결책이 나올지 모르겠지만, 결과물이 별로인건 좀 문제군요

설마하니 구글이니 사기는 안치겠지 싶었는데,

역시나....

구글이 말하는 화질저하 없이라는건 그냥 "눈에는 안띈다"는 수준인듯?

그런식이면 

기존 포맷으로도 눈에 띄는 화질차이 없이 상당한 용량 감소효과가 있고,

심지어 10배 가까운 차이도 나는데,

35% 줄였다길래 뭐 믿는게 있기는 있는건가 했는데,

결국 사기였나보네요. ㅋ

35% 줄였다는걸 증명하려면,

똑같은 이미지를 불러서 비트맵정보로 1:1 픽셀 비교해서 완벽하게 일치한다...

이정도는 되어야하는데, 그게 아니라면 말짱 말장난인거같네요.

왜냐하면 애초에 "화질"이라는건 어느정도 주관적인 부분이 있는데,

일치하지 않으면 의미가 없죠.

구글은 libjpeg랑 비교한거지 mozjpeg랑 비교하지 않았습니다.

그리고 제가 테스트해 본 봐로는 mozjpeg 대비 나름 장점은 있습니다. (위에 링크했습니다.) 그게 얼마나 의미가 있을진 모르겠지만요.

사실 무엇보다, JPEG자체가 손실 압축이기 때문에, 1:1 픽셀 비교해서 완벽하게 일치 어쩌고는 아무것도 모른다는 얘기밖에 안 됩니다.

그런 기준으로 따지면 지금까지 나온 차세대 포맷(JPEG 2000, JPEG XR, WebP, VP9, H265 등) 모두 사기가 됩니다. -_-;;

(JPEG 2000, JPEG XR는 무손실도 포함하는 포맷이긴 합니다만, 그래도 손실 압축 부분을 더 내세웠기 때문에 메리아님 논리대로라면 명백히 사기 포맷입니다. 심지어 AAC, H264등도 마찬가지죠)

애초에 JPEG 만들 때부터의 목표가 화질저하 없이라는건 그냥 "눈에는 안띈다"는 수준이었고 지금까지 기술개발은 다 그렇게 해왔습니다. 무손실로는 멀티미디어 용량 감당을 못 하니깐요.

mozjpeg도 화질저하 없이라는건 그냥 "눈에는 안띈다"는 수준이고 똑같은 이미지를 불러서 비트맵정보로 1:1 픽셀 비교해서 완벽하게 일치시키는거 절대 불가능 합니다. (이렇게 얘기하는 건 위에 링크했던 두번째 테스트 결과 때문입니다. 여기 다시 링크합니다.

[평가] 구글 Guetzli vs 모질라 mozjpeg 서브샘플링 간단 테스트 - https://lite.parkoz.com/zboard/view.php?id=express_freeboard2&no=429597

여담으로, 첫번째 테스트는 TEUS.me님과 비슷한 결과가 나왔습니다. [평가] 구글 Guetzli vs 모질라 mozjpeg 간단히 테스트 해봤습니다. - https://lite.parkoz.com/zboard/view.php?id=express_freeboard2&no=429594 )

35%는 정확히는 알 수 없지만 libjpeg 대비 피크치로 보입니다. up to % 장난질이야 너나 할거없고 하루이틀 얘기도 아니니...

모질라 mozjpeg도 기존 포맷으로 눈에 띄는 화질차이 없이 상당한 용량 감소효과를 내는 신기술 인코더이고

구글 guetzli도 기존 포맷으로 눈에 띄는 화질차이 없이 상당한 용량 감소효과 를 내는 신기술 인코더인데

둘의 우열을 가지고 모질라 mozjpeg를 기존 구형 기술 취급하면서까지 사기로 몰아가는건 억지로 보입니다.

결국 주관적 화질 측면에서 모질라(mozjpeg)가 구글보다 잘 만든 것 뿐입니다. 모질라 측 블로그의 관련 내용을 보면 화질 차이를 수치로 계산하는 표준 네가지(PSNR, PSNR-HVS-M, SSIM, MS-SSIM) 중 어느게 주관적 화질 측면에서 나은지 연구 끝에 모두 지원하되, 기본값만 PSNR-HVS-M로 하는 등 심도 있게 연구한 것으로 보입니다.

반면 구글 guetzli는 연산을 엄청나게 때려넣어서 기존 기술(mozjpeg가 아닌 libjpeg) 대비 적은 손실률로 압축률을 최대한 끌어내려 해보는 것으로 보이는데, 문제는 주관적 화질을 mozjpeg처럼 잘 반영하지 못하다 보니 적당히 비교하면 mozjpeg보다 느리고 용량 크고 화질 떨어지는 꼴 밖에 안 난다는 거죠.

다만 특정한 경우에는 mozjpeg보다 나은 점도 있는데...그게 얼마나 쓸모가 있을지는 회의적으로 보이긴 합니다만, 그건 저 같은 개인이 약간의 테스트 결과가지고 결론낼 게 아니라 커뮤니티가 결정할 일이겠죠.

추가로 역사적인 흐름을 보면, JPG가 92년에 나온 포맷(25년 되었네요 ㄷㄷㄷ)이기 때문에 이미 2000년도에 한계를 넘어서기 위해 JPEG2000이 먼저 나왔으나 쉽게 보급되지 않았고, 조금 뒤에 JPEG XR이 나와서 경쟁했죠. (압축시대 → 반디집으로 유명한 키플러님이 저 두 포맷을 개인이 쓰기 쉽게 만드신 변환기인 JPEG 너머가 2007년에 처음 나와서 8년에 마지막 업데이트가 나왔죠)

하지만 둘 다 보급은 실패했고, 모질라가 그럼 기존 JPG 포맷가지고 어떻게든 해보자 해서 14년부터 만든게 mozjpeg 입니다. (14년 3월 5일에 발표했고, https://blog.mozilla.org/research/2014/03/05/introducing-the-mozjpeg-project/ 가장 최근의 메이져 버전업인 3.0은 14년 말에 나왔습니다. https://joshaas.wordpress.com/2014/12/30/mozjpeg-3-0-released/ )이렇게 보면 왜 mozjpeg를 기존 기술 취급 하면 안 되는지가 명백히 보입니다.

반면에 구글은 WebP를 밀고 있고 나름 효과도 상당합니다. ( https://lite.parkoz.com/zboard/view.php?id=express_freeboard2&no=429577 여기 3번째 댓글 참고)

하지만 아직까지 크롬에서만 지원하는 셈이라는 약점이 있습니다. (IE최강국이던 우리나라에서조차 스탯카운터 기준 크롬 점유율이 1위이니 JPEG2000이나 XR처럼 쉽게 좌절되진 않을 듯 합니다만)

여튼, WebP만 믿기엔 아직 한계가 있으니, 역시 기존 JPG 포맷으로도 어떻게든 해보려고 한 모양인데, mozjpeg 대비 뒷북이죠. ^^;;;

그래서 다른 방향으로 파고든 모양인데, 현재까진 mozjpeg대비 잘 하고 있는 것 같진 않네요.

그러니깐 구글 guetzli가 사기가 아니고, 모질라 mozjpeg가 그만큼 뛰어나게 잘 만든 신기술이라는 겁니다.

WebP라면 성공적으로 정착한듯합니다

3대 브라우저 (이미 오페라는 자체 코어 개발 포기했으니 제외)인 IE/FF/Chrome중 개발이 중단된 IE를 제외한 2개가 지원하니까요

PNG대비 25%가량 용량이 적다고 주장하는데, 어차피 이건 손실포맷이니 당연한거고, 하드웨어 가속이 지원되지 않는 머신에서 디코딩시 연산부하가 너무 극심한 문제(특히 animated인경우 동일 해상도 h.264@mp4의 2배 이상(8bit h.264디코더는 흔하다보니 이경우 심하면 10배인경우도 봤음) 걸림)가 해결되면 보급 문제 없어보입니다 (구형 하드웨어가 퇴출되면 해결될 문제니 시간 지나면 자동입니다)

조금 찾아보고 확인해 봤는데, 파폭 WebP 지원 계획만 있고 아직 지원 안 하는 것 같습니다.

언제 무슨 버전부터 적용했다는 얘기도 없고, 지금 최신 정식 버전(52.0.1) 쓰고 있는데 https://developers.google.com/speed/webp/gallery2 에서 Here are the links to the WebP files 링크 누르면 다운로드 메뉴가 뜹니다. 크롬에선 잘 뜨고요.

about:config 에서 webp치면 아무것도 안 나오고요. (webm관련 옵션들은 있습니다.)

H.264 vs 265 비교했을때가 생각나는 결과물이군요 (다만 265경우 다른 포맷이라 디코딩에도 더 많은 연산이 필요한게 차이일듯) (이것도 일정 이하의 품질 설정하니 확대(안 하면 괜찮음)했을때 꽤 치명적 수준(컴등에서 볼땐 문제지만, tv방송등에 쓰는 경우는 적합)이었습니다)

웹용 이미지가 죄다 무손실 포맷인 PNG등으로 대체될려면 아직 시간이 좀 더 걸릴듯합니다 (특히 모바일등의 환경에서는 더 걸릴듯) (이미 우리나라처럼 고속 회선 보급율 높은경우는 웬만한 사이트 이미지 죄다 PNG(사진등은 몰라도, 사이트 메뉴 버튼등은 PNG로 만들어도 대용량 안 나오는 분야)로 바꾸어도 될것같기도 함 (통신사땜에 발생하는 IDC의 미친듯한 트래핑 비용만 아니라면))

기술적인 얘기는 많이들 해주셨으니 뭐 덧붙일건 없겠고,

1:1 일치라는 말이 거슬리신거 같은데,

"35%를 줄였다"고 자신있게 말하려면,

그정도는 되어야한다는 뜻입니다.

jpeg가 손실압축인거 모르는건 컴맹말고는 없는데,

설마 몰라서 그런말을 했을까요.

제가 말하고 싶은건

"mp3 블라인드 테스트" 같은 것처럼,

압축률,손실률을 아무리 조정해도 왠만한 사람은 구분도 못하기에 주관적인 부분이 있다는겁니다.

(흔히 말하는 "디지털 풍화" 같은 극악한 화질저하가 없는한...)

이미 나온지 10년,20년은 훨씬 지난 기존 수준에서도 사진자료나 압축률 코덱의 선택에 따라

심지어 같은 jpeg 끼리도 35%는 말은 꺼내기도 우스울정도로 수배 십수 배 차이가 발생하는데,

굳이 애매한(?) 35%라는 말을 꺼낼정도면,

"기존 화소데이터와 1:1일 매칭 되는데 구글만의 독자적인 압축기술로 확 줄였다"는 수준인가 의문이 나올수도 있는거라는 거죠.

(그 1:1이 bmp,png와 비교건, 다른 jpeg 이미지와 비교건.)

이렇게 기사까지 때리면서 광고할 정도라면요.

제목에 "품질저하 없이"라는 말을 쑤셔넣었을 정도면,

bmp와의 비교는 기대 못해도, 기존 동일한 jpeg 데이터와는 1:1 매칭을 기대할 수도 있는거 아닌가요?

많은 최신 압축기술을 무시하겠다는게 아니라,

홍보를 이렇게 때릴거라면,

그에 합당한 독보적인 차이는 있어야한다는거죠.

근데 결론은 그게 없잖아요.

없는 기술로 사기쳤다는 의미가 아니라

소문난 잔치만 벌이고는 그저 그렇다는게 사기라는거죠.(사실 딱히 큰 소문은 안났지만...)

뭐, 구글 홍보팀의 애환(?)정도로 넘어간다면 또 모를까...

근데 기사는 아닌건가요?

분명 다른 곳에서 동일한 내용을 봐서 기사라고 생각했는데, 찾아보니 기사는 안보이는듯...?

원래 어디서 발표한거죠?

제가 보기에 " jpeg 끼리도 35%는 말은 꺼내기도 우스울정도로 수배 십수 배 차이가 발생하는데 "는 사실이 아닌 것 같습니다만...

그렇게 따지면 mozjpeg도 사기입니다.

왜냐하면, libjpeg-turbo 개발자가 한 평가를 보면, 너무 느려서 쓸모없다는 늬앙스인데, libjpeg-turbo 최고속도 대비 15-27% (평균 20%) 압축률이 좋지만, 인코딩이 34-59배 느리다고 합니다. (뱀발: 근데 그  mozjpeg보다 수백배 느린게 Google의 Guetzli인건 함정 ^^;;;;;;;;;;;;;;;;;;;;;; )

최종 결론은 'libjpeg-turbo 프로젝트에 합칠 생각은 없다. 어느쪽이 더 쓸모 있을지는 커뮤니티가 결정할 일이지 내가 결정할 일이 아니다.' 정도로 보이고요.

https://lite.parkoz.com/zboard/view.php?id=express_freeboard2&no=429577

libjpeg-turbo 최고속도 화질 및 압축률 = libjpeg 화질 및 압축률(-turbo는 SSE등 SIMD 명령어로 속도만 높인거라 나머지는 libjpeg랑 동일하다고 합니다)에 비해서 mozjpeg도 최고 27% 밖에 안 된다는 겁니다. libjpeg-turbo 개발자의 평가에 따르면 말이죠.

libjpeg-turbo 개발자의 평가가 의미가 있는 이유는, 애초에 mozjpeg 자체가 libjpeg-turbo를 통째로 펌질해서 만든거기 때문입니다.

(이미 아실 듯 하지만, 오픈소스라 라이센스만 호환되면 통째로 펌질해서 다른거 만들어도 상관없습니다. fork라고 하죠.)

그리고 " 기존 동일한 jpeg 데이터와는 1:1 매칭을 기대할 수도 있는거 아닌가요? " 역시 기술적으로 성립할 수 없는 말입니다. 간단히 GIMP vs mozjpeg를 비교한다고 쳐도 1:1 매칭은 안 나옵니다. 애초에 손실압축인 이상 그런식의 비교자체가 가능할 수가 없습니다.

그래서 모질라의 mozjpeg 개발진들이 PSNR, PSNR-HVS-M, SSIM, MS-SSIM 네 가지 평가 공식을 가지고 심도있게 연구한 거고요. 객관적인 손실이 커도 주관적으로 좋은 화질을 뽑기 위해서 말이죠.

근데 그런 이미지는 jpg가 손실압축해도 png보다 오히려 용량이 커지는 경우가 많아서...^^;; 차라리 pngout 처럼 png에 컴퓨팅을 때려넣어서 최적화하는게 낫지 않을련지...

더구나 tinypng와도 비교해야 될테고요. (웹서버 입장에선 이게 png인지 jpg인지는 중요치 않고, 화질 클레임 없이 적은 대역폭으로 서비스 가능하냐가 중요할 뿐이니깐요.)

제 개인적인 생각엔, libjpeg-turbo 개발자가 mozjpeg에 대해 한 부정적 평가를 고대로 (mozjpeg 대비) 받을 것 같습니다.

In short, while we still have our doubts as to the overall usefulness of mozjpeg, we have upgraded our assessment of the technology from "completely useless" to "possibly useful in some situations." However, the slow performance and narrow scope of usefulness still makes it a non-starter for merger with libjpeg-turbo.

대충 해석하면,

종합적 쓸모에 대한 의구심을 여전히 가지고 있지만 평가를 "완전히 쓸모없음"에서 "일부 상황에서 쓸모 있을 수도 있음"으로 상향함. 하지만 느린 성능과 쓸모 있는 범위가 좁다는 점 때문에 우리 libjpeg-turbo에 합칠일은 없음

테스트를 진행하고 있는데 말씀하신 결과로 귀결되고 있습니다.

참고로 tinypng는 pngquant의 웹 front-end이고, 테스트는 pngquant로 하고 있습니다. ^^