technology behind Morpheus ....

I think rebol got contact to some multimedia-programmers with that? able to do stuff in downloadable sizes? understanding networks? if they are partners Carl would give them some special friend - hooks in rebol? hopefully. -Volker

Well, hopefully. And I would like if Holger could elaborate on this a little bit. As RT is not too much multimedia friendly - some few months ago they told us effect pipeline in user level is not priority. It was just an example :-) Some time ago Holger also mentioned platford specific hooks - e.g. Arexx on Amiga, so I am just curious, how does RT solve it in the case of Morpheus deal? Are we going to stay multiplatform with Morpheus? -pekr-

Partnering with RT may actually, in part, be a defensive strategy for those suits. Part of what hurt Napster, IIRC, was that it was all content distribution, and a very high proportion of that shady content. With this deal, it will be harder for a court to see the companies involved as principally facilitating infringement -- heck, they are providing a platform for application delivery. Considering that the *commercial* viability of non-infringing uses is, IIRC, an element considered in some of the cases, developing a commercially viable, easy for courts to understand, clearly distinct from the uses the RIAA is suing over, application of their technology is a smart move...

Definitely!

It would suprise you what is under the hood of the next release! (just an uninformed believer. ;)) Enjoy!! Ammon

May I comment as an Amiga user and long time Rebol lurker ? I have View installed on my main Amiga, and it works fine but is really too slow on the 68060 processor - especially scrolling. However, I have just received the new Amithlon CD, which effectively turns a standard PC into an Amiga. You now have the possibility of an Amiga running at effective speeds of 700MHz and above. It looks as though this product will sell rather well to many former Amiga users. It will also be ideal for compiling Amiga software. So I hope that Rebol will continue to support the Amiga platform, and allow us all to join in this big step forward with Morpheus. (One problem on Amiga is the difficulty of buying a good TCP stack.) Regards -- Don Cox [doncox--enterprise--net]

Ok, so the cat is out of the bag. Some more infos on that, because Petr is going to ask anyway :). All of these changes are expected to be in Express 1.0 and the next View release (no release date yet). - REBOL uses what are refered to as "non-premultiplied transparency" alpha values. The "transparency" indicates that the alpha channel describes the amount of transparency, not opaqueness, so 0 means solid and 255 means fully transparent. "non-premultiplied" means that you can change alpha and color values independently, i.e. the color information does not have to be adjusted when the alpha value is changed. - The image! datatype supports alpha information. Color tuples now contain a fourth byte, with the alpha channel. You can still use 3-byte tuples though to "change" an image. - PNG and GIF loaders and the PNG saver support alpha channel data. The BMP and JPEG formats do not support transparency. - Molding an image includes alpha data if the image contains some transparent section. Upward and downward compatibility for load and mold with older REBOL versions is ensured. - The effect pipeline supports alpha information, i.e. all alpha information (including alpha information from the image associated with a face and temporary alpha information, e.g. for keying) is kept during effect processing, and at the end the image is composited onto the background using the alpha channel. - to-image on a face does NOT return alpha information. It returns the face contents after compositing it onto the background. Also, don't expect windows to be transparent just because they contain an image with alpha data :-). - All effects can now be used in any combination and in any order. This includes things like "key" followed by "luma", which previously produced unpredictable results. Keying is resolved into alpha channel information whenever necessary, allowing you to process keyed images by other effects without affecting the background, or even to stack "key" effects for multiple keyed colors. - The "shadow" effect supports images with alpha data, i.e. a partially transparent pixel throws a shadow that is less dark, and the shadow of another pixel (if any) shines through :-). Also, the "shadow" effect no longer renders the image and shadow immediately, but rather keeps both around in a single, combined image, with the shadow represented by alpha data. This allows you to post-process an image with other effects after applying the shadow effect. - The "shadow" effect now enlarges the image to allow the complete image to throw a shadow. Of course in order to see it completely your face as to be large enough as well. - Added "shadow smooth" effect for shadows with smooth edges. - Some bug fixes and performance improvements in the effect pipeline. - Added "anti-alias" effect. It performs minor, non-aggressive alpha-based anti-aliasing on the borders of images. - Added "func" effect. This allows you to call a REBOL function from within the effect pipeline, manipulate the current image (including its alpha information) and pass an image back to the effect pipeline. - There will probably be a way to copy data around between the alpha plane and other color planes, and between images, e.g. to use a color plane or the grayscale value of some other image as the alpha channel in the current image, but we do not have full specs on that yet. Changes that affect compatibility with existing scripts: - The shadow effect has changed. Instead of "shadow 1.2.3", with a color value, it now uses the current key color, to be set by "key", i.e. use "key 1.2.3 shadow" instead of "shadow 1.2.3". The idea is that "key" sets the key color, and other words such as "shadow" set the keying mode (with the default being regular chroma/luma-keying, depending on whether you pass a tuple or an integer). In the future there might be more keying modes. - Previously the effect pipeline had an undocumented side effect, that if the face was transparent and did not have an image, the effects would not apply to the face, but rather to the background behind the face. This would allow you to create faces that act as filters. Because of the implied transparency caused by alpha channels, this side effect no longer exists, i.e. an effect always applies to the image itself, never to the background. You can still create faces that act as filters, but you need to tell the system about that. The effect keyword for that is "merge". It can appear anywhere in an effect block, but will most commonly appear at the beginning. What "merge" does is merge the image currently in the pipeline with the background behind the face, using alpha-based compositing. The result is then used as the current pipeline image. If there is no current image then just the background itself is used. For instance, if you previously used [colorize 255.0.0] to colorize the background behind a face red you now have to use [merge colorize 255.0.0]. - Some effects would previously allow you to pass a color value as an integer! instead of a tuple!. This has never been documented and has now been removed to allow integer arguments to fulfill a different purpose with some effects in the future. - "pick"ing a color value from an image now returns a four-byte tuple, with the fourth byte being the alpha information. The only compatibility issue here is that if you compare the returned color value directly to a 3-byte tuple using "=" or "<>" you may get wrong results. Comparisons of the type "<", ">", "<=" and ">=" should work correctly though. -- Holger Kruse [holger--rebol--com]

Is this an upgrade to WinUAE ? -- Graham Chiu

See here Graham... http://www.amithlon.net/ -- Carl Read

Heh, Holger, how do you know? :-))

OK, great changes! So few questions anyway ;-)): - some weeks ago you also mentioned fixed View timers granularity - will the change be ready for Express 1.0 release too? (Cyphre - hurry to ask about your recursive face timers removal issue, while Holger is here to respond :-) -pekr-

Why not? That would be useful IMHO.

Undocumented? I think it was documented by Carl's demos. :-) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

being of the high-end (discreet flame-inferno / AVID DS / nothing real SHAKE) compositing trade, its nice to see that you seem to have gone in-depth with comping and alpha usage. This is one of the best description of the ages-old pre vs. un-premultiplied issue... you'd be surprised how many high-level artists don't completely understand this. And thanks for NOT using pre-multiplied compositing, which in the context of building UI's would REALLY have been a drag... by what I have read in the original mail I understand that images will be allowed to have varying levels of grey in their alpha channels or that it will be able to push one into the image at run-time... but I must ask one thing to be included as an effect word... a Matte Divide (MDiv) function... (or at least a doc with a description of the way do perform it with several effects operations in the effects tree). Cause without it, PRACTICALLY ALL 3d rendered images using mattes will be DESTROYED by comping. also note that if this subject isn't covered at least in part in the docs, you probably will get many support calls of the likes of: "why does my image have a dark-grey edge?"... nice work! and thanks for the in-depth update ... we'll all code with that information in mind (especially with the planned differences and won't use the specified undocumented "features" anymore)... -Max

Yes.

Could you provide a reference, please ?

Thanks :) -- Holger Kruse [holger--rebol--com]

It uses the same JIT engine, but otherwise is different. Windows is not involved. A customised Linux kernel is used to handle booting and setting up the emulator; while this is happening, a bouncing boing ball displays on the screen. Main limitation is that there are drivers for only a few graphics cards. If no driver, you get VESA. The stated aim is to turn a PC into an Amiga. Of course the PC floppy drive hardware can't read Amiga disks and doesn't know that floppies are removable media, so there are limits. SCSI is supported. Main thing is, it should run Rebol nice and fast. Regards -- Don Cox [doncox--enterprise--net]

way

Cause

least

likes

yes Sir! on this page: http://www.nothingreal.com/support/downloads/shake_miscUtilities.shtml near the bottom, there is a link to download and install this file: http://www.nothingreal.com/support/downloads/data/shake-course-nt-v1.01.exe this is taken from parts of a general compositing bible... (who's reference is also on that page) The author, Mr Ron Brinkman who is recognized as a reference in the industry (Whom I've met personally and is a very nice fellow) gave a seminar at SIGGRAPH on compositing a while back... His book on compositing is considered by many to be THE compositor's bible. It explains many advanced compositing issues in extreme detail while keeping the language quite easy to understand. Also note that he does not use ANY software as reference, he explains the concepts by themselves... He also keep a nice friendly approach in his writing style... basically, when you have pre-multiplied images, you must divide the rgb color value by the alpha channel. (or multiply its inverse ;-) This text is quoted from Mr.Brinkman's file above when installed, chapter 5.3: 5.3 The Image-Matte Relationship You may come across the term 'Premultiplied Image', which refers to an image whose Red, Green and Blue channels have already been multiplied by a matte channel. This is almost always the type of element produced by 3D rendering software. You may also often wish to produce 'Pre-Comped', 4-channel elements that have already been pre-multiplied by their matte channel. You need to understand exactly how your compositing system deals with premultiplied elements. Some systems assume that the 'Over' operator will be fed such images by default, others may require that image and matte are brought in seperately and recombined before the 'Over' is performed. It is very important to understand that the relationship between image and matte can dramatically affect the results of an Over. Let's look at some different scenarios. We'll be using an example with a very soft-edged matte, since this is the most problematic situation. Consider Example 23. This is a premultiplied image over a background in a system that assumes you're feeding it premultiplied images. Example 24 is an Unpremultiplied image over a background in a system that assume you're feeding it premultiplied images. Note that the foreground element, in areas where it's matte is supposed to be Zero, is appearing as a 'ghost' image. If you were to check out the math of what is happening, you'll see that in those areas of the result image, it is exactly the same as if we had simply added the two images together. Example 25 is a premultiplied image over a background in a system that assumes all images sent to it are not premultiplied. Such a system will automatically multiply the image by its matte channel. In this situation, we have effectively multiplied the image by its matte channel twice thereby darkening all areas of soft-edged matte. Consequently, there is a dark halo around the foreground. As you can see, dramatic problems can arise when you feed an Over something it doesn't expect. The same sort of problems can arise when color-correcting premultiplied elements. In a premultiplied, 4-channel image, the image and the matte channels have a specific relationship that can cause compositing artifacts if altered. Because inevitably you will find yourself with a need to color-correct a premultiplied image, there is usually a tool on most systems to temporarily 'undo' the premultiplication, at least in the critical areas of the image. We will call refer to this tool by the rather unwieldy name of 'Un-Premultiply'. Essentially, the tool re-divides the image by its own matte channel, which has the effect (except in areas where the matte is solid black, or zero) of boosting the areas which were attenuated by a partially transparent matte, back to approximately their original values. If your system does not have an explicit tool to perform this operation, you can hopefully use some other tool to 'fake it'. For example, if there is a simple parsing language, you can do: R = R/M G = G/M B = B/M (and hope that you don't get divide-by-zero errors). Once your image has been unpremultiplied, apply any necessary color-corrections. Then you can re-premultiply by the original matte channel, once again producing an element whose image-to-matte relationship is correct. NOTE: For slight color corrections, or when using images which have very hard-edged mattes, you may get perfectly acceptable results without going through this process. If it looks correct, it is correct. " I hope this helps... if you have other questions... I'm always on the list! cheers! -Max ----------------------------------------- Maxim Olivier-Adlhoch, Technical Director -------------------------------------- Quaz'Art media design montreal, quebec tel: 514-273-5221