Fix image_loader for animated image types#5688
Conversation
|
Side note: I think an even better way to handle this would be to not treat static webp/gif images as "animated". The webp spec has an "ANIM" chunk at a specific position in the headers if it is animated, which you could use to determine in addition to searching for the RIFF WEBP header. I'd be happy to help out with that if you'd like. Otherwise I thought I'd just bring it to your attention in case you haven't thought about that. |
|
@emilk Do you have any concerns with this approach? Without this, my images don't work with the custom image_loader. |
| // 1. URI extension (only done for files) | ||
| // 2. Mime from `BytesPoll::Ready` | ||
| // 3. image::guess_format (used internally by image::load_from_memory) | ||
| let uri = decode_animated_image_uri(uri).map_or(uri, |(uri, _frame_index)| uri); |
There was a problem hiding this comment.
I don't like it because I feel like the image loader shouldn't need to know about animated images. The culprit is here, but fixing it there would be a much bigger change so I think this fix is fine fow now.
In theory this should break urls like http://example.com/image.png#123, where the loader now would try to load http://example.com/image.png, but I these urls are very rare so this should be fine.
There was a problem hiding this comment.
Right, that's why I pointed out that we shouldn't even be treating the static webp images as animated (in is_animated_image_uri). Would you like me to take a look at fixing that?
There was a problem hiding this comment.
Oops, sorry, I didn't mean that I think this fix should be in is_animated_image_uri. I think it would be around are_animated_image_bytes
There was a problem hiding this comment.
For fixing specifically webp, I would image something like this:
has_gif_magic_header(bytes) || (has_webp_header(bytes) && is_animated_webp_header(bytes))
I haven't looked into the gif spec to see if there is a similar header that we could look at for that.
|
Preview available at https://egui-pr-preview.github.io/pr/5688-master |
|
@lucasmerlin It looks like this PR is missing a label of some sort. I don't think I can add that, can I? |
No, unfortunately not, only maintainers can. We need the labels for proper changelog generation, thats why we have a pipeline for that |
Hi, after upgrading to 0.31.0 all of my beautiful static webp images
started failing to load. I use the image_loader to load those via the
`image` crate.
I noticed that with 0.31.0 there are additions to how animated image
types are handled with frames and such. And with those changes the frame
index is attached to the uri at the end. This was problematic for the
image_loader, because it wasn't updated to handle that frame tag at the
end of the uri, so when looking up the bytes, it would fail to match the
uri in the bytes cache (the bytes were being saved without the frame
index, but attempting to be fetched _with_ the frame index).
This fixes the image_loader for me with webp & gif. They don't load the
animations, but I think that is because I don't have the custom
image_loader set up so I'm not worried about that for myself. I'm not
sure if that part is problematic in general, or if its just the way I
have my features set up.
You can recreate the issue on master by swapping out the dependency
features in the `images` example like this:
```
# egui_extras = { workspace = true, features = ["default", "all_loaders"] }
# env_logger = { version = "0.10", default-features = false, features = [
# "auto-color",
# "humantime",
# ] }
# image = { workspace = true, features = ["jpeg", "png"] }
egui_extras = { workspace = true, features = ["image", "svg"] }
env_logger = { version = "0.10", default-features = false, features = [
"auto-color",
"humantime",
] }
image = { workspace = true, features = ["jpeg", "png", "webp", "gif"] }
```
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: lucasmerlin <[email protected]>
(cherry picked from commit 770c976)
2 participants
Hi, after upgrading to 0.31.0 all of my beautiful static webp images started failing to load. I use the image_loader to load those via the
imagecrate.I noticed that with 0.31.0 there are additions to how animated image types are handled with frames and such. And with those changes the frame index is attached to the uri at the end. This was problematic for the image_loader, because it wasn't updated to handle that frame tag at the end of the uri, so when looking up the bytes, it would fail to match the uri in the bytes cache (the bytes were being saved without the frame index, but attempting to be fetched with the frame index).
This fixes the image_loader for me with webp & gif. They don't load the animations, but I think that is because I don't have the custom image_loader set up so I'm not worried about that for myself. I'm not sure if that part is problematic in general, or if its just the way I have my features set up.
You can recreate the issue on master by swapping out the dependency features in the
imagesexample like this: