How can I get from an array of byte sized integers to a bitmap.

[help] How can I get from an array of byte sized
integers to a bitmap.

Hi Yoshiki,

Here is a some what delayed reply to your older post
on this thread.

Cheers -Jer

***
>
>
>Yoshiki Ohshima yoshiki at vpri.org
>Thu Jan 31 10:59:27 UTC 2008
>
>  Hi Jerome,
>
>  Oh, that picture looks interesting.  If the values
you're getting is
>valid, that is a fun tool.
>
>> >  This description is very vague, I have to say.
>>
>> Ah, and here I was thinking I was being precise
>> without going into unnecessary detail. :-/
>
>  Now, why don't you have to post the code there? ^^;

Lol, the picture was from the first application that
worked. I intend to put the code up after a few more
iterations of development. I conceived of the idea in
the middle of a letter to Matthew Fulmer.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124461.html


Code needs cleaning and sorting.

>> >  - What are the number of columns and rows?  What
>> are inside?
>> The columns and rows are settable by the user. Once
>> set they are knowable.
>> As for the inside on one end it is data about time
and
>> on the other just a colorful way of displaying the
>> contrast amoung the data.
>
>  These values are somehow [0..255], right?  If you
use Bitmap or
>ByteArray instead of Array, that would be easier.

Raw data may exceed that but a power compression using
#highBitOfMagnitude will get any time period of
interest into a byte.  Contrast is achieved by
subtracting out the minimun raw value and scaling
between the min and max power values.


>> >> The application I have will essentially update
the
>> >> array over time and I wish to display it
visually.
>> I
>> >> would like to do it in a time efficient way
rather
>> >> than pixel by pixel.
>> >>
>> >> I've looked at the options in the image and I am
>> not
>> >> sure which ones are right.
>> >>
>> >> Ideally once the color form is set up I should
be
>> able
>> >> to update it just by updating the bitmap from
the
>> >> array periodically.
>
>  As I understand, the values in an Array (now it
would be in a Bitmap
>or a ByteArray) change over time, and you want to map
the values to
>colors.  Isn't the mapping static?  I.e., it doesn't
change over time
>so that the same value in data is always mapped to
the same color?

So far yes. I don't need to change the color mapping.
Of course any particular color scheme is choosable. To
the taste of the user. It is independent of the data.

>So, I could build a color map (a Bitmap object) once,
store it
>somewhere like in a class variable and use it?

The pallette is no problem just generate 256 colors
and give them to a color form.

>
>> I eventually realized I did not have to set the
bits
>> all once and what worked was building a pixel poker
to
>> my form.
>
>  Hmm.  In this approach, is it possible to bypass
the step of storing
>data into the Array and read from it?  I.e., just
(effectively) write
>into the bits of the ColorForm by using the pixel
poker?

That's essentially what I decided to do with the power
compressed data. Though I do it one pass behind to
keep the min and max value data valid. This is the
part of the design that is influx right now as I learn
what works and reprogram to suit.  Gossamer Condor
style.

note from a little programming later:  I have now
found it easier to just process each pass of data as
it comes of the scanner. I am also experimenting with
different compression and scaling schemes to see which
one highlights the differences of interest best.

>
>> By holding on to the poker I can update the form
fast
>> enough. The appllication is scanning the display
for
>> slow spots and will generate one datum per several
>> cycles.
>> I collect the data as integers into an array and it
>> was ok to store a pixel each time the data came in.
>>
>> This was simple and it worked (after I found a bug
or
>> two in my typing.) And this lets BitBlt continue to
>> hide the difficulties with endianness and so forth.
>>
>> Still a fast way to go from array to bitmap would
be
>> useful.
>> Its not to hard to insist the columns be a multiple
of
>> 4 so the data keeps word boundrys intact.
>
>  I don't know how you scan and acquire data, but I'd
imagine that you
>get a value for a rectangle that is the bounding box
of a morph.  If
>so, you can "fill" the bitmap with an expression
like:
>
>aForm fill: (30 at 30 corner: 50 at 50) fillColor:
(Bitmap with: 128).
>
>(i.e., a Bitmap of length 1 can be used in place of a
Color.)
>
>  By the way, using ColorForm with translucency fails
when the
>destination (or Display) is 16-bit depth.  

In that case we could use a solid color pallete, color
code the data and display it over the test area with
an alpha blend.

(And, I found out that
>there are particular combinations of depth and
translucency and kind
>of morph you use that don't work either in Etoys
image or 3.9.  Hmm.)

Karl worked out some solutions for some of the color
translucency problems. There are some mantis reports
detailing it. I think you are right about 16 bit
colors. I remember seeing a lot of strange results
when working on some of the bugs.  I've put those
problems on my awaiting enlightenment list.
Enlightenment often comes while working on other
problems.


What I am building is a probe to show where to speed
optimize. And to test that speed optimization actually
works. What I feared was that invalidating some parts
of the screen would cascade to larger areas causing
slowdowns.

The picture shows this seems to be true when the
invalid point overlaps the system window label. So
probably caching the label bits will save a lot of
grief. It also points to looking for speed
optimizations in true font character display and maybe
character display in general.

>
>  Given that, it is safe to go with a 32-bit form:
>
> t := Form extent: 128 at 128 depth: 32.
> 0 to: 127 do: [:y |
> 0 to: 127 do: [:x |
> t pixelValueAt: (x at y) put: (x bitShift: 24)]].
>"Gradient Fill with some trick can do above better,
but to illustrate the
>idea..."

pallette := (0 to: 255 )  collect: [ :each | Color
black alpha: (each asFloat / 255 asFloat) .
pallette := pallette reversed .
ColorForm extent: (cols at rows) depth: 8
 ; colors: pallette .

>And,
>
> (SketchMorph new form: t) openInWorld.
> "which doesn't work in the 3.9 image in 16-bit
Display depth."
>
>or better write the following in your morph's
#drawOn: method:
>
> t displayOn: Display at: 100 at 100 rule: 34.
> "this works in 16-bit display or 32-bit display (and
8-bit^^;)"
>
cool

>  Well, I learned a lot about the differences between
3.9 and Etoys
>image in this exercise.
>
>  To do the #bitShift: above efficiently for a
rectangle of data, you
>could do the trick with #hackBit and WarpBlt together
(like the way in
>SugarLibrary).  But this would be another round...
>
I don't think I will need this. I just put the form
into a BitmapFillStyle and let the existing drawing
tools do the work.
I have augmented the Oriented fill tools a bit and
relyed on some of those metods here.
I can stick the fill in a rectangle morph or a polygon
morph and display it from there.



>-- Yoshiki
***



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

  Hi, Jerome,

>>  As I understand, the values in an Array (now it would be in a
>> Bitmap or a ByteArray) change over time, and you want to map the
>> values to colors.  Isn't the mapping static?  I.e., it doesn't
>> change over time so that the same value in data is always mapped to
>> the same color?

> So far yes. I don't need to change the color mapping.
> Of course any particular color scheme is choosable. To
> the taste of the user. It is independent of the data.

  Good.  In my mental model, data is the stuff that changes
constantly, but "color map" is in the realm of "viewing" and changes
only now and then when the user wants to change it.

  I don't know what Gossamer Conder style is, but sounds like we are
in some kind of agreement.

  Ah ok, by looking at the picture, I thought you were doing alpha
blending on to Display, but sure yes, that wasn't the only way.

> What I am building is a probe to show where to speed
> optimize. And to test that speed optimization actually
> works. What I feared was that invalidating some parts
> of the screen would cascade to larger areas causing
> slowdowns.

  Hmm, so, a solution outside of invalidation and #drawOn: resime could be better?

  Yes, I actually tried this and it was where rendering onto 16-bit
depth didn't work.

  Thank you!

-- Yoshiki