Hello !
Playing with background {alpha -1} to have a transparent background, I found that the "Save Image..." output is not quite what's expected.
Below is the exported image, to which I added a white background to reveal the defects, and no other overdub. And below again in a screenshot of ContextFree.
What gives ?
(BTW, did I say the new features are awesome ?)
alpha background
Moderators: MtnViewJohn, chris, mtnviewmark
The code :
Code: Select all
startshape forest
background { alpha -1 }
// forest
rule forest 4.5 { forest { s 0.8 } }
rule forest { forest { s 1.25 } }
rule forest 0.5 {
forest { x 1 y 0.03 }
forest { x -1 } }
rule forest 0.5 {
forest { x 1 y -0.03 }
forest { x -1 } }
rule forest 0.03 {
forest { x 1 }
forest { x -1 }
seed { } }
// trees
rule seed { tree { y 0.5 r 85 sat 1 hue 50 |hue 90 sat 0.5 b 0.3 } }
rule seed { tree { y 0.5 flip 180 r 95 sat 0.5 hue 50 |hue 100 sat 0.2 b 0.3 } }
rule tree {
trunc { }
tree { x 1 r 1 s 0.95 b 0.01 hue 0.03| sat 0.01 } }
rule tree 0.3 {
tree { flip 180 }
tree { r -20 y -0.1 s 0.7 b -0.5 hue -0.01| sat 0.1 } }
rule tree 0.05 { tree { b -0.5 sat 0.8 } }
// trunc
rule trunc 2 {
SQUARE { s 1 0.2 b -0.4 sat -0.5 }
SQUARE { s 1.1 0.1 b 0.8 sat -0.2 } }
rule trunc {
SQUARE { s 1 0.2 b -0.5 sat -0.5 }
SQUARE { x -0.25 s 0.5 0.1 b 0.8 sat -0.5 }
SQUARE { x 0.25 s 0.5 0.1 b 0.9 } }
rule trunc {
SQUARE { s 1 0.2 b -0.5 sat -0.5 }
SQUARE { x -0.25 s 0.5 0.1 b 0.9 }
SQUARE { x 0.25 s 0.5 0.1 b 0.8 sat -0.5 } }
// mistletoe
rule tree 0.05 {
CIRCLE { hue 80 sat -0.5 b 0.5}
tree { } }
There is at least one nasty thing which prevents transparent background to work well : the antialiasing of a black shape produces opaque pixels of different shades of grey, instead of black pixels of different alphas.
Now, I don't know if this is as a bug, or a feature request !
And I'm not sure this would be enough to explain the odd rendering of the forest above.
Now, I don't know if this is as a bug, or a feature request !
And I'm not sure this would be enough to explain the odd rendering of the forest above.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
I tried this with the Windoze client exporting to Fireworks and the image with the alpha background was almost pixel-for-pixel identical to the image with the background line commented out. I think that the AGG renderer function does use alpha the way that you suggest. This looks like an issue with the Mac OS image saving code. Mark is out of town for a week, no access to a computer. You will either have to wait for him to get back and fix it or hold your nose and use a Windows machine (did I mention that I work for Intel, the other evil empire?)
At first, as I said, I thought antialiasing produced opaque pixels. I was wrong.MtnViewJohn wrote:I tried this with the Windoze client exporting to Fireworks and the image with the alpha background was almost pixel-for-pixel identical to the image with the background line commented out. I think that the AGG renderer function does use alpha the way that you suggest. This looks like an issue with the Mac OS image saving code.
But after playing a while, I still can't put my finger on a precise bug.
For data's sake, and information persistence, here is another output (bad), and below the screenshot (right) for this code :
Code: Select all
startshape scene
background { alpha -1 }
rule scene {
SQUARE [ r 15 s 1 0.01 ]
SQUARE [ y 0.02 r 15 s 1 0.01 a -0.5 ]
SQUARE [ y 0.04 r 15 s 1 0.01 a -0.75 ]
SQUARE [ y 0.06 r 15 s 1 0.01 a -0.75 b 1 sat 1 ]
SQUARE [ y 0.08 r 15 s 1 0.01 a -0.5 b 1 sat 1 ]
SQUARE [ y 0.1 r 15 s 1 0.01 b 1 sat 1 ]
}
In the zoom, we see that antialiasing produces transparent pixels, but not of the right color :
A zoom in the forest reveals similar spurious white pixels :
[EDIT]
Even in B/W strange things occurs... Makes me think of 8 bits instead of many more... Top is screenshort, bottom in the exported picture, very pixelated (from this code :
[/EDIT]
Windozezezezee ???MtnViewJohn wrote:Mark is out of town for a week, no access to a computer. You will either have to wait for him to get back and fix it or hold your nose and use a Windows machine (did I mention that I work for Intel, the other evil empire?)
OK, no nagging... trolling is bad ! In two years, I'll have my first Intel box, anyway, and so does Mark (who is crying, alone on a lonely rainy beach, bent over pictures of himself, young, buying his first PowerMac, bou hou houhouhou...)
I can wait for him. Or dig myself in the code, as only macs are affected. Kind of a game, too !
-
- Posts: 1
- Joined: Sun Feb 05, 2006 11:37 am
- Contact:
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
We have determined that there is a bug in the Mac client that is probably causing this behavior. The problem is that we didn't realize that RGBA bitmaps on Macs want the RGB components to be pre-multiplied with the alpha component. We will fix this in the next release, when we come out with a universal binary.