Roseate has a little bit of an issue. The pipeline from when we get a path to an image all the way to actually displaying the image on the GUI is quite messy and restricts us heavily.

This is the Roseate Load An Image Pipeline simplified:

1. We have an image path.
2. We get some quick image details, like image dimensions and the image format.
3. We now enter image loading time. 😱
4. But before we actually load the image we got to determine if the image requires modifications or not, if it doesn't then we don't need to decode the image into an rgba pixel array. If it does then fuck.. we do. This step is necessary because reading the file and loading its bytes into memory will always be faster than image crate decoding then having to encode it again.
5. If we have image modifications we need to do, we manipulate the image with the image create or we manipulate the pixel array directly if the user has picked the multi-threaded Roseate backend.
6. We encode the image back to bytes with image crate.
7. Now we have the bytes, we just pass it to egui and let it do its thing.

What's the issue with this?

You might be confused and asking that question now. There's not much of an issue with this solution for common images apart from potentially wasting cpu time encoding twice #57 until... you use some of the more... unique image formats... like GIFS AND SVGS!!!!!

It's a problem because now we are relying on image crate's encoding and decoding methods to support these unique formats and more unique or obscure formats to come.

If there's something that isn't supported by the image crate or isn't well supported / blended in we'll have to divert from the normal pipeline into an alternative one just for those specific file formats. You see this will start to become really messy really fast.

So this is something we'll need to look into together with the #57 issue.