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
[nitsch-lists--netcologne--de] wrote:
>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:yah:oo 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),
Definitely!
>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
[holger--rebol--com] wrote:
> 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
[holger--rebol--com] wrote:
> - 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...
Yes.
> 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
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?"...
>
> 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
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted