I finally figured out what went wrong with the resizing of images in my fork.
Currently, the resizing process doesn't handle large (many frames) animated gifs well when it also includes jpg as an output format. Each frame of the gif is vertically stacked into the jpg output, making it too large to handle.
Temporary solution: For now, I've limited the output types to only use webp to avoid the unnecessary stacked jpg output. The sharpOptions include animated to enable animated webp output, and I've set the limitInputPixels to be 100x larger than the default option, but this really depends on the size & length of the gif animations.
Suggested solutions:
- Don't use
jpg output at all for animated file types, even when this is included in the output formats.
- Use conditional output formats per input file type: still image ->
['webp', 'jpg'], animated image -> ['webp', 'gif']
I hope this provides enough context for you. Perhaps the solution needs to be somewhere upstream instead of this template.
I finally figured out what went wrong with the resizing of images in my fork.
Currently, the resizing process doesn't handle large (many frames) animated gifs well when it also includes
jpgas an output format. Each frame of the gif is vertically stacked into the jpg output, making it too large to handle.Temporary solution: For now, I've limited the output types to only use
webpto avoid the unnecessary stacked jpg output. ThesharpOptionsincludeanimatedto enable animated webp output, and I've set thelimitInputPixelsto be 100x larger than the default option, but this really depends on the size & length of the gif animations.Suggested solutions:
jpgoutput at all for animated file types, even when this is included in the output formats.['webp', 'jpg'], animated image ->['webp', 'gif']I hope this provides enough context for you. Perhaps the solution needs to be somewhere upstream instead of this template.