When importing a raster image such as PNG, JPG, or similar, we should create a base64 version in order to save it in memory or the file, without relying on the source image location.
We should also find a way to reduce the quality of the image based on the zoom of the canvas in order to speed up the app when dealing with multiple images.
Images are imported but not saved nor converted into any other format.
Related to #326
I have 2 solutions for this problem:
base64 string to store it into the JSON file, to then use onload to generate the pixbuf and recreate the image.Picutres folder in the.akirafile, to then use it to recreate theCanvasImage` file.Both approaches seem to work, and both have pros and cons.
Using the base64 string causes the JSON file to be extremely long and heavy to read if the user has many images, but this approach takes care automatically of removing deleted images on save.
Saving the File allows us to offer previews of imported images, sort of like an internal archive, that the user can reuse. The JSON file stays light by referencing only the file path with a unique ID, but that means I'll need to manually delete those images in case all the objects that were using them are deleted.
Another thing to consider is duplicates (copy/paste) of an imported image.
If I save the actual File, then I can reference that for all the duplicates, and all the CanvasImage object will share that single image, without increasing the file size.
If I use the base64 approach, each CanvasImage will have its own string, increasing the size of the .akira file at every duplicate.
Thinking in a long run, i think we should go with the second option. It is tempting to go with the first option. but take a look at the pros and cons itself
Indeed, I went with the second option as managing images gives us more flexibility to do many more things instead of dealing with a base64 string.
This implementation is almost completed in #334 as I'm now saving the images in the Pictures folder and counting the references of each canvas item using that image, so we're already paving the road to properly handle duplicates without doubling the saved image.
I'll finish this tomorrow by implementing the load of the images form the saved file, and the simple downscaling of the quality of the image if the size decreases, so Akira doesn't have to deal with super heavy images if they're smaller than the original.