여러분, 안녕하세요. GIF를 업로드할 때 100% 크기를 선택해도 왜 이렇게 작게 표시되는지 궁금해서요. 예를 들면
이것은 업로드하려는 특정 항목에 오류가 있는 것처럼 보입니다. 단계별로, 예시를 들어 정확히 설명해 주시겠어요?
해당 문제를 유발하는 GIF 파일입니다. 컴퓨터에서 해당 파일의 속성을 확인해 보면 파일 형식이 'image/gif’로 설정되어 있습니다. 파일 크기는 10.4MB입니다. Discourse가 이미지를 리사이즈하는 것 같습니다. 동일한 방식으로 생성한 더 작은 GIF 파일은 표시 문제 없이 정상적으로 업로드할 수 있습니다.
그러니까 이건 보통 업로드 제한을 초과해서 너무 큰 GIF들이 어떻게 자동으로 리사이즈되는 건가요? 그렇게 생성된 이미지는 아주 작습니다:
50 x 29, 32kb
혹시 @sam 님, 이게 회귀(regression) 문제인가요? 
회귀 버그일 수 있는데, 애니메이션이 없는 GIF에서도 이런 문제가 발생합니까?
고마워요, 여러분 - 저는 http://giffox.com/을 사용해서 GIF를 만들고 있어요.
가끔은 잘 되고, 가끔은 안 되기도 해요… 아마도 크기에 대한 말이 맞을 것 같아요. 방금 테스트를 좀 해봤거든요.
매우 짧은 영상이라면 작동하게 만들 수 있어요.
2.06MB GIF입니다
3.47MB GIF입니다
9.06MB GIF입니다
네, @sam @eviltrout 이 GIF들의 4MB 제한에서 매우 나쁜 일이 일어나는 것 같습니다. 문제를 반영하도록 제목을 수정했습니다. 이 문제를 수정해야 합니다. 회귀(regression)가 발생했으니까요.
애니메이션 GIF에만 해당되는지 확인하려고 합니다.
크기 조절에는 https://www.lcdf.org/gifsicle/을 사용하는 것 같고, 제 추측으로는 파라미터가 변경되었기 때문인 것 같습니다.
@vinothkannans 오늘 한번 빠르게 확인해 주실 수 있나요?
이미지 축소 방식을 변경한 이후로 이 문제가 발생하고 있습니다. 위의 커밋을 적용하면 이 문제가 수정되며, 더 큰 GIF 파일도 올바르게 축소됩니다.
이것이 올바른 수정 방법인가요? 실질적으로 영상인 것을 "다운사이징"하는 것은 적절하지 않다고 생각합니다. 이는 상당히 극단적이고 (아마도 서버 CPU 부하를 크게 유발하는) 조작으로, 영상(GIF) 품질을 망가뜨릴 수 있습니다.
확신할 수 없습니다. 너무 큰 애니메이션 GIF는 강제로 영상 리사이징(더 나아가 mp4로 변환)에 끼워 맞추려 하기보다는 아예 거부해야 한다고 생각합니다. 그것은 별개의 문제로서 별도로 다뤄야 할 문제입니다.
네, 단순한 수정으로 보입니다. 현재 기능을 변경하겠습니다.
그에 대해, 지난 5년간 "gifsicle"을 사용해 GIF 이미지의 크기를 줄여왔고, 이로 인해 성능 문제가 발생하지 않았습니다. @zogstrip 님이 더 자세한 내용을 알고 있을 수 있습니다.
이 경우, 매우 구체적인 GIF를 거부하는 것은 저장소에 더 많은 코드를 추가하게 될 것입니다.
현재는 다음 코드에 따라 모든 GIF를 "애니메이션"으로 간주하고 있습니다:
일부 GIF만 거부하도록 변경하려면 애니메이션 GIF에 대한 형식 감지를 수행한 후, 이를 기반으로 특별한 거부 로직을 구현해야 합니다. 특히 치수(dimension) 문제로 인해 최적화가 필요한 이미지의 경우 더 복잡해집니다. 왜냐하면 더 이상 애니메이션 GIF를 최적화할 수 없게 되기 때문입니다.
장점은 gifsicle 의존성을 제거할 수 있다는 것입니다. 단점은 업로드 파이프라인이 더 복잡해진다는 점입니다.
개인적으로는 @vinothkannans의 수정안이 좋다고 생각하며 위험도 낮습니다. 이 코드는 5년 동안 사용해 왔고, 제가 아는 한 큰 성능 문제는 없기 때문입니다.
다만 @codinghorror, 애니메이션 GIF 리사이징 지원을 제거하고 싶다면 여기서 논쟁을 벌이고 싶지는 않습니다. 하지만 꽤 복잡한 변경 사항입니다. 식별은 비교적 쉽지만, 에러 메시지와 함께 거부를 처리하는 것은 다소 까다로울 수 있습니다.
애니메이션 GIF가 10mb를 초과하여 업로드할 수 없습니다
애니메이션 GIF가 600x400을 초과하여 업로드할 수 없습니다
어쨌든 결정은 당신에게 맡기겠습니다. 제 생각은 수정안을 그대로 두고 넘어가는 것이지만, 지원을 종료하고 싶다면 알려주세요.
참고로, 이 제거 작업은 애니메이션 아바타 지원(선택 기능입니다. 솔직히 이 기능이 있는 것이 매우 마음에 들지는 않습니다)을 제거해야 함을 의미합니다.
음, 그렇다면 애니메이션 GIF가 전체 업로드 크기 한도(?) 안에 들어맞는 한, 실제로는 … “비디오” 품질이 … 무엇에 맞춰 낮아지는 건가요?
여기서 실제로 무슨 일이 일어나고 있는지 정말로 잘 모르겠습니다.
물론 GIF의 경우 높이와 너비를 재조정하는 것은 전혀 적절하지 않은데요… 이것이 위의 원래 버그를 일으킨 원인이었던 건가요?
그동안 이미지 최적화 과정에서 애니메이션 GIF를 "손상"시키는 문제가 있었습니다. 라이트박싱(lightboxing) 대상이 되는 이미지를 업로드하면 이미지가 망가져 버렸죠.
코드 내부에는 GIF가 애니메이션인지 아닌지를 판별하는 “탐지” 로직이 전혀 없었습니다. 라이트박싱은 게시물이 데이터베이스에 커밋된 후에 이루어지기 때문입니다.
해결책은 “리사이즈” 코드를 수정하여 애니메이션 GIF를 손상시키지 않고 올바르게 처리하도록 하는 것이었습니다.
문제는 애니메이션 GIF에 대한 "특별 처리"를 위해 업로드 파이프라인의 일부를 다시 작성해야 한다는 점입니다. 지원 자체를 제거하는 경우에도 마찬가지입니다.
- GIF 업로드
- 애니메이션 GIF인가?
- 전처리(pre-processor)에서 리사이즈가 필요한가?
- 애니메이션 GIF 거부
- 후처리(post processor)에서 최적화가 필요한가?
- 애니메이션 GIF 거부
- 전처리(pre-processor)에서 리사이즈가 필요한가?
- 애니메이션 GIF가 아닌가?
- 일반 파이프라인으로 통과
- 애니메이션 GIF인가?
또한 매개변수가 변경될 경우 마크다운의 장기적인 재처리(rebaking)나 외부 링크 이미지(hotlinked images)를 가져오는 데 따른 부수 효과도 고려해야 합니다.
단순히 리사이즈만 수정했던 이전 해결책은 이러한 복잡한 문제를 걱정할 필요가 없었습니다.
애니메이션 GIF에 대해 "최적화"를 수행하는 것 자체를 하지 않는 것이 좋다고 생각합니다. 따라서 코드가 이를 감지하도록 해야 합니다. 해당 경로를 추가하면 결국 GIF를 MP4 비디오로 변환하는 기능을 구현할 수 있는 문을 열게 되는데, 이는 본래 우리가 원하던 방향입니다. 그래서 이 작업이 필요하다고 생각합니다.
확인 차 말씀드립니다.
아래 내용들을 원하시는 거죠?
- Docker 이미지에서
gifsicle를 제거 - 리사이즈된 애니메이션 GIF가 포함된 기존 게시물을 다시 처리(rebake)할 경우, 게시물에 깨진 이미지 기호가 표시되도록 변경
- 외부에서 링크된 이미지를 가져오는(pull) 작업에서, 리사이즈가 필요한 애니메이션 GIF는 가져오기를 우회하고 대신 링크를 표시하도록 수정
- 크기(해상도 또는 파일 크기)가 너무 크거나 애니메이션인 GIF는 업로드를 거부
- Discourse에서 애니메이션 아바타 지원 기능 제거
- uploads 테이블에서 애니메이션 여부(애니메이션/비애니메이션)를 추적
이 작업에는 약 1~2주 정도의 세심한 작업이 필요합니다. 현재 시스템이 정상적으로 작동하고 있으므로, 이 작업을 우리가 진행해도 되는지 최종 확인 부탁드립니다.
좋아요, 의존성이 적은 것이 더 나은 거 아닌가요?
아마 괜찮을 것 같습니다.
원격 파일 크기만 확인하면 됩니다. 크기가 너무 크면 가져오지 마세요. 그 외에는 신경 쓰지 않습니다.
네, 높이나 너비 차원이 실제로 문제가 되기 훨씬 전에 파일 크기가 문제가 될 것으로 예상됩니다. (싱송으로 Twilight Zone의 "또 다른 차원.. 시간의 차원"을 떠올리며) 또한 이것이 이미지와 비디오를 다르게 취급하는 것이 얼마나 이상한지 설명합니다. 둘은 꽤 다른 존재이니까요!
네, 정신이正常的한 사람은 아무도 이것을 원하지 않습니다.
이 코드 경로가 필요합니다. 왜냐하면 결국 GIF를 MP4로 자동 변환해야 하기 때문입니다. 이는 그 과정의 일부로 우리를 이끌어 주며, 이는 세계 전체에 순이익(net positive)입니다.
gifsicle 의존성을 제거했습니다: