E aí, pessoal, só queria saber por que os GIFs ficam tão pequenos quando vocês os carregam — mesmo que escolham 100% como tamanho, por exemplo:
Isso parece ser um erro especificamente no que você está escolhendo fazer ao enviar? Você pode descrevê-lo exatamente, passo a passo, com exemplos?
Aqui está um GIF que desencadeia o problema. Quando verifico suas propriedades no meu computador, o tipo está definido como ‘image/gif’. O tamanho é de 10,4 MB. Parece que o Discourse está redimensionando as imagens. Consigo fazer upload de GIFs menores que criei da mesma forma, sem nenhum problema de exibição.
Então, isso é sobre GIFs que normalmente são grandes demais para caber no limite de upload, certo? Eles estão sendo redimensionados automaticamente de alguma forma? A imagem resultante está minúscula:
50 x 29, 32 kb
Talvez isso seja uma regressão, @sam? 
Possivelmente uma regressão. Isso acontece também com GIFs não animados?
Obrigado, pessoal — estou usando o http://giffox.com/ para criar gifs.
Às vezes funciona e às vezes não… Acho que vocês podem estar certos sobre o tamanho. Estava apenas fazendo alguns testes.
Consegue funcionar se for muito curto.
Aqui está um GIF de 2,06 MB
Aqui está um GIF de 3,47 MB
Aqui está um GIF de 9,06 MB
Parece que algo muito ruim está acontecendo no limite de 4 MB para esses arquivos @sam @eviltrout. Editei o título para refletir o problema. Precisamos corrigir isso, regredimos.
Só queria confirmar se isso está isolado aos GIFs animados.
Acho que usamos Gifsicle: Command-Line Animated GIFs para redimensionar, então minha suposição é que os parâmetros mudaram.
@vinothkannans, você pode dar uma olhada rápida hoje?
Isso está acontecendo desde que mudamos a forma de redução de imagem. O commit acima corrigirá esse problema e os GIFs maiores serão redimensionados corretamente.
Essa é a correção adequada? Não acho que devamos “reduzir” o que são, na prática, vídeos. Isso parece uma manipulação bastante extrema (e possivelmente muito intensa para a CPU do servidor) que poderia prejudicar a qualidade do vídeo (GIF).
Não tenho certeza sobre isso. Acredito que devemos simplesmente rejeitar GIFs animados que sejam muito grandes, em vez de nos forçarmos a entrar no negócio de redimensionamento de vídeos (ou, ainda melhor, converter para MP4), o que é um problema completamente diferente a ser enfrentado.
Sim, parece uma correção direta. Vou alterar a funcionalidade atual.
De qualquer forma, parece que estamos redimensionando as imagens GIF nos últimos 5 anos usando “gifsicle” e não recebemos nenhum problema de desempenho relacionado a isso. @zogstrip pode ter mais detalhes.
Acho que, neste caso, rejeitar GIFs muito específicos vai adicionar mais código ao nosso repositório.
No momento, assumimos que todos os GIFs são “animados”, conforme:
Se vamos mudar para que alguns GIFs sejam rejeitados, teremos que implementar detecção de formato para GIFs animados e, em seguida, acionar um código especial de rejeição. Isso é especialmente complicado para imagens que precisamos otimizar (devido às dimensões), pois não poderemos mais otimizar GIFs animados.
No lado positivo, podemos nos livrar da dependência do gifsicle. No lado negativo, nosso pipeline de upload fica mais complexo.
Pessoalmente, acho que a correção do @vinothkannan é boa e de baixo risco. É um código que temos há 5 anos e não conheço grandes problemas de desempenho.
Dito isso, @codinghorror, eu não me envolveria nessa discussão se você quiser eliminar o suporte ao redimensionamento de GIFs animados, mas é uma mudança bastante complexa. A identificação é simples o suficiente, mas implementar a rejeição com uma mensagem de erro pode ser um pouco complicado.
Seu GIF animado é maior que 10 MB, então não pode ser enviado.
Seu GIF animado é maior que 600x400, então não pode ser enviado.
De qualquer forma, a decisão é sua. Minha sugestão é deixar a correção como está e seguir em frente, mas se quiser eliminar o suporte, nos avise.
Observação: essa remoção também exigirá que removamos o suporte a avatares animados (um recurso opcional; para ser honesto, não estou muito feliz em ter que fazer isso).
Hmm, então, desde que o GIF animado caiba no limite total de upload (??), ele efetivamente tem sua “qualidade de vídeo” reduzida para combinar com… o quê?
Estou super confuso sobre o que está realmente acontecendo aqui.
Obviamente, redimensionar a altura e a largura é totalmente inadequado para um GIF… foi isso que levou ao bug original acima?
O histórico era que estávamos “destruindo” GIFs animados ao otimizá-los; assim, se você carregasse imagens que seriam exibidas em lightbox, nós as estragávamos.
Nosso código interno não tinha lógica de “detecção” para identificar se um GIF era animado ou não. A exibição em lightbox ocorre após a postagem ser salva no banco de dados.
A correção foi fazer com que nosso código de “redimensionamento” não estragasse os GIFs animados e funcionasse corretamente com eles.
O problema é que precisaríamos refazer partes do nosso pipeline de upload para dar “tratamento especial” aos GIFs animados caso decidíssemos remover o suporte.
- Um GIF é carregado
- É um GIF animado?
- O pré-processador precisará redimensioná-lo?
- rejeitar o GIF animado
- O pós-processador precisará otimizá-lo?
- rejeitar o GIF animado
- O pré-processador precisará redimensioná-lo?
- Não é um GIF animado?
- permitir que passe pelo pipeline normal
- É um GIF animado?
Também existem alguns efeitos colaterais a considerar com a recriação de longo prazo do Markdown caso os parâmetros mudem no futuro e ao buscar imagens vinculadas externamente.
A solução de simplesmente corrigir o redimensionamento significou que não precisávamos nos preocupar com tudo isso.
Acho que não devemos fazer “otimização” em GIFs animados de forma alguma, então acredito que o código precise detectar isso. Adicionar esse caminho abriria a porta para uma eventual conversão de GIF para vídeo MP4, que queremos de qualquer forma… eventualmente. Então, sinto que esse é um trabalho necessário.
Só para esclarecer.
Você gostaria que nós:
- Removêssemos o
gifsicleda nossa imagem Docker - Ao reprocessar posts antigos que continham GIFs animados redimensionados, eles aparecessem com o ícone de imagem quebrada no post
- Corrigíssemos nossa tarefa de baixar imagens hotlinked, para evitar baixar GIFs animados que exigem redimensionamento, exibindo um link em seu lugar
- Rejeitássemos GIFs animados que sejam muito grandes (em dimensão ou tamanho) e sejam animados
- Removêssemos o suporte a avatares animados do Discourse
- Mantivéssemos o registro de GIFs animados versus não animados na tabela de uploads.
Estamos prevendo cerca de 1 a 2 semanas de trabalho detalhado aqui. Apenas confirmando se você deseja que assumamos essa tarefa, especialmente considerando que tudo está funcionando corretamente no momento.
Claro, menos dependências é melhor, não é?
Provavelmente OK
Basta verificar o tamanho remoto do arquivo. Se for muito grande, não baixe. Caso contrário, não me importo.
Sim, principalmente o tamanho do arquivo será um problema, muito antes de as dimensões de altura e largura realmente importarem. (No estilo cantado de “Outra dimensão… a dimensão do tempppp” de O Crepúsculo do Além) Isso também explica por que é tão estranho tratar uma imagem como um vídeo. São animais bastante diferentes!
Sim, ninguém sensato quer isso.
Precisamos desse caminho de código porque, eventualmente, devemos converter GIFs automaticamente para MP4s de qualquer forma. Isso nos leva parcialmente nessa direção e é um ganho líquido para o mundo.
Removi a dependência do gifsicle em: