technology behind Morpheus ....
[1/22] from: petr::krenzelok::trz::cz at: 30-Oct-2001 12:49
Hi, just curious - is REBOL technologically able to keep up to what can be found on following site? : http://www.musiccity.com/technology.htm Note: FastStream, SmartStream technology (probably yes), Embedded Microsoft Media player, automatic network and CPU throttling ... -pekr-
[2/22] from: nitsch-lists:netcologne at: 30-Oct-2001 16:59
RE: [REBOL] technology behind Morpheus .... [Petr--Krenzelok--trz--cz] wrote:
> Hi, > just curious - is REBOL technologically able to keep up to what can be
<<quoted lines omitted: 3>>> Microsoft Media player, automatic network and CPU throttling ... > -pekr-
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
[3/22] from: petr:krenzelok:trz:cz at: 30-Oct-2001 18:34
>RE: [REBOL] technology behind Morpheus .... >[Petr--Krenzelok--trz--cz] wrote:
<<quoted lines omitted: 16>>>"special friend" - hooks in rebol? >hopefully.
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-
[4/22] from: jseq:mediaone at: 30-Oct-2001 12:49
IIRC, Morpheus uses an embedded control for their video display. Equivalent REBOL support for multimedia could mean just launching a browser, as Holger has mentioned in the past. Architecturally, I bet REBOL will probably be used to make a UI (Morpheus is very simple) which calls into the FastTrack C library, and the press release suggests that the combo will probably provide some Groove-like deployment options for 3rd party applications. Not to be overlooked is that you'll already have a Hailstorm-like 30M active user accounts. That's so cool. My biggest disappointment with Groove is that they didn't choose a lightweight xplatform scripting environment for their dev kit. In addressing this complaint, I think REBOL+Morpheus as p2p deployment platform could be absolutely awesome. Two cautionary notes: Historically, the FastTrack folks that make the underlying p2p technology haven't been big fans of open source. They've tried to shut down open source clients in the same way AOL's Instant Messenger has. That doesn't excite me. Also, both companies (FastTrack and Morpheus) are being sued by the RIAA. Their future is pretty uncertain. More incentive to make the transition to Groove-competitor ASAP. JS
[5/22] from: greggirwin:mindspring at: 30-Oct-2001 12:17
Hi John, << Not to be overlooked is that you'll already have a Hailstorm-like 30M active user accounts. That's so cool. >> Right! Now how do we get paid when people use our services or apps? If there is a transparent mechanism in there, developers will flock to it IMO and you'll have all the content you can handle. << Also, both companies (FastTrack and Morpheus) are being sued by the RIAA. Their future is pretty uncertain. More incentive to make the transition to Groove-competitor ASAP. >> An excellent point. Here's a news snippet about them getting away from just music sharing: 'The move appeared to be one attempt to establish that the software has substantial non-infringing uses, a legal term of art that can protect whole technologies from being ruled illegal. The VCR, for example, was protected by the courts in a suit by movie studios because it can be used for many things other than making copies of copyrighted movies.' So, it's up to us to create those "substantial non-infringing uses" with REBOL. The question(s) are what and how? RT and StreamCast must have some core concepts laid out about how this is all going to work and, if they want some REBOL apps ready to roll along with them, they will need to let us know how to build them so they fit in there as seamlessly as possible and exploit the new world paradigm. --Gregg
[6/22] from: rpgwriter:y:ahoo at: 30-Oct-2001 11:25
--- John Sequeira <[jseq--mediaone--net]> wrote:
> Also, both companies (FastTrack and Morpheus) are > being sued by the RIAA. Their future is pretty > uncertain. More incentive to make the transition to > Groove-competitor ASAP.
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...
[7/22] from: carl:rebol at: 30-Oct-2001 12:04
Actually, Holger recently rewrote the entire effect pipeline when he added alpha channels. :) That sounds like a priority to me. Regarding Morpheus and multiplatform, it will take a few revs, but it is a goal.
[8/22] from: ammonjohnson:yah:oo at: 30-Oct-2001 15:18
----- Original Message ----- From: "Petr Krenzelok" <[Petr--Krenzelok--trz--cz]> To: <[rebol-list--rebol--com]> Sent: Tuesday, October 30, 2001 4:49 AM Subject: [REBOL] technology behind Morpheus ....
> Hi, > > just curious - is REBOL technologically able to keep up to what can be > found on following site? : > > http://www.musiccity.com/technology.htm > > Note: FastStream, SmartStream technology (probably yes),
>Embedded Microsoft Media player, automatic network and CPU throttling ...
It would suprise you what is under the hood of the next release! (just an uninformed believer. ;)) Enjoy!! Ammon
[9/22] from: doncox:enterprise at: 30-Oct-2001 22:52
On 30-Oct-01, Carl Sassenrath wrote:
> Actually, Holger recently rewrote the entire effect pipeline when he > added alpha channels. :) That sounds like a priority to me.
<<quoted lines omitted: 9>>>> case of Morpheus deal? Are we going to stay multiplatform with >> Morpheus?
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]
[10/22] from: warp:reboot:ch at: 30-Oct-2001 23:25
any plan in using quicktime as media handler ? quicktime = more than 200 media format supported what will rebol/view & quicktime be compared to morpheus ? woudn't be possible to make a rebol quicktime 5 extension so that there is a rebol track in quicktime that can control all other tracks? So we have rebol on top. (more_info: http://developer.apple.com/techpubs/quicktime/qtdevdocs/) have a nice day Will Arp Rebol And Mac enthusiast On 30.10.2001 21:04, Carl Sassenrath <[carl--rebol--com]> wrote:
[11/22] from: holger:rebol at: 30-Oct-2001 14:57
On Tue, Oct 30, 2001 at 12:04:46PM -0800, Carl Sassenrath wrote:
> Actually, Holger recently rewrote the entire effect pipeline when he added alpha channels. :) That sounds like a priority to me.
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]
[12/22] from: arolls:idatam:au at: 31-Oct-2001 11:06
Aha!! Goody! The good news just keeps coming. :) Good work, Holger! Oh Alpha channel, oh alpha channel... May I request that you dump your working test scripts to the list here? Even if some will not work 100% in the final release, it will speed up some of us getting examples into the library. Anton.
[13/22] from: ptretter:charter at: 30-Oct-2001 19:41
wow!... So when the is the new engine hitting the streets? ;) ... you should of known that was coming. Paul Tretter
[14/22] from: gchiu:compkarori at: 31-Oct-2001 18:55
> 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.
Is this an upgrade to WinUAE ? -- Graham Chiu
[15/22] from: carl:cybercraft at: 31-Oct-2001 21:53
On 31-Oct-01, Graham Chiu wrote:
>> 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. > Is this an upgrade to WinUAE ?
See here Graham... http://www.amithlon.net/ -- Carl Read
[16/22] from: cyphre:seznam:cz at: 31-Oct-2001 10:28
Congratulations Holger, Second great Rebol news in last two days! ;) Keep up "multimedializing" Rebol! regards Cyphre PS: Looks like I'll have to postpone some fo my projects but it will worth wait for it.
[17/22] from: petr:krenzelok:trz:cz at: 31-Oct-2001 13:08
> On Tue, Oct 30, 2001 at 12:04:46PM -0800, Carl Sassenrath wrote: > > Actually, Holger recently rewrote the entire effect pipeline when he added alpha channels. :) That sounds like a priority to me. > > Ok, so the cat is out of the bag. Some more infos on that, because Petr > is going to ask anyway :).
Heh, Holger, how do you know? :-))
> All of these changes are expected to be in Express 1.0 and the next View > release (no release date yet).
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-
[18/22] from: g:santilli:tiscalinet:it at: 31-Oct-2001 15:07
> - to-image on a face does NOT return alpha information. It returns
Why not? That would be useful IMHO.
> - Previously the effect pipeline had an undocumented side effect, that > if the face was transparent and did not have an image, the effects
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/
[19/22] from: media:quazart at: 31-Oct-2001 10:27
----- Original Message ----- From: <[holger--rebol--com]>
> - REBOL uses what are refered to as "non-premultiplied transparency" > alpha values. The "transparency" indicates that the alpha channel
<<quoted lines omitted: 3>>> the color information does not have to be adjusted when the alpha > value is changed.
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
[20/22] from: holger:rebol at: 31-Oct-2001 9:18
On Wed, Oct 31, 2001 at 10:27:39AM -0500, Media wrote:
> 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
<<quoted lines omitted: 3>>> 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?"...
Could you provide a reference, please ?
> nice work!
Thanks :) -- Holger Kruse [holger--rebol--com]
[21/22] from: doncox:enterprise at: 31-Oct-2001 18:45
On 31-Oct-01, Graham Chiu wrote:
>> 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. > > Is this an upgrade to WinUAE ?
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]
[22/22] from: media:quazart at: 31-Oct-2001 13:42
reply inline... ----- Original Message ----- From: <[holger--rebol--com]> To: <[rebol-list--rebol--com]>
> > 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
> > do perform it with several effects operations in the effects tree).
> > without it, PRACTICALLY ALL 3d rendered images using mattes will be > > DESTROYED by comping. also note that if this subject isn't covered at
> > in part in the docs, you probably will get many support calls of the
> > of: "why does my image have a dark-grey edge?"... > > Could you provide a reference, please ? >
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
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted