Topic: SaLiVA - new format

[James]

Getting it to work requires development.

That imposes a choice.

James. 

[Fanny Pack]

Anyway, until you decide what you want to achieve it is pointless to start building anything.  So, back to the list.

[James]

That's partly true, but I had no idea that I would work my way toward so many neat features in LaserBoy until I had built a bridge through thin air to get there.

Working with just the tiniest bits of information can tell you a lot about what "it" wants to become.

LaserBoy talks to me all the time! He tells me what to do next and how to do it!

James. 

[Fanny Pack]

Well I don't want to spend time Forrest Gumping my way through this.

[James]

You have such a way with words.

How would you go about it?

Would you design the whole spec first and then code it?

In what?

What if you can figure out how to implement your own ideas?

James. 

[BlinkenLights]

no.. figure out what we want to achieve.. figure out how we plan to achieve that logically then start coding. he said that already.

i would like a file that can store some sort of instructions for movement over time.. maybe..

[Fanny Pack]

Right.  First step is to figure out what we intend to do.  I assume we are talking about a next generation ILDA type format that can be shared between different applications?   So, what are the limitations/problems of the ILDA format?  Here is just what is at the top of my head.
(1) Too many different formats.  One format that does it all would be better.
(2) No way of adding data such as description, required projector colors, author info, etc.  Actually there are about 16 bytes that can currently be used but they aren't enough to be useful.
(3) It might be better to not specify every point and instead use something like beziers or shapes.  Software could be used to create the path points based on speed, scan angle, etc.  This prevents having to add optimization data to the image description.

That's a start.

[BlinkenLights]

i hate the fact that with an ilda file i cant change colors without adding a scan point.
i get why its like that, but if i want to draw a straight line and i want a linear fade from cyan to magenta, thats all the information i should have to give it. let the software figure out what to do with it.

[James]

That's a neat idea.

We should always keep in mind that we are planning on creating information that will be shown on a laser projector, and keep reality in the mix.

Meaning:

Your idea is good because it takes less information to describe something and it could easily be rendered on-the-fly.

And if it is calculated, there is less of a chance of incorrect data.

But, we also need to think about how long a projected line would need to be in order to even see the effect that you want. Remember, this is still going to be clocked out as discreet points. If you want to draw a nice line from hear to there, it will take some number of points.

Also in a 24-bit rgb color system, there are only so-many colors between any two.

James. 

[BlinkenLights]

but what if i make "from here to there" bigger as in, i do it at 96k or 120kpps (in the future) i want there to be a perfect fade.

[James]

That's all part of the question!

BTW If you really wanted to, you could start with 8 bits each for RGB colors and derive 15 bits of variation (16-bit signed short int) out of that with a color blend. Then you DAC out each of the RGB values as a 16-bit number.

Hmmmmmmm I wonder what format that would be?  :

That's the nice thing about an ASCII solution. We can use text numbers with arbitrary precision. We don't need to worry about atomic data types.... just yet.

James. 

[BlinkenLights]

agreed.. and its also nice to be able to go in a tweak a text file or parse it with a global add and replace to change something

[Fanny Pack]

That's a neat idea.

We should always keep in mind that we are planning on creating information that will be shown on a laser projector, and keep reality in the mix.

Meaning:

Your idea is good because it takes less information to describe something and it could easily be rendered on-the-fly.

And if it is calculated, there is less of a chance of incorrect data.

But, we also need to think about how long a projected line would need to be in order to even see the effect that you want. Remember, this is still going to be clocked out as discreet points. If you want to draw a nice line from hear to there, it will take some number of points.

Also in a 24-bit rgb color system, there are only so-many colors between any two.

James. 

It isn't necessarily going to be clocked out as discreet points.  In your implementation it might but in someone elses future design their "smart" scanner may be fully capable of knowing a start point and color and end point and color and linearly modulating the lasers so that they provide a gradient color change over the step.  This is why you need to stop thinking about how you can do it and start thinking of what you want to do.  Otherwise, you will always be designing for past technology.

[James]

I guess this is yet another variation on the old-old-old argument about analog vs. digital.

It all comes down to the fact that BOTH of them have ultimate limitations to resolution and signal to noise ratio.

So really all we need to worry about is the REAL finality of the "time quantum" of human perception of the information streams.

Just as you can not reliably hear above 30KHz, you can't see beyond certain limits of rate of change of light either!

James. 

[BlinkenLights]

i disagree...

by thinking inside this box you limit the flexability of design..

who is to say that i can modulate my laser with a true analog signal..

software could be written that sends instructions to a box that actually modulates the laser with a true analog signal, just like me twisting a knob..

in the SAME breath the same software may be ablt to do the same thing for scanners..

yoou say point a to point b and some other information about the math of the curve, and it does it in the analog domain..


obviously this is an extreme example, but the file should store data in the most accurate way possible..

That being said, what about starting with a BASIC set of primitives like POINT and  LINE. build on that descriptive atributes like LOCATION , ANGLE, ROTATION, COLOR, ETC, ETC...



just a thought...


my idea is to describe the art in its purest form...  kinda like the way that FLASH, ILLUSTRATOR and COREL DRAW do...