Привет, ребята! Меня интересует, почему GIF-файлы такие маленькие при загрузке, даже если вы выбираете размер 100%, например:
Похоже, ошибка возникает именно в том, что вы выбираете для загрузки? Можете ли вы описать её точно, шаг за шагом, с примерами?
Вот gif-файл, который вызывает проблему. При просмотре его свойств на моём компьютере тип файла указан как ‘image/gif’. Его размер составляет 10,4 МБ. Похоже, что Discourse изменяет размер изображений. Я могу загружать более маленькие gif-файлы, созданные тем же способом, без каких-либо проблем с отображением.
Итак, речь идет о GIF-файлах, которые обычно слишком велики для ограничения на загрузку. Они каким-то образом автоматически изменяют размер? Получившееся изображение очень маленькое:
50 x 29, 32 КБ
Возможно, это регрессия, @sam? 
Возможно, это регрессия. Происходит ли это также с неанимированными GIF?
Спасибо, ребята — я использую http://giffox.com/ для создания гифок.
Иногда получается, а иногда нет… Думаю, вы правы насчёт размера. Просто проводил тесты.
Можно заставить работать, если файл очень короткий.
Вот GIF размером 2,06 МБ
Вот GIF размером 3,47 МБ
Вот GIF размером 9,06 МБ
Да, похоже, что при пределе в 4 МБ происходит что-то очень плохое @sam @eviltrout. Я изменил заголовок, чтобы отразить проблему. Нам нужно это исправить, мы откатились назад.
Просто хотел подтвердить, что проблема изолирована только на анимированных GIF.
Я думаю, мы используем Gifsicle: Command-Line Animated GIFs для изменения размера, поэтому, по моему предположению, параметры изменились.
@vinothkannans, не могли бы вы сегодня быстро взглянуть?
Это происходит с тех пор, как мы изменили способ уменьшения изображений. Указанный выше коммит исправит эту проблему, и большие GIF-файлы будут корректно масштабироваться.
Это правильное исправление? Мне кажется, не стоит «уменьшать размер» того, что по сути является видео. Это кажется довольно радикальным (и, возможно, очень ресурсоемким для процессора сервера) действием, которое может испортить качество видео (GIF).Я не уверен в этом. Думаю, мы должны outright отклонять слишком большие анимированные GIF-файлы, вместо того чтобы втискивать себя в задачу изменения размера видео (или, что еще лучше, конвертации в MP4) — это совершенно другая проблема, которую нужно решать.
Да, похоже, что это простое решение. Я изменю текущую функциональность.
В любом случае, похоже, что мы уже 5 лет изменяем размер GIF-изображений с помощью “gifsicle”, и у нас не было никаких проблем с производительностью. @zogstrip может знать больше деталей.
Думаю, в данном случае отклонение очень специфичных GIF-файлов приведёт к увеличению объёма кода в нашем репозитории.
На данный момент мы просто считаем все GIF-файлы «анимированными», согласно:
Если мы решим изменить логику так, чтобы отклонялись некоторые GIF-файлы, нам придётся реализовать детектирование формата для анимированных GIF-изображений, а затем добавить специальный код для их отклонения. Это особенно сложно для изображений, которые нужно оптимизировать (из-за размеров), поскольку мы больше не сможем оптимизировать анимированные GIF-файлы.
С одной стороны, мы сможем избавиться от зависимости от gifsicle. С другой — конвейер загрузки станет сложнее.
Лично я считаю, что исправление от @vinothkannan вполне приемлемо и несёт низкие риски: это код, который у нас уже пять лет, и, насколько мне известно, серьёзных проблем с производительностью нет.
Тем не менее, @codinghorror, если вы хотите полностью отказаться от поддержки изменения размера анимированных GIF-файлов, не стоит ввязываться в эту борьбу здесь. Это довольно сложное изменение: определение формата анимированных GIF-файлов несложно, но реализовать отклонение с соответствующим сообщением об ошибке может оказаться непросто.
Ваш анимированный GIF-файл больше 10 МБ, поэтому его нельзя загрузить.
Ваш анимированный GIF-файл больше 600×400 пикселей, поэтому его нельзя загрузить.
В любом случае, решение за вами. Моя рекомендация — оставить исправление как есть и двигаться дальше, но если вы хотите полностью отказаться от этой поддержки, дайте нам знать.
Обратите внимание, что это удаление также потребует отказаться от поддержки анимированных аватаров (это опциональная функция; честно говоря, мне не очень нравится, что мы вынуждены от неё отказаться).
Хм, так что пока анимированный GIF помещается в общий лимит размера загрузки (??), его фактическое «видео» качество снижается, чтобы соответствовать… чему?
Мне совершенно непонятно, что на самом деле происходит.
Очевидно, что изменение высоты и ширины для GIF совершенно не подходит… именно это и привело к описанной выше ошибке?
История заключалась в том, что при оптимизации мы «разрушали» анимированные GIF-файлы: если вы загружали изображения, предназначенные для лайтбокса, мы их портили.
Внутренняя логика нашего кода не имела механизма «обнаружения», чтобы определить, является ли GIF анимированным или нет. Лайтбокс открывается после того, как пост сохраняется в базе данных.
Решение заключалось в том, чтобы наш код «изменения размера» перестал портить анимированные GIF-файлы и корректно работал с ними.
Проблема в том, что нам нужно переработать значительные части нашего конвейера загрузки, чтобы обеспечить «специальную обработку» анимированных GIF-файлов, если мы отказываемся от их поддержки.
- GIF загружается.
- Является ли он анимированным?
- Нужно ли препроцессору изменить его размер?
- отклонить анимированный GIF.
- Нужно ли постпроцессору оптимизировать его?
- отклонить анимированный GIF.
- Нужно ли препроцессору изменить его размер?
- Является ли он неанимированным?
- пропустить через обычный конвейер.
- Является ли он анимированным?
Также следует учесть побочные эффекты при долгосрочном повторном рендеринге разметки Markdown, если параметры когда-либо изменятся, а также при подгрузке изображений по прямым ссылкам.
Простое исправление изменения размера означало, что нам не пришлось беспокоиться обо всём этом.
Мне кажется, нам вообще не следует заниматься «оптимизацией» анимированных GIF, поэтому код должен это обнаруживать. Добавление такого пути откроет возможность для последующего преобразования GIF в видео MP4, что в любом случае является нашей целью в будущем. Поэтому я считаю эту работу необходимой.
Только для уточнения.
Вы хотите, чтобы мы:
- Удалили
gifsicleиз нашего Docker-образа. - При пересоздании старых постов, содержащих изменённые по размеру анимированные GIF, они отображались бы как битая иконка изображения.
- Исправили задачу по извлечению внешних изображений, чтобы она пропускала анимированные GIF, требующие изменения размера, и вместо этого отображала ссылку.
- Отклоняла анимированные GIF, которые либо слишком большие (по размерам или объёму), либо являются анимированными.
- Убрали поддержку анимированных аватаров в Discourse.
- Хранили информацию об анимированности/неанимированности в таблице загрузок.
Мы оцениваем эту работу примерно в 1–2 недели кропотливой работы. Просто хотим подтвердить, что вы действительно хотите, чтобы мы взялись за это, особенно учитывая, что всё сейчас работает корректно.
Конечно, меньше зависимостей — это лучше, не так ли?
Вполне допустимо
Просто проверьте размер удалённого файла. Если он слишком большой, не загружайте его. В остальном мне всё равно.
Да, в основном проблема будет в размере файла, что проявится гораздо раньше, чем станут важными высота и ширина. (В песенном стиле «Тайной зоны»: «ещё одно измерение… измерение врррремени».) Именно поэтому так странно воспринимать изображение как видео. Это совершенно разные сущности!
Да, никто в здравом уме этого не хочет.
Нам нужен этот участок кода, потому что в конечном итоге мы всё равно должны автоматически конвертировать GIF в MP4. Это приближает нас к этой цели и является плюсом для всего мира.
Я устранил зависимость от gifsicle в: