Cool! For the avoidance of any doubt when I'm next working on Praxis I'll add an all-permissive header rather than GPL to the RGBMath class, and the RGBComposite as well (not sure if you've taken anything from there too?) Guess by posting here you're happy for your code to be used in any way too. Be good to get some optimal version of all these blend modes in one place - notice you've got some additional optimisations to me in various places, and also some additional modes. I think you're missing Sub, Difference and BitXor from my RGBComposite class? Both Sub and Difference I use a lot - BitXor is a bit of a psychedelic experiment! Somewhere, I've also got code for an equivalent of Ghost from Director (not sure if that has another name elsewhere).

I think the premultiply() code is going to suffer from the same off by 1 error we discussed in previous thread - I guess that multRGB() should use mult(). Because my pipeline is premultiplied I'm only using that code in one specific place and hadn't noticed the issue.

Is there a reason you're passing in source pixels as single values rather than as an array? I assume you're not very often working with only a single pixel.

Cool! For the avoidance of any doubt when I'm next working on Praxis I'll add an all-permissive header rather than GPL to the RGBMath class, and the RGBComposite as well (not sure if you've taken anything from there too?) Guess by posting here you're happy for your code to be used in any way too. Be good to get some optimal version of all these blend modes in one place - notice you've got some additional optimisations to me in various places, and also some additional modes. I think you're missing Sub, Difference and BitXor from my RGBComposite class? Both Sub and Difference I use a lot - BitXor is a bit of a psychedelic experiment! Somewhere, I've also got code for an equivalent of Ghost from Director (not sure if that has another name elsewhere).

I think the premultiply() code is going to suffer from the same off by 1 error we discussed in previous thread - I guess that multRGB() should use mult(). Because my pipeline is premultiplied I'm only using that code in one specific place and hadn't noticed the issue.

Is there a reason you're passing in source pixels as single values rather than as an array? I assume you're not very often working with only a single pixel.

Best wishes, Neil

thanks.

by posting the code here, I'm just saying i'm happy for anyone to do anything they want with the code (as long as your RGBMath class is licensed that way too), just hoping that this might help some people out should they ever need it.

I took some code out of RGBComposite too, but rewrote it to use a single if statement, added a function called blendOneMinus (which doesnt require a sub instruction)

I'll add your Sub, Difference and BitXor to the class if you don't mind.

I pass in source pixels as single values because it seems easier that way, I don't have to write a massive loop around every single function which reads each source pixel, etc.

and if you need to use a source array, it should be easy to add that anyhow. also there are no virtual calls in this class, which removes the overhead of a vtable (hotspot should inline the calls).

I pass in source pixels as single values because it seems easier that way, I don't have to write a massive loop around every single function which reads each source pixel, etc.

and if you need to use a source array, it should be easy to add that anyhow. also there are no virtual calls in this class, which removes the overhead of a vtable (hotspot should inline the calls).

OK. Makes sense. I'm just used to pushing the loop into the composite method because I needed RGBComposite to be an abstract class. I'll port some of your optimisations and other blend modes back to mine, so if people want to work with arrays then that's already there - I'm used to passing in scanlines or whole regions at a time.

I pass in source pixels as single values because it seems easier that way, I don't have to write a massive loop around every single function which reads each source pixel, etc.

and if you need to use a source array, it should be easy to add that anyhow. also there are no virtual calls in this class, which removes the overhead of a vtable (hotspot should inline the calls).

OK. Makes sense. I'm just used to pushing the loop into the composite method because I needed RGBComposite to be an abstract class. I'll port some of your optimisations and other blend modes back to mine, so if people want to work with arrays then that's already there - I'm used to passing in scanlines or whole regions at a time.

go ahead. I just wanted it to modify one pixel at a time because that seemed the most flexible to me. For example, in my project I have to construct a source pixel when blending (for example when mixing brush alpha with brush color: int source = alpha<<24|(color&0x00ffffff) ). I don't want to have to make an array each time I just want to modify a single pixel in a specific location.

Tried a few values at random and does seem to be slightly more accurate, though only 1 away on all that I tried - have you noticed any greater difference?

Personally, it's unlikely I'll use that fix as it's adding 2 extra operations every time it's called - which is going to add up considering this method may be called 8 or more times per pixel. I'm not even sure about adding in the +1 fix we had in the previous thread. But then our use cases are slightly different - I'm working with video so am wanting to process many full frames per second, whereas I can understand accuracy being a greater concern in your application.

Tried a few values at random and does seem to be slightly more accurate, though only 1 away on all that I tried - have you noticed any greater difference?

Personally, it's unlikely I'll use that fix as it's adding 2 extra operations every time it's called - which is going to add up considering this method may be called 8 or more times per pixel. I'm not even sure about adding in the +1 fix we had in the previous thread. But then our use cases are slightly different - I'm working with video so am wanting to process many full frames per second, whereas I can understand accuracy being a greater concern in your application.

yea I was experimenting and happened to come up with that. I noticed an extremely different result - sometimes I used the color 0xffffaa00 with an opacity of 50% and after stroking a couple times, it became red (0xffff0000) which was obviously a major bug for a drawing application.

After switching to this method for mult, it stayed dark yellow instead of changing to red after a certain number of strokes.

yea I was experimenting and happened to come up with that. I noticed an extremely different result - sometimes I used the color 0xffffaa00 with an opacity of 50% and after stroking a couple times, it became red (0xffff0000) which was obviously a major bug for a drawing application.

After switching to this method for mult, it stayed dark yellow instead of changing to red after a certain number of strokes.

- David

I just had a quick test in Praxis as this would be a fairly serious bug for me too, but I can't reproduce this effect using my original code. I assume you're using Normal / SrcOver blend mode for this? I only see this effect (just red) when the opacity goes below 2%, when rounding errors really start to kick in - no way around that while using an integer pipeline. Could it be errors in the premultiply() -> unpremultiply() causing it to round down?

yea I was experimenting and happened to come up with that. I noticed an extremely different result - sometimes I used the color 0xffffaa00 with an opacity of 50% and after stroking a couple times, it became red (0xffff0000) which was obviously a major bug for a drawing application.

After switching to this method for mult, it stayed dark yellow instead of changing to red after a certain number of strokes.

- David

I just had a quick test in Praxis as this would be a fairly serious bug for me too, but I can't reproduce this effect using my original code. I assume you're using Normal / SrcOver blend mode for this? I only see this effect (just red) when the opacity goes below 2%, when rounding errors really start to kick in - no way around that while using an integer pipeline. Could it be errors in the premultiply() -> unpremultiply() causing it to round down?

yeah I am using SrcOver. it also happens when I use premultiplied colors (eg: not calling the premultiply and unpremultiply functions)

yeah I am using SrcOver. it also happens when I use premultiplied colors (eg: not calling the premultiply and unpremultiply functions)

switching to the mult function I posted above fixed it.

Well, the obvious thing is stick with what works for you!

I am interested, though, in why we're getting different results. I wonder what we're doing differently I'll be doing some work on Praxis in a couple of days, so might try plugging in your altered blend function and see if that causes it, but I can't see at the moment why any of your optimisation changes would alter the behaviour. That altered mult() method, while more accurate, is also going to slow things down, and negate the optimisations you've made elsewhere - if something else is the root cause, it seems a shame to change it!

I wondered if it was the premultiply<>unpremultiply because those functions seem to show a slight tendency to drift, but if anything it seems to be upwards not downwards. EDIT - scratch that bit, that's me doing it on a calculator and rounding things up when converting to int.

I am interested, though, in why we're getting different results. I wonder what we're doing differently I'll be doing some work on Praxis in a couple of days, so might try plugging in your altered blend function and see if that causes it, but I can't see at the moment why any of your optimisation changes would alter the behaviour. That altered mult() method, while more accurate, is also going to slow things down, and negate the optimisations you've made elsewhere - if something else is the root cause, it seems a shame to change it!

yeah, I can only try to optimize further now, but in my application accuracy is more important than speed - in yours probably not so much as you need to render frames at a fast rate.If I optimize anything further I'll post it here

I haven't look at adding in any of your changes or additional blend modes yet. Did try various versions of the code you posted with continuously overlaying yellow but can definitely not replicate the drift to red - must be something we're doing differently outside of this code.

Incidentally, as I was posting it in another topic, have you seen the various blend modes from http://filthyrichclients.org/ -> Examples -> Chapter 6. They're for using with Java2D and aren't as optimal as the code we've got between us, but there might be some good pointers to some missing blend modes in there.

I haven't look at adding in any of your changes or additional blend modes yet. Did try various versions of the code you posted with continuously overlaying yellow but can definitely not replicate the drift to red - must be something we're doing differently outside of this code.

Incidentally, as I was posting it in another topic, have you seen the various blend modes from http://filthyrichclients.org/ -> Examples -> Chapter 6. They're for using with Java2D and aren't as optimal as the code we've got between us, but there might be some good pointers to some missing blend modes in there.

Best wishes, Neil

thanks. I noticed the drift to red only happened when I used darkish yellow colors, eg 0xffffaa00, it didnt happen when I used brighter yellows.

Took a look at their blendcomposite class and it seems like their blender would be orders of magnitudes slower than the one we have between us, though I agree it would help us write more blend modes. will write more blend modes when I get some time

thanks. I noticed the drift to red only happened when I used darkish yellow colors, eg 0xffffaa00, it didnt happen when I used brighter yellows.

That's the exact yellow I used as you mentioned it before. Opacities below 2% show errors because they never become yellow at all, but above that constant overlaying converges towards (approximately) the correct colour.

Took a look at their blendcomposite class and it seems like their blender would be orders of magnitudes slower than the one we have between us, though I agree it would help us write more blend modes. will write more blend modes when I get some time

Yes, it is!

Watch out with that as well that they're factoring in the alpha amount separately to the blend function, whereas all ours happen in place, so the equations won't necessarily be correct either!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org