Problem loading large animated GIF images [edited title]

[primoz.rome]

Describe the issue:

Looks like there is a problem serving gif images. Assets URL says “backend error”. See the screenshot while trying to load this asset → https://www.datocms-assets.com/53444/1712829472-accessing-device-view.gif?auto=format&w=1024&dpr=4

None of GIF images is loading in my blog post.

(Optional) Can you provide a link to the item, model, or project in question?

N/A

(Optional) Do you have any sample code you can provide?

I am loading assets via datocmst React package and Image component. I don’t think it’s a problem in the image component, as the above URL doesn’t open directly as well…

[mat_jack1]

hey @primoz.rome if you remove the auto=format it works.

I think in case of an animated GIF it makes sense to remove the parameter, what do you think?

[primoz.rome]

Hmm, that is tricky, I can not dinamically asses on the GraphQL query level if image is gid then remove this parameter.

Plus, the animated gifs used to work, I am using this from the beginning… The question here is, why it should work with auto=format?

Thanks,
Primoz

[mat_jack1]

Are you saying that these animated GIFs were working correctly and then stopped? With the same params?

I see your point and it makes sense to me, I was just checking if you could fix quickly your problem. Meanwhile I’m going to contact Imgix as I think it should work with auto=format.

[primoz.rome]

Yes, I am using same params in Blog Post page since April 2023, and gifs were working … I have just now seen problems with them.

I am testing as we speak without auto=format, will keep you posted.

Just courious. Are GIFs working for you here: DewesoftX 2024.2 Released | Dewesoft ?

[primoz.rome]

UPDATE: works fine on Windows OS (Chrome) and iPhone (Safari). Doesn’t work on my MacBook Air M2 - neither Safari or Chrome.

[mat_jack1]

yes, it works here, I get this image: https://www.datocms-assets.com/53444/1712829472-accessing-device-view.gif?auto=format&w=1024&dpr=2 and works fine

Anyway I’ll be in touch!

[primoz.rome]

Another thing. Here on this page I also have image with same format=auto paramerter, and works nicely…

[mat_jack1]

yes, looks like it’s a timeout problem on that specific file as it’s quite big, I’ll keep you posted

[primoz.rome]

@mat_jack1 just for your reference, the mentioned GIF file (original file in assets) is not that big → 389.76KB. If it helps here is direct link to this asset inside DatoCMS.

[roger]

@mat_jack1 It looks like a problem with animated WebP conversion, maybe?

https://www.datocms-assets.com/53444/1712829472-accessing-device-view.gif?fm=webp&w=1024&dpr=2 works fine. Changing dpr to 3 or higher causes it to time out: https://www.datocms-assets.com/53444/1712829472-accessing-device-view.gif?fm=webp&w=1024&dpr=4

Similarly, fm=auto&dpr=3 also works: https://www.datocms-assets.com/53444/1712829472-accessing-device-view.gif?fm=auto&dpr=3 but 4+ will crash it. Is this on our end or Imgix?

@primoz.rome, for these images, should they ever exceed dpr > 1 ? You’re just enlarging them past their native size at that point, which causes pixelation or upsampling artifacts anyway. Might be better to export them at a higher native resolution and downsample to DPRs < 1 instead?

[primoz.rome]

How can I control the dpr parameter? As far as I see dpr=4 is added automatically as I do not specifically add this to my GraphQL query:

... on ImageBlockRecord {
    id
    width
    image {
      responsiveImage(imgixParams: {auto: format, w: 1024}) {
         ...responsiveImageFragment
      }
    }
 }

[mat_jack1]

Yes, the dpr is the way that we use to manage responsive images, so it’s automatically added.

A couple of ideas for you to try out:

1. can you consider using w: 1280 ? The original GIF looks 1280px wide, this might be enough to prevent the dpr=4 to kick in.

2. you can try using auto: format, compress, it might help reduce the size and avoid the timeout.

From Imgix they say that the problem is the rendering of the GIF with dpr=4 which makes a big image that times out. The compress can help and also avoid the dpr=4 to kick in. Let me know if these two options work for you.

[roger]

@primoz.rome, if you add fit=max, like https://www.datocms-assets.com/53444/1712829472-accessing-device-view.gif?auto=format&dpr=4&fit=max, it should ensure the image is never upscaled past its native resolution (and in the process, help prevent DPR-related timeouts): Responsive Images with srcset | imgix Documentation (And sorry for not suggesting this earlier… I didn’t realize it was us adding the DPRs for you , my bad)

@mat_jack1 This almost seems like a bug on our part to me. I wonder if we should add that to our own image component/default Imgix queries too? DPR makes sense when an image is scaled down from its native size to fit a container, in which case DPR > 1 can improve clarity on retina devices. But when we accidentally use it to scale an image past beyond its native size, at best it will look bad (upscaled), at worst it will cause an Imgix timeout like here. It’s what Imgix suggests in their responsive images tutorial too. I think I’ve seen similar situations with other customers too, but at the time I didn’t realize we were the ones doing the DPR calculations for them. My mistake!

[primoz.rome]

I have added this and it loads Gif’s now…

image {
   responsiveImage(imgixParams: {auto: format, w: 1024, fit: max}) {
      ...responsiveImageFragment
   }
}

Thanks @roger as always for great help!! Appreciated.

[primoz.rome]

@roger I am at the same problem with animated gif timeouts. Usin fit: max seems to work on some gifs, but not on all.

image {
   responsiveImage(imgixParams: {auto: format, w: 1024, fit: max}) {
      ...responsiveImageFragment
   }
}

This image query produces this asset and it timesout:

https://www.datocms-assets.com/53444/1733259443-new-modal-test-improvements-in-measure-mode.gif?auto=format&w=1024&dpr=3

Looks like dpr=3 causes the problem as changing to dpr=1 works.

[roger]

@primoz.rome

Usin fit: max seems to work on some gifs, but not on all.

Do you have an example where that’s still causing a timeout?

e.g. for your image of https://www.datocms-assets.com/53444/1733259443-new-modal-test-improvements-in-measure-mode.gif?auto=format&w=1024&dpr=3, adding &fit=max still seems to work?

https://www.datocms-assets.com/53444/1733259443-new-modal-test-improvements-in-measure-mode.gif?auto=format&w=1024&dpr=3&fit=max

[roger]

Also, might it make more sense to just upload them as videos and serve them that way instead?

[primoz.rome]

You will see the second image in this blog post: https://dewesoft.com/blog/dewesoftx-2024-5-released times out and this is the result

And yeah I could use video instead of Gif, but videos consume so much more bandwidth…

[roger]

Hmm, strange… that loads fine for me:

It may be non-deterministic in a way, like if maybe Imgix is re-rendering it on every edge node and maybe sometimes it times out and sometimes it doesn’t… ugh That would be even harder to troubleshoot. Let me talk to Imgix about this and get back to you.

In the meantime, though, are you sure a video won’t do? By “bandwidth”, are you worried about what the user downloads or what Dato will charge you?

If the filesize is your concern, the video should be smaller, e.g.:
https://www.datocms-assets.com/53444/1733259443-new-modal-test-improvements-in-measure-mode.gif?auto=format is a 2.1MB AVIF for me (this will depend on your browser & OS).

An MP4 generated from your original GIF is only 1.7 MB

(and it looks like it’s dithering a bit; if you record the video straight from the app, it should be even smaller & higher quality with the right settings).

If it’s the pricing you’re worried about, as long as you use Mux to serve it, it should be quite affordable (you don’t get charged bandwidth for it then, just minutes viewed): https://www.datocms.com/docs/streaming-videos/how-to-stream-videos-efficiently