Topic: Exploding Head

[James]

I just got an email from someone with a question and the answer made my head explode.

It amounts to an entirely new dimension of utility for wave DSP.

NEATO! 

It might take me a minute or two to get it working in code.

James. 

[dtewksbury]

What is it?

[James]

I've got to come up with a set of rules, but it's a way to correct for color modulation nonlinearity.

All I need to do is read from a simple text file of exactly 256 ASCII decimal values in the range of -32768 to +32766. These numbers must all be even and none of them may be repeated.

Each color channel; of which there are four in use in LaserBoy {R, G, B, I}, can be translated from the binary pure RGBI unsigned 8-bit values to signed 15-bit values from weighted lookup tables.

If the lookup tables are all even numbers (top 15 of 16 bits) then we know that the LSB will never be set, so it is still clear for marking the end of frame and unique frames. If all of the numbers in the table are unique, then the table can be saved in binary in the header of the wave file so the translation can be undone!

With this system, you will be able to correct your color modulation signals for each channel to achieve the best linearity possible, with nothing more than an ASCII table of numbers; one for each channel that requires rescaling.

It's a lot like the voltage lookup tables in a video DAC.

James.  

[dtewksbury]

I know what you just said, but I still don't understand the use. Have you divided the color value into 256 of 16384 possible values, then chop off the 8 least significant bits and use the 8 most significant bits from the lookup table to go to the DACs..... Maybe I don't understand at all.

[James]

To get from any individual color value we go from unsigned 8-bit to signed 16-bit simply by shoving it up 7 bits.

That gives us a perfectly linear relationship between 8-bit unsigned in and 16-bit signed (all positive) out.

What if we don't want a perfectly linear relationship or all positive numbers? What if we want to use the whole DAC from minimum to maximum with a non-zero DC offset correction?

This can be done with a lookup table.

A table is 256 unique values within the signed short storage range. If all of the shorts are even numbers then the least significant bit will never be set. So it is still free to mark the end of a frame or a unique frame (as it does in LaserBoy waves now).

If the numbers are even and unique, the lookups will be one-to-one in both directions with no loss of information.

So, with each appropriate color rescale table stored in the header of the wave, each color channel can be translated back into the 8-bit unsigned color values from whence they came, for proper display on a color monitor and for retranslation to a different laser projector.

All you need to do is generate plain ASCII tables of numbers and give them unique file names for each one of your lasers with a modulation that requires digital rescaling and set these file names in the appripriate places in LaserBoy.

James. 

[James]

GAWD!

Sometimes my writing is ambiguous as all hell.

What am I going on about?

James. 

[drlava]

A lookup table is OK, but for simple correction all you need is a line and gamma ratio to fit most devices.  That's 3 parameters.  For advanced correction you need more than a lookup table, you need to model thermal characteristics of the non linear optics.  I'm not saying it won't work, but you might be better off with the 3-4 parameter approach with a quadratic function

[dtewksbury]

mmmmmmm..... That's all cool, but why not just use 256 8 bit values, that's what they will end up in the end anyway.

[James]

I look at it as the most file worthy representation of what I'm trying to do.

I know I have an 8-bit unsigned to start.

I'm going to put it into a 16-bit singed number.

A look up table is easy to store. You can come up with any way to calculate it you want.

I might as well use more of the bits in the 16-bit numbers, because they are there. What if trying to get that last little bit of linearity out of the low-end requires using values that are less than 128 DAC voltages apart?

There are only 256 ASCII numbers in a color rescale file. You can write them in a text editor.

I also realize that this will not correct for any kind of hysteresis.

What it might do is make other arragements for laser voltage modulation a lot easier to drive.

It's almost done! 

Good night! 

James. 

[no-esc]

What it might do is make other arrangements for laser voltage modulation a lot easier to drive.

Maybe I am not following along very well... But would this new voltage modulation help with the GREEN DPSS lasers?

[James]

What this will do is allow you to create your own voltage curve to drive your laser's modulation input.

Let's say you don't have anything but a diode laser and you want to make your own current regulator with some sort of analog modulation.

The standard way to do this would result in a system that changes brightness based on a perfectly linear relationship with a control voltage from 0 to +5VDC.

You might come up with some other way to do it. What if your control voltage is not linear? What if it's not all positive? What if it's positive inverted?

Who knows? Who cares?

With this addition to LaserBoy, you will be able to map out 256 unique 16-bit numbers that will come out the DAC to drive your laser. These 256 values will be indexed with perfectly normal values for R, G, B, or I, but the resulting voltages from the DAC will be whatever you need them to be.

Also, keep in mind that the control voltage will be coming from a DC modified sound card with (or without) an offset voltage correction and gain. So you will have additional adjustement range in the analog portion of the system as well.

If lookup tables are used to make a custom wave for your system, they will be saved in the header of the wave. This makes it possible to share this wave with others as-is. The only thing someone else would need to do is rip it through LaserBoy to remove your lookup tables and re-linearize the color channels for proper display on the monitor; and then possibly rip it out as wave with their own custom lookup tables.

No this will not correct for any kind of problem that is the result of the laser heating up or cooling down.

James. 

[dtewksbury]

Yep, I keep forgetting you use sound cards, so you have a signed 16 bit value to play with. I only send 8 bits per color to the FPGA for processing because my hardware is network based and I need to keep the bandwidth to a minimum so that I can control lots of laser heads and other media. Although having said that, a slightly different voltage between 1 of 256 levels would probably not be noticeable anyway I suspect.

I just added color scaling. I was getting sick of the Argon/Krypton looking blue green biased, so I added a scaling adjustment on each color channel. Now I can balance the output for white without adjusting the PCAOM, much easier, and it looks good balanced now, although it is nice to use that really bright yellow line, and the deep violet one.

[James]

1 of 256 levels would probably not be noticeable

Tell me about it!

It's hard enough to see 256 level of R, G, B or I even on a good video monitor.

I guess it all comes down to making the fade-outs and fade-ins look as good as possible.

Oh well. It's a feature to tweak!

James. 

[dtewksbury]

True, but at least in your mind you will see the difference, and you will feel good about it too.

[meandean]

  Ok, so you're using the top 15 bits instead of the usual 9 (including sign bit) to hold an 8 bit precision color channel byte in a 16
bit integer audio sample, leaving the lone LSB for frame marks & such. The idea is that now with the extra bits of precision, you can
apply a sophisticated color correction curve to the data; spelled out in the wave header, so that correction could be easily reversed  at a later time, and the original 8 bit precision color could be restored with no data loss. Done properly, it could make use of bits that otherwise go to waste in the wave format.

  At first I thought that would be hard to apply in my app, because I store color channels in memory as 8 bit exclusively, but I could
always encode-decode as I read and write to wave, as I do with things like polarity and inter-channel timings. I'm not too happy with storing integer color tables as text, though. For me, it's easier to just to do a quick color re-process of an existing wave to a
disposable target file to best suit a specific situation. For now, I have overall gamma correction, but I can easily split it up for
individual color channels.

  As for managing soundcard DAC offset via software alone, eliminating the need for a correction amp, I don't think that's a good idea because you end up with a situation where wave signal has to be continually sent to the DAC just to maintain black. Soundcards require amps to get the needed voltage anyway, so you might as well use a correction amp.

  If SDL allows for streaming to a multi-ch audio card, now's the time to figure it out. You could build a wave player in LaserBoy that
has runtime parameters that could be applied and adjusted on the fly to an existing wave, without all this extra stuff.