명품몰 상품 이미지 수천 장의 썸네일 변환이 느려서 설정 튜닝을 검토했다가 개선 폭이 작을 것으로 보고 접었다. 그때 튜닝할 것이 없다고 단정했다.
Table of contents
Open Table of contents
원인 — 무의미하다고 단정한 근거
그 단정에는 확인하지 않은 부분이 있었다. convert 호출을 optimize_jpeg() 셸 함수 한 줄로 쓰고 있었고 그 안을 열어 보지 않았다.
한 줄로 보이는 설정이 실제로는 -strip·-interlace Plane·-define jpeg:optimize-coding·-define jpeg:dct-method·-sampling-factor 다섯 옵션의 조합이었다. 튜닝할 것이 없다는 결론은 그 조합을 안 본 상태에서 나온 것이었다.
측정 — 한 줄 안의 다섯 옵션
두 가지 방법이 있었다. 프리셋을 통째로 다른 조합으로 바꿔 전후만 비교하는 것과, 다섯 개를 하나씩 켜고 끄면서 측정하는 것이다. 뒤쪽을 골랐다. 이유는 통째로 바꾸면 어느 옵션이 움직였는지 모르기 때문이다. 대신 측정 조합이 다섯 배로 늘어나는 것을 감수했다. 잰 것은 인코딩 시간과 출력 크기와 compare -metric SSIM 화질 지표 셋이었다.
시간만 재면 화질이 떨어져도 알 수 없다. 무손실이라고 말하려면 화질을 함께 재야 하므로 세 축을 같이 잡았다.
무손실 이득과 대체 관계
-interlace Plane 을 끄니 SSIM 이 그대로인데 인코딩 시간이 크게 줄고 파일 크기는 거의 안 늘었다. ImageMagick 공식 문서대로 이 옵션은 프로그레시브 JPEG 을 만드는 것이라 화질과는 무관했다.
비슷한 결과를 내는 것으로 보였던 dct-method 는 함께 재 보니 이득이 더해지지 않았다. 하나만 끄면 됐다.
판단 기준 — 용도가 적용 여부를 정한다
optimize-coding=false 는 시간이 줄지만 파일이 눈에 띄게 커져서 전송 비용이 늘어나는 맞바꿈이었다. 남은 -strip 과 -sampling-factor 는 바꿔도 개선이 없거나 나빠져서 기본값이 이미 최적이었다.
프리셋은 일반적인 균형을 잡는데 우리 상황의 균형과 다를 수 있다. 여기서는 대상이 작은 썸네일이라 프로그레시브 로딩이 체감에 영향을 안 주므로 같은 옵션이라도 큰 상세 이미지를 다루는 곳과 판단이 달라졌다.
시간과 크기와 품질
결과적으로 다섯 중 -interlace Plane 하나만 빼는 것으로 정리됐다. 기록에는 앞서 튜닝할 것이 없다고 한 단정을 지우지 않고 왜 틀렸는지를 함께 적었다.
지우면 왜 그렇게 생각했는지가 사라지고 같은 실수를 다시 하게 된다. 한 줄로 보이는 설정 안에 무엇이 있는지 보지 않았다는 것이 그 교훈이었다.
정리
optimize_jpeg()한 줄이 여러 옵션의 조합일 수 있다- 내부를 안 보고 튜닝할 것이 없다고 단정하지 않는다
- 옵션을 개별로 분해해 측정한다
- 시간과 크기와
SSIM을 함께 재야 무손실이라고 말할 수 있다 - 화질 손실 없이 얻는 이득이 있을 수 있다
- 두 옵션의 이득이 더해지지 않으면 하나만 바꾼다
optimize-coding처럼 맞바꿈인 것은 다른 비용과 함께 본다- 프리셋의 균형과 우리 용도의 균형은 다를 수 있다