Ciao a tutti, mi chiedevo solo perché i GIF siano così piccoli quando li caricate, anche se scegliete il 100% come dimensione, ad esempio:
Sembra che ci sia un errore proprio in ciò che scegli di caricare? Puoi descriverlo esattamente, passo dopo passo, con degli esempi?
Ecco un GIF che innesca il problema. Quando controllo le sue proprietà sul mio computer, il tipo è impostato su ‘image/gif’. La sua dimensione è di 10,4 MB. Sembra che Discourse stia ridimensionando le immagini. Posso caricare GIF più piccole create nello stesso modo senza problemi di visualizzazione.
Quindi si tratta di GIF che normalmente sono troppo grandi per rientrare nel limite di caricamento e vengono ridimensionate automaticamente in qualche modo? L’immagine risultante è minuscola:
50 x 29, 32 kb
Forse si tratta di una regressione, @sam? 
Possibile regressione: succede anche con i GIF non animati?
Grazie ragazzi - sto usando http://giffox.com/ per creare GIF.
A volte funziona e a volte no… Penso che tu possa avere ragione riguardo alle dimensioni. Stavo solo facendo alcuni test
Posso farla funzionare se è molto breve.
Volevo solo confermare che questo è limitato alle GIF animate.
Credo che usiamo Gifsicle: Command-Line Animated GIFs per il ridimensionamento, quindi la mia ipotesi è che i parametri siano cambiati.
@vinothkannans puoi dare un’occhiata veloce oggi?
Questo problema si verifica da quando abbiamo modificato il modo in cui ridimensioniamo le immagini. Il commit sopra menzionato risolverà il problema e i GIF di grandi dimensioni verranno ridimensionati correttamente.
Questa è la correzione giusta? Non credo dovremmo ‘ridimensionare’ ciò che sono effettivamente dei video. Sembra una manipolazione piuttosto estrema (e potenzialmente molto pesante per la CPU del server), che potrebbe rovinare la qualità del video (GIF).
Non sono sicuro al riguardo. Penso che dovremmo semplicemente rifiutare i GIF animati troppo grandi invece di costringerci a occuparci del ridimensionamento dei video (o, ancora meglio, della conversione in MP4), che è un altro problema da affrontare.
Sì, sembra una soluzione semplice. Modificherò la funzionalità attuale.
Comunque, sembra che stiamo ridimensionando le immagini GIF negli ultimi 5 anni utilizzando “gifsicle” e non abbiamo ricevuto problemi di prestazioni. @zogstrip potrebbe conoscere più dettagli.
Credo che in questo caso, rifiutare GIF molto specifiche aggiungerà più codice al nostro repository.
Al momento assumiamo semplicemente che tutte le GIF siano “animate” come da:
Se decidiamo di cambiare le cose in modo che alcune GIF vengano rifiutate, dovremo implementare il rilevamento del formato per le GIF animate e poi scrivere un codice speciale per il rifiuto. Questo è particolarmente complicato per le immagini che dobbiamo ottimizzare (a causa delle dimensioni), perché non saremo più in grado di ottimizzare le GIF animate.
D’altro canto, potremo eliminare la dipendenza da gifsicle. D’altro canto, la nostra pipeline di upload diventa più complessa.
Personalmente, penso che la correzione di @vinothkannans vada bene e sia a basso rischio; è codice che abbiamo già da 5 anni e, per quanto ne so, non ci sono gravi problemi di prestazioni.
Detto questo, @codinghorror, non mi immergerei in questa discussione se volessi eliminare il supporto per il ridimensionamento delle GIF animate, ma si tratta di una modifica piuttosto complessa: l’identificazione è abbastanza semplice, ma gestire il rifiuto con un messaggio di errore potrebbe essere un po’ complicato.
La tua GIF animata è più grande di 10 MB, quindi non può essere caricata
La tua GIF animata è più grande di 600x400, quindi non può essere caricata
Comunque, la decisione è tua. Il mio suggerimento è di lasciare la correzione così com’è e andare avanti, ma se vuoi eliminare il supporto, faccelo sapere.
Nota: questa rimozione richiederà anche di eliminare il supporto per gli avatar animati (una funzionalità opzionale; onestamente, non sono molto contento di doverlo fare).
Hmm, quindi finché il GIF animato rientra nel limite totale di caricamento (??), di fatto la sua qualità “video” viene ridotta per adattarsi… a cosa?
Non sono per nulla chiaro su cosa stia effettivamente succedendo qui.
È ovvio che ridimensionare altezza e larghezza sia del tutto inappropriato per un GIF… è proprio questo che ha causato il bug originale sopra?
La situazione era che, durante l’ottimizzazione, “distruggevamo” i GIF animati: se caricavi immagini destinate alla visualizzazione in lightbox, le rovinavamo.
Il codice interno non disponeva di alcuna logica di “rilevamento” per capire se un GIF fosse animato o meno. La visualizzazione in lightbox avviene dopo che il post è stato salvato nel database.
La soluzione è stata modificare il nostro codice di “ridimensionamento” in modo che non rovinasse più i GIF animati e funzionasse correttamente con essi.
Il problema è che, se decidessimo di rimuovere il supporto, dovremmo ridisegnare ampie parti della nostra pipeline di caricamento per prevedere una “gestione speciale” dei GIF animati:
- Un GIF viene caricato
- È un GIF animato?
- Il pre-processore dovrà ridimensionarlo?
- Rifiuta il GIF animato
- Il post-processore dovrà ottimizzarlo?
- Rifiuta il GIF animato
- Il pre-processore dovrà ridimensionarlo?
- Non è un GIF animato?
- Lascialo passare attraverso la pipeline normale
- È un GIF animato?
Bisogna inoltre considerare alcuni effetti collaterali legati alla ricreazione a lungo termine del markup se i parametri dovessero cambiare in futuro e al recupero di immagini hotlinked.
La soluzione semplice, ovvero correggere solo il ridimensionamento, ci ha permesso di non dover preoccuparci di tutto questo.
Non penso dovremmo affatto eseguire “ottimizzazioni” sui GIF animati, quindi credo che il codice debba rilevarlo. Aggiungere questo percorso aprirebbe la strada a una futura conversione da GIF a video MP4, cosa che vogliamo comunque… prima o poi. Quindi ritengo che questo lavoro sia necessario.
Solo per chiarire.
Vorreste che noi:
- Rimuovessimo
gifsicledalla nostra immagine Docker - Quando ricreate i vecchi post che contenevano GIF animate ridimensionate, queste dovessero apparire con l’icona dell’immagine rotta nel post
- Correggessimo il nostro task di recupero delle immagini hotlinkate, in modo da evitare di scaricare le GIF animate che richiedono un ridimensionamento, mostrando invece un link
- Rifiutassimo le GIF animate che sono troppo grandi (per dimensioni o peso) e che sono animate
- Rimuovessimo il supporto per le avatar animate da Discourse
- Tenessimo traccia della differenza tra animato e non animato nella tabella degli upload.
Stimiamo circa 1-2 settimane di lavoro dettagliato qui; stiamo solo confermando che desiderate che procediamo, soprattutto dato che al momento tutto funziona correttamente.
Certamente, meno dipendenze sono meglio, no?
Probabilmente va bene
Controlla semplicemente la dimensione remota del file. Se è troppo grande, non scaricarlo. Non mi importa altrimenti.
Sì, principalmente il peso del file sarà il problema, molto prima che le dimensioni di altezza e larghezza diventino rilevanti. (In tono canzonatorio, come in “Altra dimensione… la dimensione del teempppo”) È anche per questo che è così assurdo trattare un’immagine come un video. Sono creature piuttosto diverse!
Sì, nessuno sano di mente lo desidera.
Abbiamo bisogno di questo percorso di codice perché dovremmo alla fine convertire automaticamente le GIF in MP4 comunque. Questo ci porta a metà strada e rappresenta un guadagno netto per il mondo.
Ho rimosso la dipendenza da gifsicle in: