World: r3wp

Well, there isn't any excuse for us to get it wrong in R3 now. :-)

Max, I tried to compare the circles example as you described and 
I don't see any offset here. Can you clarify?
Also you can set the gamma correction for AGG antialiasing in R2.

But yes, it looks the AGG filters(which are separated from the AA 
code) have the same gamma issue as described in the article. I believe 
we can fix that (hope it won't slow down things).

Is the situation wrt the range of intensity really as described in 
the article? I seem to recall that the receptors for the three colors 
in the retina are not all equal in terms of sensitivity. In particular, 
the eye is supposedly more sensitive to green. Why the assumption 
that the three colors should have the same exponential scale?

the scale is the same, because its a question of energy distribution 
vs color distribution, but our green sensitivity is about 4 times 
higher than red or blue.

in traditional TV signals, the green color you see actually is the 
luminance of the signal, so if you separate the green red and blue 
and look only at the green, you will see exactly the same image as 
a BW tv.

red and blue are calculated as differences from the luminance and 
are how the color is added to images.   These other two channels 
of color information will in fact take a fraction of the signal bandwith 
that the luminance takes, and the green is calculated by the different 
both red and blue have from the luminance channel.


which is why the SAME signal is used for both color and black and 
white TVs

digital signals work differently.. i'm not sure if they still use 
YCrBr  (luminace, red diff, blue diff) concepts in their encoding.

cyphre... use this as a basis:


view layout [box 200x200 effect [
    draw [
        push [
            translate 119x119 
            pen none 
            fill-pen black 
            box -50x-30 50x50 
            fill-pen blue 
            pen red 
            line-width 3 
            circle 50x50 25 
            fill-pen red 
            pen blue 
            circle -50x50 25 
            fill-pen blue 
            pen red 
            circle -50x-30 25 
            fill-pen red 
            pen blue 
            circle 50x-30 25
        ]
    ]
]]


adding new black, red, blue, black, circles in betwen colors may 
give very poor results.  sometimes 1 pixel width lines practically 
disapear horizontally!


playing around with the line width will also have a different visual 
impact, since the aliasing will spread the error more or less.


as I said, i know part of the issue is related to the screen's rgb 
sub-pixel channel components but I remember trying some of this in 
other softwares and the effects weren't as image degrading.


to me the main defect is that you will notice a WHITE ringing effect 
between the red and blue on one side and a black ring on the other.


I can understand the black ring, but can't explain the white one, 
which is why I think it coule be related to gamma issues.


also, the black ring seems to be wider than it should &  the effect 
seems the most apparent at ODD line widths, which is a bit strange 
too...


I'm wondering if AGG has an algorithm which is trying to compensate 
for pixel to pixel color defects and gets it wrong.  


maybe it could be enhanced to support subpixel aliasing (or gets 
it wrong if it already does so).

Max, I'm sorry I don't see any degrading 'ringing effect' when looking 
at your example. Even while looking at scaled screenshot the AA of 
the edges of circles looks perfectly symetric to me(did horizontal 
flip comparisons). I'm using average LCD display and also my eyes 
are getting older every day so I still might missing something.

AFAIK AGG is not using any 'compensation' code. It simply computes 
the covers of every pixel cell using 256 levels and ofcourse uses 
subpixel AA(try to translate by fractions of pixel..). So the AA 
result is still very high-quality(though there are very few special 
cases limitations of the used alogrithm). If you compare it to current 
FSAA abilities of gfx cards 256 levels is still way more than what 
the current  super/multisampling offers.

I'm not sure it this is the best group, but anyway, does anybody 
already has a script which would take block of images as an input 
and will layer these images into specified area (a new image). Possibly 
using as less space as possible.

If there is no such a script, I will write it. But better to ask 
first not to duplicate work.

Maybe studying the problem first could be helpful: http://www.ijcai.org/papers09/Papers/IJCAI09-092.pdf

or: http://www.csc.liv.ac.uk/~epa/surveyhtml.html

At least I now how to name the problem now: 2-D Rectangle packing 
:)

Sounds like a generic optimization problem with constraints. If you 
are unlucky this is a NP complexity problem.

Like the travelling salesmand.

Here it is:
http://box.lebeda.ws/~hmm/rebol/rectangle-pack.r
with my real life result example:
http://box.lebeda.ws/~hmm/rebol/rectangle-pack-result.jpg
Maybe it's not perfect, but it does what I need.

I've never seen anything like that before, cool.

This gfx art really amazes me :-)

Very cool Oldes!

yes nice.

Looks cool, and seem to be good result with the rectangle packing. 
I would like to see a PNG version without the artifacts though. :-)

Remembers me on the old C64 days, where graphic chars were packed 
in a bitmap.

cool stuff Oldes!

Here is related script which I use to crop images according it's 
alpha channel:
>> do http://box.lebeda.ws/~hmm/rebol/get-img-alpha-bounds.r

>> get-img-alpha-bounds load http://box.lebeda.ws/~hmm/rebol/alpha-image.png
== [53 6 99 121]

Can anybody help me?
I have original image:

img1: make image! [5x1 #{AA0000AA0000AA0000AA0000AA0000} #{003F7FD8FF}]

which Flash IDE internaly stores as:

img2: make image! [5x1 #{A900007E0000540000190000000000} #{003E7ED8FF}]


I need to get the original from the flash version but have no info 
what flash does... any idea? I only know, that Flash is able to export 
the original from it's modified version.

the above can be also visualised as:
>> repeat i 5 [print [i img1/:i tab img2/:i]]
1 170.0.0.0      169.0.0.0
2 170.0.0.63     126.0.0.62
3 170.0.0.127    84.0.0.126
4 170.0.0.216    25.0.0.216
5 170.0.0.255    0.0.0.255

hm.. it's not exactly the same, but I can get the Flash version for 
red component as:

 repeat i 5 [c: img1/:i print to-integer   c/1 * (255 - c/4) / 255]

you could try looking visually at a few gradient tests just to understand 
what is happening, you might find a pattern.

That's what I was doing here:) Anyway.. the above is enough for me. 
It's not exactly same, but I cannot see difference when I see the 
image just by eye, because mainly almost invisible pixels are affected.

ah its premultiplying your pixels  !

it looks like premultiplication indeed.

ie, when you are compositing "img" over "bg", you basically do:  
bg * (1 - img_alpha) + img * img_alpha

they are precomputing img * img_alpha (a common tecnique) so that 
they can then simply do:  bg * (1 - img_alpha) + img

here is a simple function to swap channels from any image in R2

channel-copy: func [
	raster [image!]
	from [word!]
	to [word!]
	/into d
	/local pixel i b p 
][	
	b: to-binary raster
	
	d: to-binary any [d raster]
	
	from: switch from [
		red r [3]
		green g [2]
		blue b [1]
		alpha a [4]
	]

	to: switch to [
		red r [3]
		green g [2]
		blue b [1]
		alpha a [4]
	]

	either (xor from to) > 4 [

  ; when going to/from alpha we need to switch the value (rebol uses 
  transparency not opacity)
		repeat i to-integer (length? raster)  [
			p: i - 1 * 4
			poke d p + to to-char (255 - pick b p + from)
		]
	][
		repeat i to-integer (length? raster)  [
			p: i - 1 * 4
			poke d p + to to-char pick b p + from
		]
	]
	d: to-image d
	d/size: raster/size
	d
]

an example usage


circle: draw 100x100 [pen black fill-pen red circle 50x50 30]
circle/alpha: 0

alpha: draw 100x100 [pen white fill-pen white circle 50x50 30]
alpha/alpha: 0


line: draw 100x100 [
	pen blue
	fill-pen blue 
	line-width 5
	line 10x50 90x50
]

f: make face [
	offset: 100x100 
	color: gray
	pane: make face [
		color: none  
		image: line  
		text: "close for next"
		font: make font [color: white ]
	]
]

view f
f/pane/text: none

result: channel-copy/into line 'blue 'green circle
result: channel-copy/into alpha 'blue 'alpha result

f/pane/image: result



view f

note, images have to be same sizes if using /into refinement

also note that the function returns a new image (it doesn't modify 
"in-place")

btw, the swap code is not related to Olde's last question, even if 
it is loosely related... its a gift function for anyone who needs 
to copy channels (usually manipulating alphas)

Does anybody have done or begin a Box2d port in rebol ?

Is there something similar to this atan2 function in rebol (I guess 
no) :

http://msdn.microsoft.com/en-en/library/system.math.atan2%28v=vs.95%29.aspx

you have ARCTANGENT in rebol, atan2 should be easy to define based 
on it

I made ATAN2 while ago, I try to find it.

can't find it right now, but it was based on http://en.wikipedia.org/wiki/Atan2

Found 2 versions in my scripts.
atan2: func [

 {Angle of the vector (0,0)-(x,y) with artangent y / x. The resulting 
 angle is extended to -pi,+pi}
	x y
][
	if x = 0 [x: 0.0000000001]
	add arctangent y / x pick [0 180] x > 0
]

atan2: func [x y][
	x: x + 0.00000001
	either x > 0 [
		arctangent y / x
	][
		180 + arctangent y / x
	]
]

How many zeros after the decimal point?

does that matter ?

I mean, you can round the result

I don't know, that's why it seemed worth asking. Don't know the reason 
for that line. If it is supposed to be close to 0 then 15 or 16 zeros 
would be the closest.

Found another one:
atan2: func [x y][
	x: x + 0.00000001
	x: either x > 0 [arctangent y / x][180 + arctangent y / x]
	360 + x // 360
]
Geez... How many time I rewrote that one ? 
:-)

the last one is weird...