World: r3wp

also don't forget that light is additive,  so sometimes, all you 
need to do, in visual effects, is add up an immense number of very 
dark particles.  where they are tightly packed, it will create a 
ball of white, by iteself.

the different hues, will build themselves up based on the falloff 
your particles are spreading out at.

the same probably applies wrt the way the color spreads out over 
the time it cools down and/or the distance from a single hot point.

if your base color is some kind of darkish brown, it will glow from 
brown to orange to yellow to white.  the bluish tint usually comes 
from the surface which "blues" because its exposed to heat.  not 
all metals "blue".  some melt before getting that hot.

Wow - you guys. This is very interesting, but, going too far for 
my purpose at the moment. I *really* like the idea of having the 
simplest, most robust code possible. Adding so many visual effects 
and detail is something for a computer game.

I'm mostly concerned with communicating as simply and directly as 
possible to the user the current overall progress of some operation 
(multiple file download is first application).

(I appreciate all the technical details very much, however.)

This site is good for color picks http://www.colourlovers.com/

nice one, Oldes.

Yes, cool.

Interesting stats in the lower right corner of the page... About 
Colourlovers.  An idea of what we could have for the AltME stats 
on Rebol.org as suggested in another group.

*That*'s the kind of website I was after, thanks Oldes.

anyone know if/where I can find an implemented shortest path algorythm 
in rebol?  I know I can do my own... but if one exists and available, 
I'd rather use it  :-)

Maxim,
do http://cyphre.mysteria.cz/a-star.r


that is my very old script I used for prototyping when developing 
strategy games couple of years ago. It's not optimized as it is just 
prototype before conversion to Java but it kinda works ;)

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.