AltME groups: search

What about 

>>RED
talk dialects


the >> is a play on the target image used in REBOL where >> is both 
from a console,and also an arrow head?

Peter: the lib-test file is crashing here on my OS X 10.6.2 image 
with following error:

dyld: lazy symbol binding failed: Symbol not found: _strnlen

  Referenced from: /Users/dk/Desktop/Red/red-system/tests/runnable/lib-test
  Expected in: flat namespace


After researching a bit about it, it seems that strnlen() is (was?) 
not supported by OS X.

It seems that strnlen() is defined for versions >= 10.7.0...unfortunately, 
I can't upgrade my image (virtual image), so I will replace strnlen() 
by strlen() in the tests.

Nenad" "Peter: the lib-test file is crashing here on my OS X 10.6.2 
image with following error:"


Did you install Xcode including the Unix libs?  I wrote the tests 
under OS X 10.6 but am now running on 10.7.

It's strange that it didn''t work for Rebolek even on its WinXP virtual 
image...do you have an antivirus installed there?

Thanks for the link...if I take Linus' code and add it to Red/System, 
I should be able to output a VM image directly from a Red/System 
program, no? ;-)

Depend on what you mean by "debug version" and what debugging tools 
you're thinking about. My plan for Red is to deeply integrate it 
with the IDE, so that you'll be able to have advanced debugging capabilities, 
like step-by-step debugging. Such feature could maybe also be ported 
to the console version, so you'll be able to use it even without 
the IDE installed.


Also, I have thought the Red execution architecture to be as reflective 
as possible in order to try to support memory image loading/saving 
and stopping/resuming (think Smalltalk). It's very tricky (not sure 
we'll have it in the end), but if we can achieve it, you'll be able 
to get a snapshot of a running Red program on file, transfer it and 
resume it somewhere else....ideal for reproducing exact bugs occuring 
conditions. EDIT: the right expression for that is "Image-based persistence".


In the meantime, we already have some "debug mode": -d switch for 
Red and -g switch for Red/System (we'll probably adopt -d for both, 
-g will be reserved for gdb support). It's mainly intended for internal 
usage for now, the Red/System one can be useful to locate runtime 
errors in source code (usable, but still needs some fixes though).

Strange concept

 It looks pretty classic to me, but there are some specific reasons 
 behind such choice, that I will detail them in a future blog entry. 
 Basically, it simplifies the tracking of Red values on stack (making 
 the work of the GC easier) and stack serialization becomes almost 
 trivial (to memory, for continuation support, or to file, for image 
 support). I think that R3 doesn't do it that way, but probably uses 
 recursion, passing all R3 values on C stack instead. It's a faster 
 approach but less flexible.

I'm fixing the Unicode string printing issues on Linux/ARM...will 
post the fixes tonight.


BTW, I've now an ARMHF image installed, so I'll work very soon on 
supporting ARMHF ABI.

Hello-GTK-world is still segfaulting on my Debian-armel image on 
QEMU. I will investigate that tomorrow.

To put it concretely, the AVR backend needs to generate a memory 
image, without external symbols because there is no operating system, 
but with all internal addresses resolved. Can that memory image be 
constructed by appending data-buf and code-buf?

Image is here:
http://www.rebol.com/docs/core23/rebolcore-6.html#section-1.1

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

never mind, talking about View engine itself. I don't like gobs logic 
in some aspects anyway ... I e.g. don't like separate gobs for text, 
color, image, effect, draw. Dunno low level logic, but it could be 
all in draw dialect. Simply put - always hated when you can do gob/text, 
but then you can do another text in terms of draw, ditto effect, 
etc.

I know that François Jouen is already using Red/System to make image 
capturing from multiple cameras on OS X. Also as a rule of thumb, 
everything that is doable in C can be also achieved in Red/System.

An example of loading an image is here in PeterPaint:

ah, wrong, I thought that you just need an image info, not actually 
an access to the bitmap data ...

There's also a basic binding to image loading in GDK, so that would 
load you all image types that GDK supports, including JPEG:

With the following code:

#include %GTK.reds

with gdk [
	err: declare struct! [value [g/g-error!]]
	myimg: load-image "image.jpg" err
]

I get the following error:


*** Compilation Error: invalid literal syntax: [value [g/g-error!]]

If I change it to:

err: declare struct! [value [c-string!]]

I get the following error:


*** Compilation Error: argument type mismatch on calling: gdk/load-image

*** expected: [struct! [value [g/g-error!]]], found: [struct! [value 
[c-string!]]]

There's an example of using load-image in GTK.reds in the icon function

Thanks!  When I use load-image, it looks like it is returning a pointer. 
 Is that correct?

If 'load-image returns a pointer, how do I know when I have reached 
the end of the image?

Better yet, assuming 'load-image returns a pointer, how do I access 
the first memory location referenced by the pointer?

See the function spec in GDK.reds. It returns a pointer to an image! 
struct, so if you want to access the image internally, you have to 
go by that struct definition

As you can see in the same file, I haven't finished the definition 
of that struct, because I don't have to look inside the image

Ah, that's relatively easy, because you don't have to know the image 
format. At least not if you can compare byte values instead of strict 
pixels

You'd have to know GDK's internal image format, then

François showed me a few nice demos done with that binding a couple 
of weeks ago when I visited him in Paris. He had some camera-controlling 
and image recognition demos done from Red(/System).

Doc - would it work from behind the glass? I mean - in front of Windows, 
projecting image on the window (with some foils like Vikuiti from 
3M). Because the guy at the video has it laying on table. And you 
also said, that it does not work, if you point your fingers up or 
down, which might mean - towards the device?

NickA - I share your point of view. Ppl mostly nowadays think, that 
the web rules it all. However - it is still complex. I don't care, 
if we generate HTML5 (whatever it is) in the end, as far as we can 
very easily build apps using VID like dialect. I remember those initial 
days, where we had really a small script (1.6KB) to show image from 
4 webcams ...

Any framework that supports more than one image format will have 
its own internal format. That goes for R2, SDL, GDK, ImageMagick 
and any other framework you could bind to

If you bind to LibJPEG directly, you'll have to devise your own internal 
format once you add support for another image type

You could make a binding with SDL-Image to have fewer dependencies

New OpenCV Red/System code demo and video (image real-time filtering) 
posted by François: 

http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C17Mar2013190850930275100%3E

Video link:
http://www.wuala.com/fjouen/Code/OpenCV/Red/pub/filtering.m4v/

François says that the Red/System binding has been tested successfully 
with OpenCV 2.0. Base OpenCV features are 98% complete, now François 
is working on wrapping image processing functions.

It's now running fine on my Linux 32-bit image.

513 ~/Downloads$ chmod +x GTK-browser 
514 ~/Downloads$ ./GTK-browser 
dyld: Library not loaded: /usr/lib/libgthread-2.0.dylib
  Referenced from: /Users/john/Downloads/./GTK-browser
  Reason: no suitable image found.  Did find:

 /usr/local/lib/libgthread-2.0.dylib: mach-o, but wrong architecture
Trace/BPT trap: 5

Some funny slides in there!

How REBOL began 14 years ago...

 - and then an image from the frech revolution with REBOL flags, onto
... and where it is today

 - and the image of a raft at sea with no sight of land, people suffering 
 and great despair.


You need a viking ship in there maybe, sailing off for new adventures 
in a new World.


I feel, Red is a good project, and with BSD license, it should be 
possible to give and take easily, right?

I use a Linux/ARM image running on QEMU to help me debug the low-level 
parts of Android port (which is a really hostile environment for 
low-level coding).

Got a simple HelloWorld text displayed in an Android native window 
using the emulator with an x86 image. Working on the ARM version 
now.

Bo, the above suggestions are all good. Your code looks OK until 
you start generating the third result image

is not the way to allocate an image. as-binary is just a type cast, 
like as-integer, not a declaration

So you're pointing img3 to a semi-random memory area that happens 
to have an address equal to the size of the first image. That will 
crash the first time you try to access the image

Alternatively, you could reuse either img1 or img2 to produce the 
result image if you don't need them afterwards. That would save the 
allocation and freeing of the third image

This is a loop that processes raw binary image data.  'r, 'g, and 
'b are incremented through an 'until loop until the data is all consumed.

The problem I'm trying to solve is to convert two seperate images 
to grayscale and then compare the pixels in each image to each other 
to look for big variations in contrast between the pixels.

I'm passing the processed image back out to Rebol to convert back 
into an image for visual verification of the motion detection algorithm. 
 That part works fine. :-)

But it's probably even faster to iterate through the image with one 
integer pointer, because the pixels happen to be four bytes, and 
then use indexes of 2, 3 and 4 for r, g and b

I'm trying to extend the build script for other platforms, but my 
Ubuntu 11.04 image somehow got stuck with old source repository versions 
and no way to install/update any packages...So I now need to install 
a 12.04 package in order to check the requirement for the build script 
and test it. I'm baffled that the support for a 2 years old Ubuntu 
version is so bad...

By the way, the bottom image is completely built by Red/System.

Henrik: I'm installing an XP SP3 image to try to reproduce your issue.

From http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx:


What is the difference between msvcrt.dll and msvcr80.dll?

The msvcrt.dll 
is now a 

known DLL," meaning that it is a system component owned and built 
by Windows. It is intended for future use only by system-level components."


Looks like another Windows oddity, so I guess XP users needs to install 
msvcr80.dll...testing that on my fresh new XP image.

I searched for GCam on appshopper.com and got hits on the above mentioned 
app (in description they write GCam Swarm and GCam Server). I have 
alot of photo/image apps on my iPhone 4S. Good luck with your.

As far as I know you can compress JPG to any degree.

An what about updating an image ?

Then you access /IMAGE.

I acutually use:
image to-image load news/immagine

Hi, I need again your help:
I have an invalid image in my database.
I update images inside my window and I use this code:

	if not error? [to-image load news/immagine] [
		immagine/image: to-image load news/immagine
	]

I have tried this code too:

	if not error? [picture: to-image load news/immagine] [
		immagine/image: to-image load news/immagine
	]
However I get the following error:

Script Error: Invalid argument: make image! [170x78 #{
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFF...
** Where: to-image
** Near: to image! :value

The error is generated from the block following the IF

Why I am not able to catch the wrong image ?

by the way, LOAD will detect if the argument is an image. So there 
may no need TO-IMAGE.


unless attempt [immagine/image: load news/immagine] [immagine/image: 
load-image %default.png]

Hmm.. LOAD might load the file even if it is not an image. So you 
may need to TO-IMAGE, or check the datatype after loading:
attempt [img: load %file if image! = type? img [...]]

Perhaps it helps to learn about the mechanisms: There are several 
ways to generate a dynamic UI:


The LAYOUT function works by creating an object tree, a tree of faces 
that are simply ordinary objects. When passing this to the VIEW function, 
a layout is displayed. The layout function is part of VID and is 
as such a high level function. VIEW is a low level function to interpret 
the face tree.


The face tree consists of objects that contain other objects through 
the FACE/PANE word. If the FACE/PANE contains an object, that object 
is a single face, that is displayed inside the parent face. If the 
PANE contains a block, that block may contain multiple objects that 
are simply multiple faces. As such, a typical window is a face with 
a FACE/PANE that is a block that contains other objects.


Graphically, the face is represented by a region on the screen that 
has the size and offset, possibly an effect, such as coloring, blur 
or mirroring or a text attached to it, and image or other faces that 
are only visible inside that region.

A window is also a face.


To navigate to the parent face from a face, use the FACE&/PARENT-FACE 
word. Note that FACE/PARENT-FACE is many times not set by VID, which 
is sometimes problematic.


You can manipulate the face tree by adding removing objects dynamically 
and calling the SHOW function. You can also change values in existing 
face objects in the tree, such as for resizing or moving the faces 
and then calling SHOW again. You can also build a face tree entirely 
by hand, and this is usually the starting point for different layout 
engines, such as RebGUI, that simply build face trees in their own 
way.


The prototype face is FACE, which is a minimum requirement face for 
the View engine. The prototype face for a VID face, which contains 
a few more words, is SYSTEM/VIEW/VID/VID-FACE, which is the minimum 
requirement face for VID.


One condition for the face tree is to not use the same object in 
multiple locations. The VIEW or SHOW function will return an error 
if that is the case.


A simpler way is also to generate a new face tree every time you 
want to change the layout. Although this is slightly more computationally 
heavy, it allows you to manipulate the block that was passed to the 
LAYOUT function instead of manipulating the face tree directly. This 
technique is best used, when the face tree changes dramatically by 
each manipulation.


Another important concept is the DRAW engine which is a separate 
entity in REBOL2. It can be called to draw on an image bitmap, using 
the DRAW function or as in effect for a face object, by adding a 
parameter in the VID dialect block or by changing the FACE/EFFECT 
word. DRAW is used by calling a dialect. if you just want to use 
fields, buttons and simple user interface designs, you may not need 
to use DRAW.

In the script display-chess-board.r on rebol.org there is this part
   ;;  counter is now an image -  note the 'key effect 
    ;;  user to make the black in the image transparent.
    ;;  ------------------------------------------------
    counter: box 30x30 effect [key 0.0.0 oval]
 

This does not work, when keyword merge is added the middle part is 
transparent when the tuple is replaced with an integer, but only 
the other way around or the oval is limiting the working of merge 
to the inside of the circle?

RLE is better for image data. Any takers?

I made a program that embeds a dll to generate a cellular automaton 
image. Could someone test it for me?     http://pastebin.com/raw.php?i=67KtcSK3

img: make image! 88x88
img/alpha: 255

draw img [
	pen none
	fill-pen linear 0x0 0.0 88.0 90.0 1.0 1.0
		0.0.0 16.16.16 32.32.32
	box 0x0 88x88 14.0

	fill-pen linear 5x5 0.0 78.0 90.0 1.0 1.0
		102.102.102 10.10.10 10.10.10 10.10.10 0.0.0
	box 5x5 83x83 14.0
]

view layout [
	image img
]

sz: 200x400
img: make image! sz
img/alpha: 255

draw img compose [
	pen none
	fill-pen linear (as-pair 0 sz/y / 2) -50.5 70.5 90.0 1.0 1.0
			45.45.47 9.9.11 108.113.117
	circle (as-pair sz/x - 115 sz/y / 2) 70.5
	fill-pen 1.0.5
	circle (as-pair sz/x - 115 sz/y / 2) 68.5

	reset-matrix

 fill-pen linear (as-pair sz/x - 115 sz/y / 2) -60.5 30.5 45.0 1.0 
 1.0
			161.164.169 161.164.169 89.94.100

 box (as-pair sz/x - 115 - 26 sz/y / 2 - 26) (as-pair sz/x - 115 + 
 26 sz/y / 2 + 26) 10.0
	fill-pen 1.0.5

 box (as-pair sz/x - 115 - 22 sz/y / 2 - 22) (as-pair sz/x - 115 + 
 22 sz/y / 2 + 22) 6.0

	reset-matrix

 fill-pen linear (as-pair 0 sz/y / 2 - 26) -50.5 100.5 90.0 1.0 1.0
			1.0.5.255 200.214.226.224 200.214.226.128
	shape [
		move 154x200
		arc 16x200 68.0 68.0
		arc 154x200 -149.0 68.0
	]
]

view layout [
	backdrop 1.0.5
	image img
]

auto-crop-bitmap-text: func ["Returns a cropped image, or none if 
the input image was blank"
	image [image!] 
	/local region
][
	if region: find-bitmap-text-crop-region image [ 

  copy/part skip image region/1 region/2  ; return a cropped image
	]
]

Thanks......I can see now how SKIP can work on an image bitmap
    img: to-image #{....plausible hex stream....}
    skip img 2x2


However, TAKE does not work on image bitmaps.....Are there other 
types of bitmap?

:)
Is TAKE intended one day to work on image bitmaps?
Or is there another use for:
     TAKE/DEEP word 10x10

No, because TAKE removes from the original, and that would change 
the dimensions of the original in the case on an image, assuming 
it's possible (you can't take a hole from the middle, for instance). 
So you mean COPY/part here.

Well, maybe it was intended to work on image (if so, sorry). I'd 
have to review the R2/Forward code to be sure, since its version 
of TAKE would have replicated that. It's a really weird thing to 
do to an image though.

The R2/Forward TAKE makes reference to an image in its code, but 
not in its typespec. Weird. A bug?

BrianH: If I wanted to take a subsection of an image, why wouldn't 
it create a new image with just that subsection, and then replace 
the "taken" part in the old image with 0.0.0?  Or am I understanding 
the purpose of 'take incorrectly?

Kaj, do you happen to have a VMware image for version 0.6.7? I only 
saw 0.6.6 posted.

AdrianS: if you have a working 0.6.7 image for VMware, it would be 
nice if you could share it with us by sending it to Kaj (so we can 
download it from Syllable servers).

A VB image would be fine too.

I can provide the VMware image if it's useful - I've got 25 gigs 
with box.net that could be put to some use. So, are you ok to just 
have the VB image or would having both be better?

Hosting a VMware image would be great, but we have to make sure that 
it's correct

I'll wait for a proper VM image I guess.

Did you mount the image in an odd position in VMware? A normal boot 
drive is hda

Can't you mount the image as primary master in VMware?

k - I'll make an image and post a link here

It's unclear how to convert OVF to QEmu. Does the OVF contain a VMware 
VMDK disk image file?

Odd. This is another reason that the creation of our distributions 
is quite critical. Our existing VMware image is 55 MB, although that's 
for Syllable 0.6.6, which was smaller

was the prior image for an even older version of Workstation than 
6?

I'd rather just upload the VirtualBox image I have

I'd like to have your image, but this is not working

i think i have a qemu/kvm image from back when syllable desktop 0.6.7 
was released. if that's of any use, i can dig it up.

Thanks, but a QEmu image is less problematic for me to produce, because 
we have it in Syllable

No idea, sorry. I was just wondering why I created the image as a 
.vmdk, but well -- at least that seems to compress quite well.

The VB image is 10 GB; that shouldn't be the problem

I'm curious - how much traffic do you get from the image downloads?

Syllable versions have been downloaded several ten thousand times 
per version. If a version is current for a long time, the VM image 
could be downloaded twenty thousand times, for example

Got my Syllable 0.6.7 image running in VMware, thanks to AdrianS 
for making the image available!

Bo - do you remember first CID? Predecessor of VID? I can remember 
small script, which was showing image from 4 webcams, in rudiculously 
small script. That was - rebollish :-)

Important message for all R3 graphics fans:


I have finished IMAGE datatype(including all image codecs and other 
related code) change so it uses 'standard' alphachannel values (ie. 
0-trasparent 255-opaque)to be compatible with the 'rest of world'.

Without this change we would have problems to connect r3 with graphics 
systems on misc platforms/graphics frameworks etc.

This change will be in the upcoming revised R3 graphics code which 
is being worked on. So that is just FYI to avoid any duplicated efforts(in 
case you wanted to work on that in the feature).

For those interested in the "alpha-channel change":

Here is the branch with first round of related code changes to the 
image! and image codecs: https://github.com/cyphre/r3/commit/472c106a0f177ead82a6f29be1ae98b4cd33b9ad


Note: This code doesn't contain any graphics related changes...just 
the image! datatype + image codecs so you can MAKE images and load 
BMP, GIF, PNG and JPG files. But it should be enough to test the 
change.

(I have this code already intergated with changed AGG graphics and 
it works well but I haven't published it as this part is not compatible 
with the 'official' git source at the moment.)

Note2: the code was not tested on big-endian systems so it is possible 
there can be some quirks. Use at your own risk and let me know about 
any problems.


The RGBA tuples on IMAGE! now work so if the fourth(alpha) value 
is not defined it is assumed the RGB tuple is opaque (ie. alpha = 
255) so 0.0.0 = 0.0.0.255 etc. This way color values in old code 
that doesn't explicitly define alpha values are still compatible.


If you are interested, try to compile and test a bit. Let me know 
if you see any issues. Thanks.

Personally I am waiting for the updated documentation since it has 
been announced. Also I am waiting for the IMAGE datatype my personal 
application needs.

Yes, but I think Carl was talking about making it more of an integrated 
component so it can be easily accessed Rebol-style.  It's like the 
difference between loading a jpg in Rebol (it just works) or trying 
to link Imagemagick (or comparable) to load a jpg into a binary image 
format that can be modified by Rebol.

Geomol, some notest regarding alpha channel:

The alpha values seems to be left out.

I'ts not left out..that's only the way "mold" of image! datatype 
works. So I the image have "fully transparent" alphachannel it is 
just not shown by mold to make the output more readable.

But it seems, the alpha channel is separate from RGB values.

The alphachannel is always present in the image! datatype (ie. internally 
it's always 4 components = 32bit bitmap). Again it's just the way 
"molding" of the datatype displays the content.


AFAIK You can construct the image! with alphachannel in various ways 
for example:

separated alpha:

>> i: make image! [2x2 #{0102030405060708009A0B0C} #{11121314}]
== make image! [2x2 #{
0102030405060708009A0B0C
} #{
11121314
}]

same example but the RGBA compoments together:

>> i: to image! #{0102031104050612070809130A0B0C14}
== make image! [4x1 #{
0102030405060708090A0B0C
} #{
11121314
}]

>> i/size: 2x2
== 2x2

>> i
== make image! [2x2 #{
0102030405060708090A0B0C
} #{
11121314
}]

>>

Same way you can get the values in different form:

>> i/rgb
== #{0102030405060708090A0B0C}

>> i/alpha
== #{11121314}

>> to binary! i
== #{0102031104050612070809130A0B0C14}


For more I'd suggest you read the image! datatype docs here: http://www.rebol.com/docs/image.html

AFAIK The docs were written for R2 but should hold pretty much also 
for R3.

Andreas, yes exactly these considerations are important because the 
sore temptation could lead into an overload and therefore polluted 
R3 with embedded extensions beyond a usefull 'R3 with batteries included' 
;-) 

there are tons of usefull libs and free code out there, compression, 
crypto, text processing, serialisation, image manipulation, audio, 
math, ai and very important;  db connectors. filling these areas 
step by step is a lot of work but I think it's worth. As soon R3 
has reached a stable structure (couple of weeks I think) a new bounty 
system should be established for extensions we need but haven't the 
time or skills to create those. Just now I started with a simple 
one to get a feeling for the handling and any advise in this is highly 
appreciated.