After swapping it out for skia-canvas I'm able to get my node server to generate images in a similar capacity. However the final step of my project includes the step of "deep frying" the image so as to purposefully degrade the visual quality. I do this by running canvas.toDataURL("image/jpeg", 0.01) and serving the result. It seems that this library (as well as https://github.com/Brooooooklyn/canvas library called napi-rs) don't degrade the quality to the extent that the Cairo backed library does. I need to exactly recreate the effect from my current version to prevent a visual rift in the experience of my users and so I'm unable to use this library.
I can understand that I'm probably considered an edge-case and don't blame you if this issue is marked "won't fix", but in terms of creating a high fidelity version of canvas it might be worth your time looking into it. If so I've provided an example of two images, the first one saved with canvas.toDataURL("image/jpeg", 0.01) using the Cairo canvas and the other using Skia for your comparison.
original:
after further investigation it seems that actually this library is generating a file that is in fact very similar to what happens when canvas is used natively in the browser. Below is one version of the image created in the browser:
This seems to solidify this as a "me problem" since I'm now reliant on a very specific output from the cairo canvas which is not actually "correct" in terms of fidelity with canvas in the browser. I will still post this as an issue if nothing else for my own records or so that if anyone is ever looking into the same topic they might find it. Also in case you have read this far and may have any advice on how I might be able to use your library to still achieve this "extra deep fried" look that I've gotten from Cairo (but am unable to use on my current serverless function architecture as linked in the very first issue). I'll be posting a similar issue on the napi-rs repo for the same reason.
Hello, thank you for the repo! I'm hoping to replace my use of https://github.com/Automattic/node-canvas with this repo due to this issue among others.
After swapping it out for
skia-canvas
I'm able to get my node server to generate images in a similar capacity. However the final step of my project includes the step of "deep frying" the image so as to purposefully degrade the visual quality. I do this by runningcanvas.toDataURL("image/jpeg", 0.01)
and serving the result. It seems that this library (as well as https://github.com/Brooooooklyn/canvas library callednapi-rs
) don't degrade the quality to the extent that the Cairo backed library does. I need to exactly recreate the effect from my current version to prevent a visual rift in the experience of my users and so I'm unable to use this library.I can understand that I'm probably considered an edge-case and don't blame you if this issue is marked "won't fix", but in terms of creating a high fidelity version of canvas it might be worth your time looking into it. If so I've provided an example of two images, the first one saved with
canvas.toDataURL("image/jpeg", 0.01)
using the Cairo canvas and the other using Skia for your comparison.original:![test-image](https://user-images.githubusercontent.com/964052/223110344-23790ed5-a449-42d1-8b3d-0c1bfa003398.jpeg)
after further investigation it seems that actually this library is generating a file that is in fact very similar to what happens when canvas is used natively in the browser. Below is one version of the image created in the browser:
This seems to solidify this as a "me problem" since I'm now reliant on a very specific output from the cairo canvas which is not actually "correct" in terms of fidelity with canvas in the browser. I will still post this as an issue if nothing else for my own records or so that if anyone is ever looking into the same topic they might find it. Also in case you have read this far and may have any advice on how I might be able to use your library to still achieve this "extra deep fried" look that I've gotten from Cairo (but am unable to use on my current serverless function architecture as linked in the very first issue). I'll be posting a similar issue on the
napi-rs
repo for the same reason.