Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

explanation, gurus? :-) (image memory representation)

 [1/16] from: petr::krenzelok::trz::cz at: 21-Aug-2001 0:21


Hi, I visited today my friend, who helped me to do .dll library in gcc under Windows. Kind of a pain :-) We tried to prepare small function for image manipulation. I remember Jeff stating that the way to allow library space code to access rebol word data is by using pointer thru structurre .. (http://rebol.org/userlist/archive/504/457.html ) Because we are trying a little bit to prepare ourselves for our camera, and data received, we did a small function. We receive primare data in bytes (binary form), so receiving them thru rebol port, we will get something like: ->> to-string #{FFFF} == "" for FFFF = 65535 pixel value. As we need to convert to RGB, we did it in following way: str1 ... our raw image data received from camera in above form str2 ... preallocated string (we have to use insert/dup to prevent library crash), of size 3 * (lenght? str1) len ... length of image data we send into library ... We found out, that once we send string into library, it is hopefully not copied (or we think so), but only pointer is received and data is manipulated directly in 'str1 or 'str2 rebol storage space. So the result is - our 'str2 contains data "ready" to display ... So now is the time to convert it to image datatype: img: make image! reduce [XxY str2] view layout [image img] So - it somehow works (or so did our very primitive test example ...) Now the question is - we have data in display, or let's say - 'img already exists, and we would like to do something directly in it (e.g. user adjusted img data by some effect, e.g. brightness). How to easily get the image data back into string, avoiding copying data? I came to a little bit ugly aproach :-) mold img, cutted off "#{.....}" string, loaded it, converted into string, ready to be sent into library once again. But, with large images, it is sure time consuming aproach :-) Would using structures help here? Would it allow us to modify image data directly? I am a little bit confused by rebol "polymorphism" though: img: make image! [1x1 #{FFFFFF}] ->> first img == 255.255.255 ->> second img == 0.255.255 ->> third img == 99.0.255 ->> fourth img == 108.99.0 where do second, third, fourth come from? What about this one? img: make image! [10x10 #{FFFFFF}] == make image! [10x10 #{ FFFFFFCC96CFD8A9CD0000000A00004C96CFE8B0CD0000000A00001C90CF E8B0CD0000000A0000C4E3D9E8B0CD0000000A000084E... ->> view layout [size 100x100 backdrop img] Christopher Ross-Gill: loop 20 [probe make image! [1x1]] courtesy of Chris Ross-Gill, midnight RIM session :-) Ryan Cole: I: make image! [1x1] Ryan Cole: >> I: make image! [1x1] == make image! [1x1 #{00E6E1}] Ryan Cole: >> I: make image! [1x1] == make image! [1x1 #{00E7E1}] Ryan Cole: its different every time. Ryan Cole: >> i: make image! [1x2 #{FFDDCCBBAA99}] == make image! [1x2 #{FFDDCCBBAA99}] ->> next i == make image! [1x2 #{DDCC00AA9900}]
>>
Ryan Cole: The next thing was how next, first and second work on the image binary data, just by offsetting by one, instead of 3 as you would expect. courtesy of Ryan Cole :-) OK, let's hope our Rebol gurus will find some nice explanations ...:-) Thanks and Cheers, -pekr-

 [2/16] from: robbo1mark:aol at: 21-Aug-2001 5:05


PEKR, The image! data is contained in a binary! string in which each group of two characters is a value corresponding to a hex value equivalent to one byte. ie {FFFFFF} = FF FF FF (hex) or 255.255.255 each RGB tuple can be contained in 6 hex chars which is equivalent to total range of colour values 0 thru 255 for each Red Green & Blue. First, Second, Third, Fourth, Last etc take subsequent groups of 6 chars as described above. Hope that helps, Mark Dickson In a message dated Mon, 20 Aug 2001 6:27:07 PM Eastern Daylight Time, "Petr Krenzelok" <[petr--krenzelok--trz--cz]> writes:

 [3/16] from: petr:krenzelok:trz:cz at: 21-Aug-2001 11:31


[Robbo1Mark--aol--com] wrote:
> PEKR, > > The image! data is contained in a binary! string in which each group of two characters is a value corresponding to a hex value equivalent to one byte. > > ie {FFFFFF} = FF FF FF (hex) or 255.255.255 > > each RGB tuple can be contained in 6 hex chars which is equivalent to total range of colour values 0 thru 255 for each Red Green & Blue. > > First, Second, Third, Fourth, Last etc take subsequent groups of 6 chars as described above.
Yes, but: img: make image! [1x1 #{FFFFFF}] ->> img: make image! [1x1 #{FFFFFF}] == make image! [1x1 #{FFFFFF}] ->> first img == 255.255.255 ->> second img == 0.255.255 ->> third img == 0.0.255 ->> fourth img == 0.0.0 ->> fifth img ** Script Error: Out of range or past end ** Near: fifth img at least confusing, isn't it? There is no second, third, fourth pixel in our 'img contained ... -pekr-

 [4/16] from: dockimbel:free at: 21-Aug-2001 12:14


Hi Petr, Petr Krenzelok wrote: [...]
> img: make image! [1x1 #{FFFFFF}] > ->> first img
<<quoted lines omitted: 6>>
> == 108.99.0 > where do second, third, fourth come from?
Seems to be a bug !
> What about this one? > > img: make image! [10x10 #{FFFFFF}] > == make image! [10x10 #{ > FFFFFFCC96CFD8A9CD0000000A00004C96CFE8B0CD0000000A00001C90CF > E8B0CD0000000A0000C4E3D9E8B0CD0000000A000084E...
That's clearly a bug. The byte sequence that appear is a Rebol memory space dump !! It's more than a simple bug, it's a potential security hole ! Also, did you notice that image!'s data are stored internally in 32 bits ?
>> img: make image! [1x1 #{FFFFFF}]
== make image! [1x1 #{FFFFFF}]
>> length? img
== 4
>> to-binary img
== #{FFFFFF00} It would be great if more Rebol types were supported by the /library interface. (Image! should be my first choice!). Regards, DocKimbel.

 [5/16] from: cyphre:volny:cz at: 21-Aug-2001 12:47


Hi Pekr ;-) It reminds me very old /View bug when creating empty images. try for example this: loop 100 [probe make image! [5x2]] There is probably still something wrong with image! datatype creation and maybe with the image's data access using 'first,'second... you have mentioned. Maybe someone from RT could explain it? ;-) I recommend you to use accessing images using img/1 etc. which works well for me. Cyphre ----- Original Message ----- From: "Petr Krenzelok" <[Petr--Krenzelok--trz--cz]> To: <[rebol-list--rebol--com]> Sent: Tuesday, August 21, 2001 11:31 AM Subject: [REBOL] Re: explanation, gurus? :-) (image memory representation)
> > [Robbo1Mark--aol--com] wrote: > > > PEKR, > > > > The image! data is contained in a binary! string in which each group of
two characters is a value corresponding to a hex value equivalent to one byte.

 [6/16] from: petr:krenzelok:trz:cz at: 21-Aug-2001 12:32


Hi Nenad, thanks a lot. I sent it to feedback for RT to look into .... My problem is - I am not good at various base conversions. Let's say I want to have something like that: 00000001 - byte representation, where certain bits will mean some action in our device. So, while in Rebol, I can construct such string. But how to easily convert it to binary for our 8bit chip. I mean - I want my friend to receive above mentioned 00000001 representation ... What aproach to choose? Let's say I want to express, that CCD read-out will be 324x200 pixels .... How to encode 324 value into those "001101010101blabla"? :-) btw: do you know that debase "00000001" crashes rebol/view? Rebol/Command seems to be OK, but try debase/base "00000001" 2 :-) Thanks, Best, -pekr- Nenad Rakocevic wrote:

 [7/16] from: cyphre:volny:cz at: 21-Aug-2001 15:03


Hello again Pekr and Nenad,
> btw: do you know that debase "00000001" crashes rebol/view? Rebol/Command
seems to be
> OK, but try debase/base "00000001" 2 :-)
bug in last version of /View (see http://www.escribe.com/internet/rebol/m11462.html) regarding the problems with images...maybe this problem has something to do also with Rebol's crashing when drawing filled polygons(using Draw dialect) out of bounds of the image area...looks like DRAW corrupts memory alocation or so.Try for example: this works: view/new layout [i: image make image! [50x50] effect [DRAW [fill-pen red polygon 0x0 25x0 25x50]]] show i wait [] this crashes: view/new layout [i: image make image! [50x50] effect [DRAW [fill-pen red polygon 0x0 25x0 25x100]]] show i wait [] Cyphre

 [8/16] from: jeff:rebol at: 21-Aug-2001 7:10


Howdy, DocKimbel:
> > What about this one? > >
<<quoted lines omitted: 5>>
> Rebol memory space dump !! It's more than a simple bug, > it's a potential security hole !
When we create an image and pass in some binary data to use for that image: if the image is larger than the data we provided the remaining memory is uninitialized. This memory is from the heap. No live objects will be in there, but perhaps fragments of recycled objects could be evident there. It'd be hard for someone to programmatically exploit this current behavior by looking a random window of heap memory because the contents are as good as random due to the variances in the recycling path for different OSes, architectures, and machine configurations-- this is also not an issue of a being able to munge the stack since this is all heap memory (possibly reclaimed or otherwise). Nonetheless, this remainder memory should be cleared.
> Also, did you notice that image!'s data are stored > internally in 32 bits ?
We save out images with out the alpha channel and reconstruct the alpha channel when reading images back in.
> It would be great if more Rebol types were supported by the > /library interface. (Image! should be my first choice!).
The next Library revision will allow all string-series! types to be passed where a library routine expects string!-- that includes such types as image, binary, issue, email, etc. RETURING these types is a whole different issue, though. :-) -jeff

 [9/16] from: dockimbel:free at: 21-Aug-2001 16:56


Howdy Jeff ! Thanks for your enlightening reply ! Jeff Kreis wrote:
> Howdy, DocKimbel: > > > What about this one?
<<quoted lines omitted: 10>>
> this current behavior by looking a random window of heap > memory [...]
Sure, i tried without any success ;-) That's why i said "potential".
> The next Library revision will allow all string-series! types > to be passed where a library routine expects string!-- that > includes such types as image, binary, issue, email, etc.
That's a VERY good news !
> RETURING these types is a whole different issue, though. :-)
Opening the internal Rebol API to make external components might be a more interesting solution. I remember some discussions about that on /link, RT's answer was : ok, but wait for the API to be freezed. (or something like that). Are we closed to that state ? Best regards, DocKimbel.

 [10/16] from: petr:krenzelok:trz:cz at: 21-Aug-2001 17:52


> > Also, did you notice that image!'s data are stored > > internally in 32 bits ? > > We save out images with out the alpha channel and reconstruct > the alpha channel when reading images back in.
... weeee ... LIKE alpha :-))
> > > It would be great if more Rebol types were supported by the > > /library interface. (Image! should be my first choice!). > > The next Library revision will allow all string-series! types > to be passed where a library routine expects string!-- that > includes such types as image, binary, issue, email, etc.
OK, could you a little bit outline what is the difference in your example (http://rebol.org/userlist/archive/504/457.html ), where you use struct! datatype and string being its first element to get pointer into rebol word, and sending the string to the library directly? We were successfull in modifying Rebol data in-place by sending the string directly, without the trick with using structure. What is the difference please?
> RETURING these types is a whole different issue, though. :-)
components, compiler, yeah yeah :-)) Cheers, -pekr-

 [11/16] from: fsievert:uos at: 21-Aug-2001 17:59


> > It would be great if more Rebol types were supported by the > > /library interface. (Image! should be my first choice!).
I had this problem before and have a sollution. You can create an string! out of the image! which uses the same memory-area. Example:
>> im: make image! 10x10
== make image! [10x10 #{ 000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000...
>> parse im [str:]
== false
>> str
== {^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^...
>> change str "hello"
== {^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^...
>> im
== make image! [10x10 #{ 68656C6F0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000... You can give str to the library-function and it will change your image!. I used this for a program. Hope that helps, Frank

 [12/16] from: petr:krenzelok:trz:cz at: 21-Aug-2001 18:36


----- Original Message ----- From: "Frank Sievertsen" <[fsievert--uos--de]> To: <[rebol-list--rebol--com]> Sent: Tuesday, August 21, 2001 5:59 PM Subject: [REBOL] Re: explanation, gurus? :-) (image memory representation)
> > > It would be great if more Rebol types were supported by the > > > /library interface. (Image! should be my first choice!).
<<quoted lines omitted: 6>>
> 000000000000000000000000000000000000000000000... > >> parse im [str:]
heh, hey, cool, how did you found out? :-) Much simpler than: ->> str: find mold image "#" == "#{000000}]" ->> remove back tail str == "" ->> str: to-string load str == "^@^@^@" OK, thanks for the advice ... -pekr-
> == false > >> str > >
{^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^... > >> change str "hello" > >
{^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@

 [13/16] from: fsievert:uos at: 21-Aug-2001 19:46


> ->> str: find mold image "#" > == "#{000000}]" > ->> remove back tail str > == "" > ->> str: to-string load str > == "^@^@^@"
What does this do? Isn't that the same as
>> str: to-string #{000000}
== "^@^@^@" Frank

 [14/16] from: fsievert:uos at: 21-Aug-2001 19:54


> ->> str: find mold image "#" > == "#{000000}]" > ->> remove back tail str > == "" > ->> str: to-string load str > == "^@^@^@"
Forget my last email. I understand: You only want the rgb-values. But parser does not help with this:
>> im: make image! 1x1
== make image! [1x1 #{000000}]
>> parse im [str:]
== false
>> str
== {^@^@^@^@} The only advantage is that if you change the string, it will change the image. You can give it to library-functions with this trick. But you could also use
>> second third load mold im
== #{000000} CU, Frank

 [15/16] from: petr:krenzelok:trz:cz at: 21-Aug-2001 20:06


----- Original Message ----- From: "Frank Sievertsen" <[fsievert--uos--de]> To: <[rebol-list--rebol--com]> Sent: Tuesday, August 21, 2001 7:46 PM Subject: [REBOL] Re: explanation, gurus? :-) (image memory representation)
> > ->> str: find mold image "#" > > == "#{000000}]"
<<quoted lines omitted: 5>>
> >> str: to-string #{000000} > == "^@^@^@"
yes, sorry, I just forgot to insert first line of my script: image: make image! 1x1 Simply said - I worked with already existant image, e.g. loaded .jpg file. It will end-up in image datatype, so I found above complicated way of how to get binary out of it - using mold image :-) your way is much much more simple, of course - no need to load binary data into string ... -pekr-

 [16/16] from: g:santilli:tiscalinet:it at: 21-Aug-2001 19:28


Hello Petr! On 21-Ago-01, you wrote: PK> Now the question is - we have data in display, or let's say - PK> 'img already exists, and we would like to do something PK> directly in it (e.g. user adjusted img data by some effect, PK> e.g. brightness). How to easily get the image data back into PK> string, avoiding copying data? to-binary will work, but it is probably doing a copy. (I didn't check that. You may try with Nenad's memory watcher or just by poking in the binary to see if the image changes.) PK> What about this one? [...] Probably it's just that REBOL does not clear the memory area assigned to the image upon creation. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted