World: r3wp

effect merge is only used when merging DRAW results with the background, 
AFAIK

not sure - there was some change between 2.1 and later View iirc, 
maybe merge was first needed, later it was not, or vice versa ...

ah, now I get it - if there is some effect involved, simply setting 
color to none would not work, it is needed to add merge to effect 
block ... it is well described in view-system doc

hmm, still unable to save out the transparent png file to maintain 
the transparent part in the png file.  I was able to produce an image 
with two coloured boxes and then one box was then made transparent, 
however when saving that image out, the background appears the default 
grey colour that is used when no colour is specified.

I'm missing something key here... can the background colour be made 
transparent?

view lay: layout[
	origin 0
	backdrop 255.0.0
	box green 30x30
	at 15x15 box blue 30x30 effect[merge]
]

save/png %sample.png to-image lay

presents an image with a red background, green box in upper left 
corner and the blue box is transparent in the lower right corner. 
 Save result shows red background image with green box.

adding effect [merge] to the backdrop now makes the backdrop transparent, 
however the save result shows the background in the default grey 
now instead of red.

removing the backdrop line altogether doesn't change the saved result 
from the step above.

adding   lay/color: none  after the definition of the layout block 
changes the saved result to now have a black background with the 
green box appearing inside in the top left corner.

changing the backdrop line to be   backdrop with [color: none]   
again saves out with the default grey background.

I;m not sure if PNG saver supports transparent color

Hm, seems I had different oppinion two years ago :) http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlHSHC

>> i: logo.gif
== make image! [100x24 #{
252525141414141414141414141414141414141414141414141414141414
14141414141414141414141414141414141414141414...
>> i/alpha: 128
== 128
>> save/png %test.png i
>>

Cyphre: This is is alpha channel, I think transparency means key 
color

IMO 'key color' is only alpha = 255 isn't it?

Maybe I don't know what exactly need?

what you exactly need

Ah, you mean the 'key color' in PNG format spec...then I think this 
cannot be controlled using the SAVE function IMO.

rambo it?

it's not a bug, you can say 'missing feature' :)

well, IMHO those also belong in RAMBO..

You need to manipulate tRNS chunk in PNG file. REBOL saves PNG files 
in color type 2 (true color) I think, so you must set tRNS chunk 
to RGB (2 bytes per color) value of color you want transparent. See 
http://www.faqs.org/rfcs/rfc2083.html

yes, you would need the tRNS chunk for that feature.

Out of my league, thanks for the responses.

Brock: or you can make mask image and set the areas you want transparent 
to alpha 255 and REBOL saves aplpha chanel

Rebolek, okay thanks, in theory I understand what needs to occure, 
but have no idea what this would look like in code.

If you are interested in possibly creating a sample, I'd love to 
see it.

Check out help.gif, it has an alpha channel, which survives after 
saving and loading.
	print mold help.gif/alpha
	save/png %image.png help.gif
	view layout [image (load %image.png)]

Now process the image, replacing a particular colour with transparent:
	img: copy help.gif
	colour: pick img 12x12

 repeat i length? img [if colour = pick img i [poke img i 0.0.0.255]]
	view layout [box red at 10x10 image (img)]

but that alpha is only a one bit plane no?

No, 8-bit alpha. Observe:
	img: copy help.gif
	colour: pick img 12x12

 repeat i length? img [if colour = val: pick img i [val/4: mod i 256 
 poke img i val]]
	save/png %image.png img

 view layout [box 300x300 red at 20x20 image (load %image.png) (img/size 
 * 8)]

that's really strange.   its possible that converting from bmp to 
png, RT realised the need to save the potential green mask.  so they 
probably store the image properly inside, but when creating one from 
scratch.. the channel is not.

and this leads me to... how in hell this you stumble accross this? 
 :-)

The image! datatype has an optional alpha channel. If it does not 
exist, it will be created when you set a pixel with alpha.

ok, I read back a bit and I understand more the origin of the discussion. 
 I had assumed brock had an image with an alpha and was not able 
to save it out.  his real question basically... how do I CREATE the 
alpha channel from View gfx.

and you have answered that.

sorry for stickin my head in my ass, I should have read above.

Is there any way to disable the exit button in the upper right corner 
of a window (the button with the X in it) or else reprogram it to 
exit according to my own rebol code?

the window's feel is different and accepts 'close events (in feel/detect).

it not very easy to deal with this because when you call 'view on 
a window, its feel is replaced automatically by view.  so you must 
explicitely replace the feel AFTER calling view on a layout or a 
face.


alternatively, you can also use an input even handler, which is probably 
a better solution:

this is one way to handle the close for all windows: 
   http://www.rebol.com/docs/view-system.html#section-5.13

Anton, great example... I was able to get this to work with a sample 
image that I created.  Thanks so much.

damn anti-aliasing!!  now I have fringing or a halo effect around 
my image due to anti-aliasing.  I'll see what I can do about this. 
 Thanks again.

(I'm trying to create custom rounded bullets)

ajusting gamma in the draw block may help, some artifacts may depend 
specifically on the colour being layered...

My example uses some very contrasting colours.  I'm guessing from 
your statement that you are suggesting making the original image 
background less contrasting and the effect will be minimized.

I'll also play with eh gamma as you suggested as well.

bad colors to mix are green and pink, for example.  the effects are 
usually worse when they are side by side and edges overlap.

a good trick is to set the gamma to one end, do the drawing and then 
compensate gamma back with its complement, to get original colors 
back.

yes, I had a green background, changing to a dark grey (near black) 
works nicely for my purpose, atleast on a larger image.

this is an old trick to fix the flickering stars effect you get when 
you try to move around small dots of white on a screen which has 
aliasing.

(and bg is black)

but there are many possible edge artifacts... and its hard to say, 
what will be the best solution without looking at it directly.

(plus I'm not an AGG expert specifically)