World: r3wp

http://www.4p8.com/eric.brasseur/gamma.html

Thanks for posting that Gabriele. I had no idea.

Yes, quite interesting. Never heard of that.

REBOL produce a green result here, when scaling the test image to 
half size.


view layout [image http://www.4p8.com/eric.brasseur/gamma_dalai_lama_gray.jpg
image http:
//www.4p8.com/eric.brasseur/gamma_dalai_lama_gray.jpg 129x111]

DRAW produces a gray result:


i: load-image http://www.4p8.com/eric.brasseur/gamma_dalai_lama_gray.jpg
view layout [box 200x200 effect [draw [scale 0.5 0.5 image i]]]

Downscaling in View and DRAW that way basically work the same (pure 
nearest neighbor), but it might be that View is sampling odd rows 
and DRAW is sampling even rows.

My view test was in R2.

the gamma issue is a standard "senior artist" debunking test for 
high-end effects artists  hehe


tell the (often ego-filled, highly paid) artist to a simple pan a 
starlit field (a simple sky shot at night).   he will LAUGH and tell 
you that's its an easy thing to do...  and then watch him struggle 
with the results, if he doesn't know his theory.


what happens is that as a pixel is distributed across several pixels, 
it will dim. as the pixel gets closer and closer to a 1:1 position 
with another pixel it will pop right back.


you must pre-amplify the "energy" of the light before panning, and 
then bring it back down... which, depending on the image & screen 
will usually be a value between 1.7 to 2.2.

the final result, when facing a "junior" compositor is that the stars 
blink in and out of existence as the image moves... 


You get this blunder even in High-budget effect-heavy movies coming 
out of hollywood.

the same problem is the basis for poor font aliasing.

AGG has an issue on every aliased stroke, btw.... just look at a 
red circle on blue bg and then a blue bg on red, and you will see 
there is a 1-2 line offset in the circle.  


There is no way to fix this in R2 AGG and I think that part of the 
problem is based on similar gamma assumptions.  also RGB pixels will 
affect left/right edge too, which is probably just amplifying the 
problem.

oops  above should read: "and then a blue circle on red bg"

another thing that people do not often realize is that our eyes are 
also not linear...  you can see each 8 bit step in the dark areas 
of an image, but can skip 5 steps within the brighter areas of an 
image without noticing it.  which is why we always notice image compression 
in very dark parts of DVDs and not in the bright parts of it... 


its very surprising to me that many compression algorythms get this 
wrong straight out of the bat.

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")