World: r3wp

I don't think I mentioned what I wanted the colours for - a progress 
bar. After consideration, I've pretty much decided that a large range 
of colours such as cooling metal might go through might actually 
be bad for the user interface (unless extreme measures are taken 
to make it really look like molten metal, like a computer game programmer 
might do), because all those colours might be confusing, and some 
of them (eg. red) may signal warning, etc. (especially if the user 
hasn't seen the progress bar before - I don't want to present the 
user with a circus of colours). Fading from white to solid blue is 
what I'm using at the moment, and I'm thinking white might be too 
bright.

May I suggest that:


- Starting with just cold metal - metal is not a single colour.  
You are seeing many colours at all times, and different patches of 
colour everywhere.  You are seeing colours reflected and you need 
a coefficient table to calculate the reflection index.  Copper for 
example would lean heavily towards red.


- Next, heated metals are the same, meaning, not a single colour 
either, but now for a different reason.  But to produce the illusion 
of something burning hotter and hotter will require something that 
is multi-pass, and changing constantly.


In video games to produce the afterburner on a jet we did a few tricks:


- The jet flame itself was made of a cone-like shape (maybe a dozen 
polygons).

- The cone was set with an alpha channel so that the source was close 
to opaque, and the tip was close to translucent.

- A second cone was placed around the first cone, but just slightly 
larger.

- They both undulated at all times.  In other words, the length was 
always changing for both cones independently just slight.  And when 
the jet went faster and slower, they changed from long to flat (with 
the plane itself).

- The textures on the polygons were already a rainbox of colours, 
but as the jet changed what it was doing, the colour pallet was changed. 
 Again, both cones were not always changed at the exact same time.

- Just behind the jet (but depending on your angle of view), several 
filters (polygons that read the bg info and render again) would be 
used to create a small waiver and a refocusing.  The more GPU you 
had, the more of this you could do, and the better the final effect 
would look.

- Lastly, and this is what makes the whole thing amazing in a 3D 
game.  We are always checking the location of bright things, such 
as the sun, or things like the after burner filling your screen. 
 If so, we change the contrast of the whole world, and flare out 
your iris.  In the case of the sun we throw up a lens flare, and 
darken all the ships in the sky.

Even as a 2D problem, you should attach this the same way.

This video I think drives this all home for you.

http://www.youtube.com/watch?v=mHL94qQgl_8&feature=related

This photo drives this point perfectly


http://www.richard-seaman.com/Aircraft/AirShows/Nellis2006/Extras/BelgianF16Afterburner.jpg


See how the jets are making the left wing blurry...this is what makes 
it look hot more than even seeing the jet itself.  That just tells 
you the source, not that it is so hot it messes up the air.

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!