Hi!
so finally I decided to do not try to blend the colors in the CairoColor
space. Since a the end, any correction that I can write to make the blend
functions work with CairoColors correctly, pass through to convert the
unsigned int values to float, then do the blend and then come it back to
unsigned char, I decided to do it before the blend operation. See my latest
commits on that.
It works fine for both Halftone2 and Halftone3.
In fact, any layer that doesn't use directly the Cairo API can act like
that. For example, the Blur layer can blend into the context result by
doing that kind of blending but I prefer to use the native Cairo blending
when possible. These two layers Halftone2 and 3 could be changed to use the
Cairo blending operations to the context surface when possible in a second
stage of coding. If the Cairo native blending operations are faster, of
course.
Also, those two layers has shown to me how to proceed in case that the
synfig's blending method were not supported with any combination of Cairo
operators. I just need to render to another surface and blend them together
using the synfig's blending methods.
Finally the fact that the blending functions aren't useful only for float
colors I think that I can rewrite the CairoColor::blend method to use the
float versions with the proper demultiply, convert to Color, blend, convert
back to CairoColor and premultiply. That's what I'm doing in the halftone
layers.
In terms of performance, the current Cairo render for Haltone2 and 3 is
(surprisingly) slightly faster than the software method. Images are
basically the same so it has not interest on show them.
I'm working on Shade layer now ;-).
Cheers!
2012/9/20 Carlos López González <genet...@gmail.com>
> Hi!
> all the blending functions that I proudly ported to a template to be used
> on Color as well as CairoColor are wrong! ^___^''
> The won't work for CairoColors!
> First, the alpha value used for scale up the rest of channels has to be a
> float betwen 1.0 and 0.0 and so it needs to be scaled down by the color
> channel range.
> Second the blending operations are needed to be done in a float space and
> only convert the final value to the type of the channel because if we keep
> converting to the color channel type in the middle of the operations we
> will get precision loose.
>
> So hands on work!
>
> Cheers!
>
>
> 2012/9/18 Carlos López González <genet...@gmail.com>
>
>> Hi!
>> I've been working to be able to render gaussian blurs using Cairo
>> surfaces.
>> I needed to do some changes as you can see in the commits list. It seems
>> to work but for some reason the alpha is washed out. It is like if the
>> alpha value were not accumulated properly... Still don't know the reason. :(
>> Time for gaussian blur is far larger in Cairo render than in Software
>> that makes it unusable.
>> For that type of layers that doesn't have similar API in Cairo I'm
>> considering to directly convert the CairoSurface to Surface, do the
>> operations and then convert back to CairoSurface.
>> Possibly it is not so slow than now.
>> So far that's my last commit with Blur layer.
>> Cheers!
>>
>> 2012/9/17 Carlos López González <genet...@gmail.com>
>>
>>> Hi!
>>> After the Warp layer bug hiatus I'm back on the Cairo render road. ^__^
>>> I've been working on implement the Blur layer. Very interesting! This is
>>> the summary of changes:
>>>
>>> 1) I've needed to add a new member function to the etl::surface:
>>>
>>> void etl::surface::copy(const etl::surface &rhs);
>>>
>>> to allow to copy one surface to other when both are already with the
>>> data memory allocated. This would prevent to allocate memory for the
>>> receiving surface (as the operator=() does) and so it can be used to copy
>>> one surface to other when it is CairoSurface type.
>>>
>>> 2) CairoColor has an unsigned char value per channel. This makes
>>> CairoColor unusable for accumulate values of colors like in a pixel
>>> subsampling or a blur filter. I've created a CairoColorAccumulator class
>>> that is simply a float color with interface to convert from and to
>>> CairoColor. From now on, all the etl::surfaces and etl::generic_pen and
>>> derivatives must use CairoColorAccumulator as Accumulator type when a
>>> CairoSurface is needed. It is needed for the blur operations. Possibly it
>>> would improve some other subsamplig areas.
>>>
>>> 3) I've added Cairo render support for the Blur layer. The gaussian blur
>>> doesn't work yet because it needs some changes on the etl::gaussian*
>>> templates. Currently gaussians templates expect to receive pointers to the
>>> value_type of the etl::generic_pen class for further calculations on each
>>> gaussian blur template. It is perfect for Color class but not for
>>> CairoColor due to its value range limitation. Instead of expect a pointer
>>> to the value_type, it should expect a pointer to the accumulator_type, that
>>> is not typedefined yet. It will be my next commits.
>>>
>>> For the performance results, in general, Cairo render is slower than
>>> Software (as expected), basically because the calculations are the same
>>> plus the needed operations to convert between CairoColorAccumulator and
>>> CairoColor. Only Boxblur looks to be slightly faster in Cairo. Results are
>>> very good in any case.
>>>
>>> One thing that I particularly liked from this coding session is that
>>> I've learned a lot of how the blurs operations are performed. This would
>>> allow me to implement in the future a new blur type that would use variable
>>> size on each pixel and so it could be possible to emulate differential blur
>>> in one scene.
>>>
>>> Well, that's all for today!
>>>
>>> Cheers!
>>>
>>> --
>>> Carlos
>>> http://synfig.org
>>>
>>>
>>
>>
>> --
>> Carlos
>> http://synfig.org
>>
>>
>
>
> --
> Carlos
> http://synfig.org
>
>
--
Carlos
http://synfig.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Synfig-devl mailing list
Synfig-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl
