Dx4
Jr. Member  Posts: 73 Medals: 5
|
 |
«
on:
2011-07-23 05:32:35 » |
|
this class allows you to add new blendmodes to java. included are: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| public static enum Mode {
Normal,
Add,
Multiply,
Erase,
Average,
Overlay,
Screen,
Glow,
Reflect,
Red,
Green,
Blue,
ColorDodge,
ColorBurn,a
HardLight,
} |
supports both premultiplied and unpremultiplied colors. mult and blend functions taken from praxis ( http://code.google.com/p/praxis/source/browse/ripl/src/net/neilcsmith/ripl/rgbmath/RGBMath.java) reference: http://www.pegtop.net/delphi/articles/blendmodes/intro.htmexample: 1
2
3
4
5
| int [] destination = .. int source = 0x80ff0000; int offset = 0x20; int extraAlpha = 100; blendPixelPremultiplied(destination, offset, source, extraAlpha, Mode.Multiply); |
the above code blends the pixel in offset 0x20 with the color red, with 50% opacity, adding 100 extra alpha while blending, using the multiply blendmode. |
|
|
|
|
nsigma
Sr. Member Posts: 342 Medals: 18
|
|
«
Reply #1 on:
2011-07-23 07:05:47 » |
|
Hi,
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
|
|
|
|
Dx4
Jr. Member Posts: 73 Medals: 5
|
|
«
Reply #2 on:
2011-07-23 07:29:24 » |
|
Hi,
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). - David |
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
nsigma
Sr. Member Posts: 342 Medals: 18
|
|
«
Reply #3 on:
2011-07-23 07:49:02 » |
|
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. |
|
|
|
Dx4
Jr. Member Posts: 73 Medals: 5
|
|
«
Reply #4 on:
2011-07-23 08:03:35 » |
|
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. |
|
|
|
|
Dx4
Jr. Member Posts: 73 Medals: 5
|
|
«
Reply #5 on:
2011-07-23 09:43:44 » |
|
this seems to be a more accurate alternative to your mult(): 1
2
3
4
| public static int mult(int a, int b) {
int t = a * b + 128;
return (t >> 8) + t >> 8;
} |
|
|
|
|
|
nsigma
Sr. Member Posts: 342 Medals: 18
|
|
«
Reply #6 on:
2011-07-23 13:02:58 » |
|
this seems to be a more accurate alternative to your mult(): 1
2
3
4
| public static int mult(int a, int b) {
int t = a * b + 128;
return (t >> 8) + t >> 8;
} |
Interesting. Is that yours or from a particular source? 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. |
|
|
|
Dx4
Jr. Member Posts: 73 Medals: 5
|
|
«
Reply #7 on:
2011-07-23 13:30:39 » |
|
this seems to be a more accurate alternative to your mult(): 1
2
3
4
| public static int mult(int a, int b) {
int t = a * b + 128;
return (t >> 8) + t >> 8;
} |
Interesting. Is that yours or from a particular source? 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. - David |
|
|
|
|
nsigma
Sr. Member Posts: 342 Medals: 18
|
|
«
Reply #8 on:
2011-07-24 07:23:32 » |
|
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? |
|
|
|
Dx4
Jr. Member Posts: 73 Medals: 5
|
|
«
Reply #9 on:
2011-07-24 08:08:32 » |
|
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) switching to the mult function I posted above fixed it. |
|
|
|
|
Games published by our own members! Go get 'em!
|
|
nsigma
Sr. Member Posts: 342 Medals: 18
|
|
«
Reply #10 on:
2011-07-24 11:46:53 » |
|
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.  |
|
|
|
Dx4
Jr. Member Posts: 73 Medals: 5
|
|
«
Reply #11 on:
2011-07-24 23:11:25 » |
|
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  - David |
|
|
|
|
|
|
Dx4
Jr. Member Posts: 73 Medals: 5
|
|
«
Reply #13 on:
2011-07-25 08:00:47 » |
|
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 - David |
|
|
|
|
nsigma
Sr. Member Posts: 342 Medals: 18
|
|
«
Reply #14 on:
2011-07-25 11:52:06 » |
|
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! |
|
|
|
|
