Manipulate Bitmap in DSP Code

[tulamide]

@kortezzzz
Ruby is an OOP language. Everything is an object. Therefore, there is only one type of array. You can use it for any type of object, for example [64, 1234567891234567, 1.0275, "A", ["B", 2], {fruit => "apple"}]
'In order of appearance, this array contains the objects fixnum, bignum, float, string, array, hash table. Find out more about arrays in the 3rd part of Ruby Stripped: Arrays, on Flowstone Guru.

@martin
You spotted exactly the weak point. I was able to find undocumented methods that get and set the ARGB values of a color, but there is nothing comparable to getPixel, at least not with internal tools!

[martinvicanek]

@martin
You spotted exactly the weak point. I was able to find undocumented methods that get and set the ARGB values of a color, but there is nothing comparable to getPixel, at least not with internal tools!

Too bad. So basically we can use Ruby for only little more than a loop generator. I did this and used getpixel externally, and guess what: it was two orders of magnitude slower than green. It seems there is a substantial overhead on Ruby's I/O. Whatever.

[aronb]

Martin,

First thank you again for the help !

But I am having a few issues with "StreamGetPixel.fsm" you provided...

When I scan thru the image with a raster pattern the RGB output does not seem to access quite right. I am trying to figure it out so I can even explain it, but it seems like the index is not quite right maybe or the phase of the RGB outputs is off. when the index is looking up the data shouldn't the index be the width x height instead of just the width for example?

I have a few modules that have 2D array inputs to a 1D array index out, so I am still figuring out your module, it seems so close to working too !

I will try and put a mock-up schematic up... the regular schematic I am using has external hardware that is needed to see / understand the results.

I will post again as soon as I get a generalized schematic done.

Thank you,

Aron

[tulamide]

Too bad. So basically we can use Ruby for only little more than a loop generator. I did this and used getpixel externally, and guess what: it was two orders of magnitude slower than green. It seems there is a substantial overhead on Ruby's I/O. Whatever.

Isn't that a shame? There's a bitmap class, color class, there are methods to set colors from ARGB values, methods to get the color channels from a color - and then it lacks that one method, equivalent to the get-pixel-prim! That's like teasing a dog with a dog buiscuit ("Good boy, yes, you're a good boy!"), but never giving it to that poor dog...

EDIT: If at least there was a "to_array" method in the bitmap class, we could then grab the appropriate values. But without externals I see no way. And external mostly also means the whole chain (loading an image format to a bitmap, etc.), which breaks compatability to green. Yes, it is a shame!

[martinvicanek]

when the index is looking up the data shouldn't the index be the width x height instead of just the width for example?

In my schematic the indexing of pixels is according to a line scanning scheme:

Code: Select all

 0 ,  1  ,  2  ,  3  ,..., w-1
 w , w+1 , w+2 , w+3 ,...,2w-1
2w ,2w+1 ,2w+2 ,2w+3 ,...,3w-1 
.
.

so the xth pixel in the yth row would have an index x + y*w.

[aronb]

Martin,

Here is a sample schematic of the issue I was talking about.

BMP_Raster_Test.fsm

BMP Test

(88.07 KiB) Downloaded 1042 times

Manual pointing on the Bitmap image seems to work fine, but not when scanned using an oscillator for example.

There should be a 1 to 1 correspondence with input XY and the color output no matter what input you use. Arrays like this I have done in the past with DSP code typically work well, it is almost as though something is wrong with the "mem" primitive??? Maybe I will make a DSP module to store the BMP data instead of using mems...

I should be able to scan whatever waveform onto the BMP and get back the correct ARGB value.

Thanks Again,

Aron

[pshannon]

Thanks for the feedback, kortezzzz. I did some trigger engineering and got the following benchmarks for a 512x512 pixel image;

loading time: 3s
processing time: 1s

That's not great but certainly better than 5 min. Perhaps an external DLL would help, but then it is sort of pointless to use FS in the first place, no?

I know this is a very old post, I am still learning Flowstone and its capabilities. If you are looking for image processing at the fastest possible speed, you will need to use something a function called scanline. This type of feature/function which is in common programming languages will access the video card memory at an extremly high rate. Otherwise the get pixel function in any language is using the cpu to grab the info from the video memory and it is a lot slower. I have used this many times in the past for bitmap manipulation. If FS has this feature, then you will be in luck, but from what I can tell, it does not and it was not meant to do that. You would need to reference it through a dll, however, it might still be slower then you want going from FS-->Dll. I just did a google search and pasting the first link I found. Do you notice in photoshop how they give you a preview of the image you are changing the colors on ect on the fly? That is the scanline in practice. Very powerful! Goodluck.

https://stackoverflow.com/questions/405 ... ethod-in-c

QuadBIT