Closed Reptorian1125 closed 4 months ago
Hello @Reptorian1125 ,
I have two things to say about this:
premula
and ipremula
which do the job of converting from RGBA to premultiplied RGBA (and the reverse). Just put a resize
between and it should do the job.That's being said, of course, you can have fun figuring out how to add native things to CImg/G'MIC if you like, even make your own forks of CImg/G'MIC, which is very instructive. But there's almost no chance of this kind of functionality being integrated into the official CImg/G'MIC packages, especially if you can do the same thing with a custom G'MIC command.
One of my next attempt at touching CImg,h is implementing alpha-aware resize. That's doable in G'MIC, but the code to do that is resize using average interpolation, split the alpha from color, scale alpha from 0-255 to 0-1, divide color by alpha, re-scale the alpha, append them together. That could be a command without having to do this, but I wanted to do a new command via CImg.h and editing gmic.cpp(?) just to trim some time off (See commentary below) and I'd like that to complete my Mosaic refactor. I can't say I'm satisfied with the execution time via my own G'MIC implementation yet, and I'm thinking it can be noticeably faster.
So, my goal is to have a built-in command which isn't a new function that enables all of that at once.
At the moment, I am studying lines close to this:
Just so that I can understand it and then make my own implementation.
The plan is to first loop over all of the alpha-channel. Find the weighing factor. And then the color is calculated by multiplying the color by weighing factor of alpha multiplied by alpha. Then insert the result in the resized image. I do wonder if it'll be faster to have a C++ code that stores positions, and amount of alpha value, then use those to find the new value of color which was the main reason I was thinking to touch Cimg.h.
You can see a bit of math here.