Please, keep the profanity down. Re: Dealing with images (Filter 20311056)
Someone posted this message, and I'm concerned about questionable language. I use an HTML-based e-mail retrieval via Internet Explorer, but system settings may cause IE to block inappropriate web-pages (ones that contain cuss words), and as I get my e-mail via the www, a company with strict settings on the internet machines may prevent me from reading some of the postings. Apart from that, it may offend some people. This is a public mailing list, after all. Could we keep the profanity down please? It's a bit rude and may also cause problems with paranoid browsers. From: mark kandianis [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Dealing with images Date: Sun, 07 Dec 2003 19:13:54 -0500 On Sun, 07 Dec 2003 14:52:50 -0800, Alan Coopersmith [EMAIL PROTECTED] wrote: mark kandianis wrote: that's shit. I really think that's got the cart in front of the horse. I don't see the market leader(s) doing that, to make something saddled to a standards group is a reminder of why LINUX beat FreeBSD. Standards are what allow Linux to have had even a chance to be here in the first place. this from the company that has brought us solaris. (cheap shot but I like it) and as for pOSIX and linux, linux is not limited by the pOSIX standard, it makes the standard by doing it making it happen. i've seen LINUX move beyond and do things that posix has yet to endorse but does so it can be LINUX aware. making something a standard doesn't mean that anyone willl use it? tech is wrecked with lots of 'standards' that went no where. yeah the internet took off. darpa made it happen. lots of govt money can make anything happen. mark If it wasn't for open standards, the Internet wouldn't exist in it's current form - all we'd have is AOL Compuserve with their proprietary formats, and anyone wanting to compete would have to be constantly reverse engineering to be able to interoperate at all (as you can see in the word processor market, where Microsoft changes its file formats every release, and everyone else wastes a ton of effort reverse engineering in order to be compatible). hey wanna buy a standard cheap? i'll sell in on ebay. goes to highest bidder ;-) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Shop online for kidsÂ’ toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Dealing with images
Hi all, I posted the following message to the Xouvert list. I know that cross-posting to different lists is not generally a good idea, but I maybe somebody might be interested in this. -- Forwarded Message -- Subject: Dealing with images Date: Sunday 07 December 2003 16:39 From: Gian Filippo Pinzari [EMAIL PROTECTED] To: General discussion about the Xouvert X server [EMAIL PROTECTED] On Sunday 07 December 2003 05:05, Herbert Snorrason wrote: Now the question is: Who won't want it? PNG is in nearly every way *the* lossless raster format. Nearly everyone with X is going to have libpng available. It would, frankly, make sense to promote it to a default format for any and all bitmap graphics. I'm personally advocating addition of PNG and JPEG support to the X protocol since long. Translation of X bitmaps to PNG and JPEG is in already NX. Images are decompressed back to X bitmaps by the X server side proxy. Only 'NX aware' X clients can use it as it's not a standard X extension and you need to run the NX proxy system, so it's clearly not a general solution. In NX we need our own Xlib to make this available to all X clients and this is even more clumsy. When I'm saying that advocating PNG and JPEG addition, I'm not talking about XIE. I'm talking about a way to: - Save bandwidth sending images in a more compact format. - Allow clients to 'stream' images on the link and be notified when the image has been completely recomposed at the X server side. Additional functionalities (all implemented in NX) that could greatly improve network efficiency are: - Separate alpha channel from the PutImage X bitmap so alpha (highly compressible) can be cached/compressed as a separate message. This would allow to add alpha to JPEG or other image formats that don't natively support it. - Store 'colortables' in the X server to be used to decompress the X bitmaps, again as a separate (highly cacheable) protocol message. I'm not talking about the existing X colormaps here, but the mapping of values to pixels of the TrueColor visual, to be used to decompress the image. - Store images at X server side and let clients verify if the image needs to be transferred over the link. X server could store PNG an JPEG images in memory or disk and decompress them on the fly, when needed. This is different in respect of pixmaps. Clients couldn't manipulate the image, just copy (that is uncompress) the image to the drawable. - Support other pluggable image formats, such as MS RDP bitmaps or RFB screen updates in different encodings. Looking even further, I think that X needs to deal with the problem of transferring huge amounts of bitmap data over the network in a smarter and definitive way. I'm sure that many people will say that X clients should simply forget X bitmaps and use SVG or other vector graphics. How these people are going to run a X video-conferencing application or a media player over the network? They don't say. They just wonder why you would ever want to do that. What I propose is to make the PutImage request obsolete (note, only the request, not the idea that clients need bitmaps) and let clients use arbitrary image streaming codecs. The X client should be able to query which codecs are available, create a 'stream' object and add 'frames' to it. The X server should decompress the frames to a virtual frame-buffer and provide a way to CopyArea from the frame buffer to the drawables. Then clients should be able to use all the usual X protocol requests to manipulate the drawable and display their output. I started to talk about this with Leon Shiman of MAS but we didn't have a chance yet to discuss the technical details. Clearly this overlaps in many ways with what MAS is doing. There is a big difference, anyway. MAS is intended to deal with streaming and displaying of real time MM contents while our scope is session persistency, compression and network efficiency. MAS is the solution for MM (but, as I said to Leon, the project needs to leave the lab and go in the wild) but we still need a way to manage images in average X clients (web browsers, office automation applications) that don't have time requirements but can't afford to loose data due to the stateful nature of X protocol. Regards, /Gian Filippo Pinzari. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
It'll take more than advocacy to make it a standard. I don't need to tell you, I'm certain, that in Open Source software the best way to make things happen is to do them. To be a Standard though, you need to write a specification and have it go through X.org's standardization process. A proof of concept, in the form of an implementation, is useful too. X.org is currently in the process of aligning its processes with the open source movement. The legal framework is expected to be in place by the first of the year. Even though that part won't be ready for a few more weeks, X.org has already begun the other part by sponsoring an open development source tree on freedesktop.org. This tree will become the basis for X.org future releases. Commit privileges in the X.org tree are free for the asking -- you do your work on a branch and when the X.org community agree, your work will be merged into the main branch and become part of the next release. The people doing Cygwin-X have already started working in the X.org tree. -- Kaleb S. KEITHLEY Gian Filippo Pinzari wrote: Hi all, I posted the following message to the Xouvert list. I know that cross-posting to different lists is not generally a good idea, but I maybe somebody might be interested in this. -- Forwarded Message -- Subject: Dealing with images Date: Sunday 07 December 2003 16:39 From: Gian Filippo Pinzari [EMAIL PROTECTED] To: General discussion about the Xouvert X server [EMAIL PROTECTED] On Sunday 07 December 2003 05:05, Herbert Snorrason wrote: Now the question is: Who won't want it? PNG is in nearly every way *the* lossless raster format. Nearly everyone with X is going to have libpng available. It would, frankly, make sense to promote it to a default format for any and all bitmap graphics. I'm personally advocating addition of PNG and JPEG support to the X protocol since long. Translation of X bitmaps to PNG and JPEG is in already NX. Images are decompressed back to X bitmaps by the X server side proxy. Only 'NX aware' X clients can use it as it's not a standard X extension and you need to run the NX proxy system, so it's clearly not a general solution. In NX we need our own Xlib to make this available to all X clients and this is even more clumsy. When I'm saying that advocating PNG and JPEG addition, I'm not talking about XIE. I'm talking about a way to: - Save bandwidth sending images in a more compact format. - Allow clients to 'stream' images on the link and be notified when the image has been completely recomposed at the X server side. Additional functionalities (all implemented in NX) that could greatly improve network efficiency are: - Separate alpha channel from the PutImage X bitmap so alpha (highly compressible) can be cached/compressed as a separate message. This would allow to add alpha to JPEG or other image formats that don't natively support it. - Store 'colortables' in the X server to be used to decompress the X bitmaps, again as a separate (highly cacheable) protocol message. I'm not talking about the existing X colormaps here, but the mapping of values to pixels of the TrueColor visual, to be used to decompress the image. - Store images at X server side and let clients verify if the image needs to be transferred over the link. X server could store PNG an JPEG images in memory or disk and decompress them on the fly, when needed. This is different in respect of pixmaps. Clients couldn't manipulate the image, just copy (that is uncompress) the image to the drawable. - Support other pluggable image formats, such as MS RDP bitmaps or RFB screen updates in different encodings. Looking even further, I think that X needs to deal with the problem of transferring huge amounts of bitmap data over the network in a smarter and definitive way. I'm sure that many people will say that X clients should simply forget X bitmaps and use SVG or other vector graphics. How these people are going to run a X video-conferencing application or a media player over the network? They don't say. They just wonder why you would ever want to do that. What I propose is to make the PutImage request obsolete (note, only the request, not the idea that clients need bitmaps) and let clients use arbitrary image streaming codecs. The X client should be able to query which codecs are available, create a 'stream' object and add 'frames' to it. The X server should decompress the frames to a virtual frame-buffer and provide a way to CopyArea from the frame buffer to the drawables. Then clients should be able to use all the usual X protocol requests to manipulate the drawable and display their output. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
On Sun, 07 Dec 2003 12:15:07 -0500, Kaleb S. KEITHLEY [EMAIL PROTECTED] wrote: It'll take more than advocacy to make it a standard. I don't need to tell you, I'm certain, that in Open Source software the best way to make things happen is to do them. To be a Standard though, you need to write a specification and have it go through X.org's standardization process. that's shit. I really think that's got the cart in front of the horse. I don't see the market leader(s) doing that, to make something saddled to a standards group is a reminder of why LINUX beat FreeBSD. FBSD was tied to that old war horse, Telephone, and following standards and they lost. Linux followed a standard that a genius created and made it happen. throw out the standards group and just take hold of the standard by being there. the group will follow as they can't think just react. Linux proves it. Linux is god. mark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
mark kandianis wrote: that's shit. I really think that's got the cart in front of the horse. I don't see the market leader(s) doing that, to make something saddled to a standards group is a reminder of why LINUX beat FreeBSD. Standards are what allow Linux to have had even a chance to be here in the first place. If it wasn't for open standards, the Internet wouldn't exist in it's current form - all we'd have is AOL Compuserve with their proprietary formats, and anyone wanting to compete would have to be constantly reverse engineering to be able to interoperate at all (as you can see in the word processor market, where Microsoft changes its file formats every release, and everyone else wastes a ton of effort reverse engineering in order to be compatible). And even the market leaders of Microsoft and Apple participate in standards groups such as the IETF and W3C. The original post pointed out that the image formats used by NX weren't as useful as they could be, because only NX supported them - the solution to that is to get everyone to agree to include it in a standard - otherwise, it will remain something that you can't use with everyone else's software. Linux followed a standard that a genius created and made it happen. Actually, Linux started out following the POSIX standard that a standards group created to make sure all UNIX-like OS'es were compatible, so that all the existing software like gcc, emacs, X, etc. for those other OS'es could be used on Linux. Without that, Linux would probably have gone the road of BeOS - an interesting concept that never really caught on since it had few useful applications. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
On Sun, 07 Dec 2003 12:15:07 -0500, Kaleb S. KEITHLEY [EMAIL PROTECTED] wrote: It'll take more than advocacy to make it a standard. I don't need to tell you, I'm certain, that in Open Source software the best way to make things happen is to do them. To be a Standard though, you need to write a specification and have it go through X.org's standardization process. A proof of concept, in the form of an implementation, is useful too. X.org is currently in the process of aligning its processes with the open source movement. The legal framework is expected to be in place by the first of the year. Even though that part won't be ready for a few more weeks, X.org has already begun the other part by sponsoring an open development source tree on freedesktop.org. This tree will become the basis for X.org future releases. Commit privileges in the X.org tree are free for the asking -- you do your work on a branch and when the X.org community agree, your work will be merged into the main branch and become part of the next release. The people doing Cygwin-X have already started working in the X.org tree. -- Kaleb S. KEITHLEY so this is basically an advertisement? don't waste my time or bandwidth. i thought you had something to say. mark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
On Sun, 07 Dec 2003 14:52:50 -0800, Alan Coopersmith [EMAIL PROTECTED] wrote: mark kandianis wrote: that's shit. I really think that's got the cart in front of the horse. I don't see the market leader(s) doing that, to make something saddled to a standards group is a reminder of why LINUX beat FreeBSD. Standards are what allow Linux to have had even a chance to be here in the first place. this from the company that has brought us solaris. (cheap shot but I like it) and as for pOSIX and linux, linux is not limited by the pOSIX standard, it makes the standard by doing it making it happen. i've seen LINUX move beyond and do things that posix has yet to endorse but does so it can be LINUX aware. making something a standard doesn't mean that anyone willl use it? tech is wrecked with lots of 'standards' that went no where. yeah the internet took off. darpa made it happen. lots of govt money can make anything happen. mark If it wasn't for open standards, the Internet wouldn't exist in it's current form - all we'd have is AOL Compuserve with their proprietary formats, and anyone wanting to compete would have to be constantly reverse engineering to be able to interoperate at all (as you can see in the word processor market, where Microsoft changes its file formats every release, and everyone else wastes a ton of effort reverse engineering in order to be compatible). hey wanna buy a standard cheap? i'll sell in on ebay. goes to highest bidder ;-) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
mark kandianis wrote: and as for pOSIX and linux, linux is not limited by the pOSIX standard, it makes the standard by doing it making it happen. i've seen LINUX move beyond and do things that posix has yet to endorse but does so it can be LINUX aware. All interesting OS'es have extensions beyond the core POSIX standards, but those are often sources of great problems when trying to make portable software such as XFree86. The original question asked about getting it into the standard presumably to avoid such problems. XFree86 already has a number of extensions beyond the core standards - it would be easy to create another one there, but then there's no guarantee of interoperability with other OS'es, and different OS'es end up with different versions, or none at all - a situation you can see today with XFree86 non-standard extensions such as Render or RandR. If all you care about is OS'es which run XFree86, that's not a problem - but that may not even be all Linux distributions in the future if any of them decide to start shipping the Xouvert or freedesktop.org or some other X server instead. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
Hi Kaleb, On Sunday 07 December 2003 18:15, Kaleb S. KEITHLEY wrote: To be a Standard though, you need to write a specification and have it go through X.org's standardization process. A proof of concept, in the form of an implementation, is useful too. We have the proof of concept. Should we write such a X image compression and streaming specification and submit it for approval to the X consortium? Such an extension would be useless without clients leveraging it. I'm speaking about GNOME, KDE, Mozilla, OpenOffice, Evolution and I could name many more. We need the support of the X developers otherwise it's better to use our time and resources to write a layer that don't need X apps to be aware of it. We already have hard time making a living out of writing OSS software, so I don't think we'll follow the Rule and spend development time and resources in something that, maybe, nobody will ever use. Does OSS development always follow the Rules? Fortunately not. Look at the XDamage extension. There were some talks and a sample implementation from Havoc. It solved a very real problem, so everybody agreed on it. Keith Packard wrote the specification, a better version of the code and it immediately went into the freedesktop X server. As often happens in the OSS world, somebody comes with a solution, then the OSS world elaborates it, improves it, plugs the holes and makes it a standard. We would like to follow the same OSS rule. Unfortunately we are still at the stage that most X people seem to completely ignore (or consider not worth of mention) the work we have done and the problems we are trying to solve. Obviously I think they are wrong, otherwise I would have already stopped complaining in mailing lists ;-). I'm just starting to believe that also the OSS world suffers of the 'not invented here' syndrome. I carefully read the Open Source Desktop Technology Road Map of Jim Gettys: http://freedesktop.org/~jg/roadmap.html It doesn't make any mention of NX. This is really sad. I'm sure Jim knows about our software, so I must argue that he thinks that X doesn't need specific X protocol compression, X image encoding and streaming, a X agent system resolving round-trips at application server side, embedding of different remote desktop protocols in X, a proxy system implementing bandwidth control, encryption, transport over a RTP network, session initiation through SIP and other things we instead need in NX. Should we write a specification for each functionality and wait the X developers to embrace them? It would be fantastic, but I don't think we have the money to live long enough to see this happen. I read in the previous document that Jim Gettys thinks that ssh -X -C or VNC are good enough for most remote computing needs. Well, I think that the proof of the pudding is in eating. I would really like to know if Jim Gettys has ever tried our software and if he had a chance to run it, side by side, with ssh -X -C or VNC. Many X people seem to forget that there is a company whose name is Citrix and another company whose name is Microsoft that have nearly the 100% of the remote computing market. Probably these X people should rather argue that ssh -X -C is no-good. Some weeks ago we received an e-mail from a company that qualified itself as a Citrix partner since 10 years. They told us that they had tried NX and were stunned by the performances. It was the first time, since 10 years, that they had something that could beat Citrix. They are now in the process of becoming distributors. And, yes, they had tried ssh -X -C and VNC. I read again the thread about NX in the old XFree86 forum. The point of Keith Packard and Jim Gettys was that the work that is taking place at freedesktop.org should make possible to run remote X applications with the same efficiency and with the same features provided by NX without any of the NX solutions to the problem. I studied the papers but I don't see any solution to the X image encoding and streaming problem, so I think this is a good place to start working together. And I hope, Kaleb, that your suggestion is not to do all the work by ourselves ;-). Kind regards, /Gian Filippo Pinzari. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
