While the AFPL is a non-DFSG license designed in large part to support an OEM licensing business, it also has three important freedoms that appear to be missing from the SPL:
1. Fork rights. You are perfectly free to take AFPL code, make your own modifications, and release that code under the AFPL. This distinguishes the AFPL from most other "almost free" licenses.
2. Commercial use. AFPL code is free for commercial use. An example is ps2pdf.com, which is an advertiser supported site using AFPL Ghostscript.
3. No grantback. If you make custom modifications for in-house use, you are not obligated to grant those modifications to the original author. Further, if you release a forked version under the AFPL, you are not obligated to license that code back to the original author so they can OEM license it.
In my opinion, the only significant right lacking from the AFPL is commercial redistribution without compensation. While people obviously disagree with this, my personal opinion is that it is not anywhere nearly as important as the other free software rights, especially now that free distribution over the Internet is ubiquitous. I frankly don't see why it's so important for Red Hat to make money from selling our code without compensating us in any way for our work.
Ghostscript has a fourth freedom guarantee, which is that major AFPL releases are re-released under the GPL a year later. Thus, the extra rights granted to us as commercial Ghostscript developers is fairly small and definitely time-limited. As long as we continue to improve Ghostscript actively, the AFPL version is valuable. As soon as we stop doing our job, it falls into the hands of the community.
The lack of funding for core development is a serious pragmatic weakness of the free software movement. Peter Deutsch, with Ghostscript and the AFPL license he authored, made a very good attempt to address that problem, and it's actually been working out pretty well for us.
Even so, freedom is very important to the Ghostscript project. Thus, I feel called to respond to comparisons between less-free licensing arrangements and Ghostscript.
As several people have already pointed out, there are official drivers right now that work very well with Ghostscript. While these drivers are not quite open source, they come fairly close. No binary-only drivers like the Lexmark Z52, these come with full source and rights to do your own modifications. The one restriction keeping them from being fully dfsg compliant is the requirement that they be used only with HP printers. The nice engineers at HP are very aware of the advantages of moving to a true free software model, and are busy shepherding this through the corporate bureaucracy.
All in all, I'm pleased and impressed with HP's support of Linux and free software. Given the context they're operating in, I'm not surprised that it's taking time to do things right, and I'm willing to grant them that.
But also look at gimp-print for a very impressive example of what a "pure" free software project is capable of. What Bruce said originally is true - all we (the free software community) needs is the basic documents about how to get the dots on the page, and we can do a damn fine job of arranging them. I believe "intellectual property" is a non-issue for getting inkjet drivers under Linux.
A lot of comments here reflect a somewhat, uh, uninformed view of color vision. I was going to write up a little summary, but then decided to try my Google skills out.
I came up with this definitive article on Color Vision by Peter Gouras. It's very deep, with a special focus on the neurology of color vision.
Another potentially interesting link is the Color Vision Q&A from Rochester Institute of Technology.
What's especially fascinating to me about color vision is that it still isn't fully understood. The low level parts, such as rods and cones, and even some of the "early vision" parts of the brain, have been studied for a while now. However, there are lots of higher level brain activities that are still quite mysterious. As such, making color photographs "match" across computer screen, print, video, etc., is still a subjective art, claims of rigor in "color management solutions" notwithstanding.
The trick is to use a pair of my patented spectral shifting eyeglasses. The extra colors are visible as discrepancies between the two eyes, a somewhat glittery effect.
I have a prototype pair here. I haven't done an experiment along the lines of Dr. Jordan's, but my intuition is that you'd be able to pass the tetrachromat test.
In theory, this technique can give you up to hexachromic vision. In practice, the color shifts in the yellow area are by far the most pronounced.
The prototypes cost me about $1000. The optical coating technology is pretty straightforward, and it should be possible to manufacture these in quantity for $20-$30. Anyone interested in going into production?
A fair amount of info on color management tools is on my color management page. One of the most exciting pieces of technology is the Argyll color management system.
The main thing that's lacking right now is integration. A lot of the pieces exist, but they're tied together yet. I plan on integrating Argyll into Ghostscript over the next few months, so that's likely to be a good start.
Interestingly enough, X had a very good start at a color management system (XCMS). However, as far as I know, nobody ever used this seriously, so it's yet another hunk of worthless junk hanging off the X server. This type of thing still "works", though:
xterm -fg CIEXYZ:0.371298/0.201443/0.059418
Of course, the chance of your monitor actually matching the CIE color is pretty close to nil.
In any case, there's quite a bit of work underway, and it's reasonable to expect that Linux will eventually have good color management. If you want it sooner rather than later, contribute to one of the projects!
There was an O(n^2) inner loop for reading the trust metric cache, because it was using the Apache table functions. Also, as a more minor problem, this cache file was being stored as an XML file, which took a little while to parse.
After a little on-the-spot programming, it's now stored as a plain text file.
So thanks to Slashdot for motivating me to do this fix. I had noticed the performance was getting a little clunky, but it was good enough until now.
Even though Mac OS X is based on resolution independent technology (a modified version of Display PostScript), the UI is still laid out in terms of pixels, and the numbers of pixels are hardcoded in the style guide.
This was a big mistake. Now that very cool things are starting to happen with X, I believe that we will end up creaming Apple.
What restrictions, if any, are there on the use of Library of Congress data? The quality and quantity of data available on their Z39.50 port looks quite impressive.
I sent them an email about this a couple of weeks ago but did not receive an answer. Any insight would be appreciated.
There are two solutions, I think, to the tragedy of the commons. One is to pay people for their disk space and bandwidth. As several other comments have pointed out, this is exactly what Mojo Nation does, using "mojo" micropayment tokens as the currency. I've been playing with it, and though it's been a bumpy ride, it looks very promising. Check it out.
There is another solution, I think, which is using trust to define a community. The set of "Gnutella users" is too large and diffuse to actually define a community. Why should I donate my bandwidth for other people who I don't know and don't really care about?
If, on the other hand, I were sharing files with a much smaller group of people, many of whom I know personally, then it starts feeling more like a community. Of course I want my friends to be able to listen to the music I like.
I propose that the trust system as deployed on Advogato might be a good way to define these communities. Of course, I might be totally wrong about this as well. Only one way to find out:)
Incidentally, the way Mojo Nation is set up right now, it still has Tragedy of the Commons problems. Currently, you don't get mojo for uploading tasty content. In fact, you actually have to pay for the privilege. However, when you share a file, it's not a continual drain on your bandwidth (or diskspace, fwiw). The actual distribution is handled by "block servers", who do charge for their services.
Of course, the Mojo economy is still in its formative stages. I hope, and expect, that actual markets will develop for providing and identifying tasty content.
In any case, file sharing sure promises to be an interesting ride.
Now that this is posted to Slashdot, I thought people might be interested to know how this extension relates to Libart, which, after all, shares many of the same goals of providing high performance 2D rendering.
Libart and the Render extension are both fairly low-level mechanisms for 2D rendering. Libart nails down the data structures and buffer layouts (24-bit packed RGB for most work), which has desirable consequences for both performance and simplicity. On the other hand, Render is really optimized for the case where there is hardware support for the primitives.
In many ways, Render is even lower level than Libart. For example, Libart handles vector paths, stroke outline, miters, line dashing, and so on. Render only handles low-level primitives such as triangles and trapezoids. To render more complex shapes, you have to tesselate them into triangles client-side before sending them to the screen.
Neither of these projects currently provides an ideal high-level API for application developers. While it will be possible to write directly to the Render layer, it's probably too much of an impedance mismatch for most applications. Similarly, the current Libart API doesn't provide any way to use the hardware acceleration that Render provides.
Thus, I'm working on a slightly higher level API for Libart, one with basically the same semantics as the existing API, but with the actual representations of data structures abstracted. Thus, a Libart+ "shape" can be a bezier path, a vector path, an SVP (sorted vector path), or a pile of triangles optimized for the Render extension. Similarly, a "picture" can be a packed RGB or RGBA buffer as now, or may be a handle to a pixel buffer actually living on the video card, accessible through the Render extension.
I want this to be a beautiful API for applications to write to. The main advantage is that it can automatically negotiate which functions should be performed server-side and which client-side. For example, no video cards today can actually deal with bezier paths directly. If this ever changes, then Keith can add the relevant stuff to the Render extension, I can add the code to Libart+ to recognize it, and apps will automatically win.
Further, this architecture provides for richer functionality than Render provides, without loss of performance in the common case. Right now, I'm adding the PDF 1.4 blend modes (Multiply, Overlay, Hard Light, Soft Light, etc) to Libart. These blending modes just get implemented in software.
Lastly, I have to say that I think Keith is making exactly the right decisions to keep Render low-level, lean, and simple. I have great confidence that he will ship something soon that provides useful access to hardware acceleration. It is refreshing to see well-engineered stuff coming out of the X world again, after many years of bloated, nearly useless crap from the X consortium and The Open Group. Gambai!
Well, speaking just for the antialiased font problem, I think Linux is going to see some really good news over the next few months. I've been hacking on high performance aa font rendering using Freetype2, and I've got some working code in the Nautilus CVS, as part of librsvg. All of the font integration code is going to get released as LGPL (librsvg is GPL) and I hope and expect lots of other projects to pick up on it.
Not only that, but the XFree86 render project has all of a sudden picked up some momentum. I have confidence that the designs floating by on that mailing list will lead to nice, clean hardware accelerated aa text soon. While we're at it, we'll fix the XLFD mess and problems like client and server fonts not always matching.
This is a hell of an exciting time for advanced 2D graphics under Linux. Gambai!
Well, since Cisco is one of the hottest and most capitalized Internet companies, this is probably how IBM best felt they could compete.
But hopefully people won't consider IBM to be an Uncle Tom because of this.
If you haven't seen the ad, btw, here's a transcript:
1991 Helsinki. A 21 year old student named Linus Torvalds writes a new computer operating system. He calls it "Linux". Then does something revolutionary: he gives it away, free. Over the Internet. The powers that be dismiss him as an eccentric, a freak. But everywhere coders and free thinkers embrace linux; improve and refine it. Now the forces of openness have a powerful and unexpected new ally.
It's a different kind of world. You need a different kind of software.
I just love the way he pronounces "software" - it's sexy. One thing though: how come he pronounces Linux as/LIN-ucks/, but Linus as "LIE-nus"?
I watched Cube the other day, and noticed that the soundtrack featured either a dot matrix printer or a really good simulation. I was idly thinking that it would be neat to a whole piece based on it, but these guys have obviously beat me to the punch.
I also have a Graphtec X-Y plotter, which makes neat sounds, especially from programmatically generated images, such as a cardioid. I've been hacking it to do pencil and watercolor images, with promising results.
Someone is doing something about free tools for the.doc file format, rather than whining, and he only gets a +2 (as of the time of this writing)? Have the moderators recently had a brain transplant operation, on the donor side?
There's enough misinformation posted here that I feel some factual information is in order. I am doing work for Eazel on a consulting basis on graphics and rendering. Librsvg (the renderer for the reduced SVG subset) is my baby.
Yes, Nautilus has the capabilities to do fairly advanced antialiased rendering. The current development snapshot has the option to use the antialiased renderer in the Gnome Canvas (joint work between Federico Mena-Quintero and myself). This does full alpha-blending and enables the use of icons with semitransparency. The Xlib renderer will probably remain an option for those with slower computers. Icons can be provided in both SVG for full scalability, or in PNG in a graded series of sizes.
My current project is integrating Freetype 2 text with librsvg, adding antialiased text capabilities with both TrueType and Adobe Type1 font support.
The current architecture of X makes it relatively straightforward to implement antialiasing and alpha compositing within a window, but impossible to composite across windows. Thus, Aqua effects such as having windows cast soft shadows, or having drag'n'drop icons antialias correctly, are currently beyond the scope of what X can do.
There is active work ongoing to add true alpha to X, led by Keith Packard of SuSE. I'm following this work closely, and am eager to see it come to fruition so that we can start to apply a rich imaging model across the entire screen.
Raster is doing some very cool work with EFM. Some people seem to think there's a kind of war going on between the Gnome and E camps. I don't see it this way at all - to me, it's a friendly competition in the best sense of the word. Raster is at the cutting edge of graphics capabilities, while Gnome is doing more work on integration and making sure everything works well on a broad range of systems and configurations. Both approaches have their merits, and if nothing else Raster's work serves as excellent protypes for Gnome development. I had lunch with Raster and Andy last week, and we had a really nice discussion about extending X, getting access to hardware acceleration for antialiasing and compositing, and so on. We also talked about some of the requirements for making sure all this stuff is useful from the Gnome Canvas, and I'm hopeful good stuff will come of it.
I also want to talk a little about antialiased text. The best of all possible worlds is an unhinted, antialiased display at 140 dpi or higher. Since those displays aren't widespread yet, we have to make do with some tradeoffs. The most fundamental tradeoff is between edge sharpness on one hand, and smoothness on the other. Also hanging in the balance is the faithful reproduction of the glyph shape. Whenever you antialias, the edges become softer. However, you can sometimes get a slightly better tradeoff by aligning vertical and horizontal stems to the pixel grid, thus ensuring sharp edges for these, while diagonal and curved segments get smoothly antialiased. However, this process does distort the font somewhat.
In order to take advantage of 140+ dpi displays, you have to write your apps to be resolution independent. Fortunately, with the Gnome Canvas (which is what Nautilus uses for its icon view), it's pretty straightforward - in fact, there's a zoom control that scales the whole canvas uniformly. I was surprised and a bit disappointed to see that Aqua is not resolution independent, and in fact has many of the dimensions hardcoded. Thus, down the road I think it's not unreasonable to expect free software to have the best rendering, bar none.
It's a lot of fun to be developing this stuff, and I'm looking forward to getting a desktop with advanced graphical rendering into the hands of lots of people.
First, you didn't say which encoder you're using. There is a tremendous amount of difference, and the most popular coders seem to be among the lowest quality.
Any MP3 coder is going to give you muddy hi-hats at 128kbps. That's because the hi-hat sound is incredibly complex. Getting all the nuances and subtleties perfect requires a lot of bits. At 128kpbs, the encoder does what it can, but can't possibly get it all in there. That's why they sound muddy.
There is no reason for a good MP3 coder to significantly distort bass sounds. If it's changing a smoothly varying timbre into one that's "flittery," then you're seeing variation from frame to frame, a significant problem with all MP3 coders other than Fraunhofer's newer ones. If you're getting this effect with Fraun, I'd be very surprised.
The 16KHz cutoff is frequency-based (not exactly an FFT, but similar). Look at some spectrum analysis data - you'll see it's pretty crisp.
MP3 at 128kbps definitely does distort the sound. That rate is just at the knee - a lot of people can't hear the difference of going to a higher rate, while just about everybody starts hearing the degradation at lower bitrates.
But my original point was not that MP3 is flawless, it was that the loss is in sonic complexity rather than frequency response. Because the degradation caused by traditional analog processes such as mic's, tapes, speakers, etc., can all be well quantified in terms of loss of frequency response, it's tempting to use the same criteria to judge digital compression. However tempting, though, it's wrong.
Ok, saying "MP3 wacks out music's treble and bass" is pretty inaccurate.
The overall frequency response of MP3 is essentially flat. If you do the standard audio tests of sine waves at various frequencies, you'll get basically perfect fidelity. That's because sine tones are not very complex and thus compress very well.
MP3, like all lossy compression schemes, removes information complexity from the signal, so that it fits into a much smaller bitrate channel. The function of the magical "psycho-acoustic model" is to separate out the complexity that you can hear easily (for example, the attack on a snare drum) from complexity that you can't (ie small signals at frequencies that are close to frequency peaks, so are masked out). At any given bitrate, MP3 encodes as much as possible of the former signal and ditches the rest. The higher the bitrate, the more gets encoded.
Now, that said, at 128kbps, the better quality MP3 encoders suppress frequencies higher than 16kHz. The reasoning for this is very sound: most people (myself included) can't hear these frequencies at all. Nonetheless, because they're up there in the frequency spectrum, they can encode quite a bit of informational complexity - in fact, the 16kHz to 22.05 kHz band has almost exactly enough bandwidth to encode two telephone conversations. By ditching this band, the MP3 encoder gets rid of a lot of informational complexity that generally can't be heard anyway, leaving more for the actual music.
If you insist that you can hear near-ultrasonics, then simply encode at 160kbps, or use a better encoding format than MP3, such as Vorbis.
Speaking of which, my understanding is that MPEG-4 is absolutely riddled with patent problems. I'm surprised this wasn't mentioned in the article. If you rush to adopt MPEG-4, you've given up the right to whine about big evil corps and their patents - it's you who's adopted patented technology. Support a free video codec instead.
First, LAME was not developed in a "clean room" at all; it's based on the ISO reference code, which is horribly buggy and far from optimal. Blade is based on the same code, but doesn't have anywhere nearly the same level of work put into it.
Second, while cleanroom techniques are a fine defense against copyrights, they make no difference whatsoever for patents. So the idea of starting a new cleanroom MP3 encoder project wouldn't really help matters.
What would, though, is the creation of a new format that is free of intellectual property problems. While you're at it, wouldn't it be nice if it included amplitude shaping to make transients sound crisper, and used a few other techniques to achieve better quality compression with MP3? Oh, and why not lots of work integrating it into free software tools such as XMMS? Why doesn't somebody do this?
Nobody forced you to adopt the standard. Now that Vorbis is out, there's an excellent alternative to MP3, both technically superior and free of intellectual property problems.
Ok, so there isn't a huge archive of illegal vorbis files available on Napster/Gnutella. Yet. Maybe you'll have to sacrifice a little convenience and have a little patience, just in order to stand up for what's right. It's your choice, though.
I agree that not everyone has fat pipes, and I don't want to be a techno-elitist.
However, waiting interminably for pages to download seems to me to be more a problem of bad Web design than inadequate compression. For one, it's very common to see images out there that could be compressed a lot more than they are. For example, when images have sharp chroma boundaries, a lot of people crank up the quality setting to the max to try to compensate for JPEG's well known chroma bleeding problems. However, with good software (like the Gimp) in skilled hands, you can adjust the chroma subsampling to 1:1, which will give excellent results at low Q, ie a better tradeoff.
JPEG works pretty damn well. JPEG2000 is better. But I am not yet convinced that the advantages are really worth the pain of upgrading to a new format, especially if it's not free as JPEG baseline is. If you really care about compression, there's plenty you can do using existing tools.
Last time Slashdot covered this story, the EE Times article had a very hyped-up comparison showing JPEG2000 to be dramatically better than plain JPEG. Upon closer examination, while JPEG2000 is better, the difference is not very dramatic, as this comparison shows.
If this technology is not free for free software implemenation, forever, then my advice is to avoid it like the plague. I hope they do release the technology for free, but even then some care is called for. After all, you definitely don't want to send a JPEG2000 image to a browser that doesn't properly support it. One can only hope that the browser support is better than that for, say PNG.
The idea of sending images at multiple resolutions, one for the screen and one for printing, is an excellent one. However, it's not fundamentally the responsibility of the image format, but rather of the hypertext protocol. The idea has been around for a while - the first time I saw it was in Ted Nelson's Xanadu proposal. Damn, the old guys stole all our best ideas! Again!
Slashdot Mirror
While the AFPL is a non-DFSG license designed in large part to support an OEM licensing business, it also has three important freedoms that appear to be missing from the SPL:
1. Fork rights. You are perfectly free to take AFPL code, make your own modifications, and release that code under the AFPL. This distinguishes the AFPL from most other "almost free" licenses.
2. Commercial use. AFPL code is free for commercial use. An example is ps2pdf.com, which is an advertiser supported site using AFPL Ghostscript.
3. No grantback. If you make custom modifications for in-house use, you are not obligated to grant those modifications to the original author. Further, if you release a forked version under the AFPL, you are not obligated to license that code back to the original author so they can OEM license it.
In my opinion, the only significant right lacking from the AFPL is commercial redistribution without compensation. While people obviously disagree with this, my personal opinion is that it is not anywhere nearly as important as the other free software rights, especially now that free distribution over the Internet is ubiquitous. I frankly don't see why it's so important for Red Hat to make money from selling our code without compensating us in any way for our work.
Ghostscript has a fourth freedom guarantee, which is that major AFPL releases are re-released under the GPL a year later. Thus, the extra rights granted to us as commercial Ghostscript developers is fairly small and definitely time-limited. As long as we continue to improve Ghostscript actively, the AFPL version is valuable. As soon as we stop doing our job, it falls into the hands of the community.
The lack of funding for core development is a serious pragmatic weakness of the free software movement. Peter Deutsch, with Ghostscript and the AFPL license he authored, made a very good attempt to address that problem, and it's actually been working out pretty well for us.
Even so, freedom is very important to the Ghostscript project. Thus, I feel called to respond to comparisons between less-free licensing arrangements and Ghostscript.
As several people have already pointed out, there are official drivers right now that work very well with Ghostscript. While these drivers are not quite open source, they come fairly close. No binary-only drivers like the Lexmark Z52, these come with full source and rights to do your own modifications. The one restriction keeping them from being fully dfsg compliant is the requirement that they be used only with HP printers. The nice engineers at HP are very aware of the advantages of moving to a true free software model, and are busy shepherding this through the corporate bureaucracy.
All in all, I'm pleased and impressed with HP's support of Linux and free software. Given the context they're operating in, I'm not surprised that it's taking time to do things right, and I'm willing to grant them that.
> I'll need a retainer for that.
No need.
http://www.levien.com/patents.html
But also look at gimp-print for a very impressive example of what a "pure" free software project is capable of. What Bruce said originally is true - all we (the free software community) needs is the basic documents about how to get the dots on the page, and we can do a damn fine job of arranging them. I believe "intellectual property" is a non-issue for getting inkjet drivers under Linux.
A lot of comments here reflect a somewhat, uh, uninformed view of color vision. I was going to write up a little summary, but then decided to try my Google skills out.
I came up with this definitive article on Color Vision by Peter Gouras. It's very deep, with a special focus on the neurology of color vision.
Another potentially interesting link is the Color Vision Q&A from Rochester Institute of Technology.
What's especially fascinating to me about color vision is that it still isn't fully understood. The low level parts, such as rods and cones, and even some of the "early vision" parts of the brain, have been studied for a while now. However, there are lots of higher level brain activities that are still quite mysterious. As such, making color photographs "match" across computer screen, print, video, etc., is still a subjective art, claims of rigor in "color management solutions" notwithstanding.
The trick is to use a pair of my patented spectral shifting eyeglasses. The extra colors are visible as discrepancies between the two eyes, a somewhat glittery effect.
I have a prototype pair here. I haven't done an experiment along the lines of Dr. Jordan's, but my intuition is that you'd be able to pass the tetrachromat test.
In theory, this technique can give you up to hexachromic vision. In practice, the color shifts in the yellow area are by far the most pronounced.
The prototypes cost me about $1000. The optical coating technology is pretty straightforward, and it should be possible to manufacture these in quantity for $20-$30. Anyone interested in going into production?
A fair amount of info on color management tools is on my color management page. One of the most exciting pieces of technology is the Argyll color management system.
The main thing that's lacking right now is integration. A lot of the pieces exist, but they're tied together yet. I plan on integrating Argyll into Ghostscript over the next few months, so that's likely to be a good start.
Interestingly enough, X had a very good start at a color management system (XCMS). However, as far as I know, nobody ever used this seriously, so it's yet another hunk of worthless junk hanging off the X server. This type of thing still "works", though:
xterm -fg CIEXYZ:0.371298/0.201443/0.059418
Of course, the chance of your monitor actually matching the CIE color is pretty close to nil.
In any case, there's quite a bit of work underway, and it's reasonable to expect that Linux will eventually have good color management. If you want it sooner rather than later, contribute to one of the projects!
There was an O(n^2) inner loop for reading the trust metric cache, because it was using the Apache table functions. Also, as a more minor problem, this cache file was being stored as an XML file, which took a little while to parse.
After a little on-the-spot programming, it's now stored as a plain text file.
So thanks to Slashdot for motivating me to do this fix. I had noticed the performance was getting a little clunky, but it was good enough until now.
Even though Mac OS X is based on resolution independent technology (a modified version of Display PostScript), the UI is still laid out in terms of pixels, and the numbers of pixels are hardcoded in the style guide.
This was a big mistake. Now that very cool things are starting to happen with X, I believe that we will end up creaming Apple.
What restrictions, if any, are there on the use of Library of Congress data? The quality and quantity of data available on their Z39.50 port looks quite impressive.
I sent them an email about this a couple of weeks ago but did not receive an answer. Any insight would be appreciated.
There are two solutions, I think, to the tragedy of the commons. One is to pay people for their disk space and bandwidth. As several other comments have pointed out, this is exactly what Mojo Nation does, using "mojo" micropayment tokens as the currency. I've been playing with it, and though it's been a bumpy ride, it looks very promising. Check it out.
:)
There is another solution, I think, which is using trust to define a community. The set of "Gnutella users" is too large and diffuse to actually define a community. Why should I donate my bandwidth for other people who I don't know and don't really care about?
If, on the other hand, I were sharing files with a much smaller group of people, many of whom I know personally, then it starts feeling more like a community. Of course I want my friends to be able to listen to the music I like.
I propose that the trust system as deployed on Advogato might be a good way to define these communities. Of course, I might be totally wrong about this as well. Only one way to find out
Incidentally, the way Mojo Nation is set up right now, it still has Tragedy of the Commons problems. Currently, you don't get mojo for uploading tasty content. In fact, you actually have to pay for the privilege. However, when you share a file, it's not a continual drain on your bandwidth (or diskspace, fwiw). The actual distribution is handled by "block servers", who do charge for their services.
Of course, the Mojo economy is still in its formative stages. I hope, and expect, that actual markets will develop for providing and identifying tasty content.
In any case, file sharing sure promises to be an interesting ride.
Now that this is posted to Slashdot, I thought people might be interested to know how this extension relates to Libart, which, after all, shares many of the same goals of providing high performance 2D rendering.
Libart and the Render extension are both fairly low-level mechanisms for 2D rendering. Libart nails down the data structures and buffer layouts (24-bit packed RGB for most work), which has desirable consequences for both performance and simplicity. On the other hand, Render is really optimized for the case where there is hardware support for the primitives.
In many ways, Render is even lower level than Libart. For example, Libart handles vector paths, stroke outline, miters, line dashing, and so on. Render only handles low-level primitives such as triangles and trapezoids. To render more complex shapes, you have to tesselate them into triangles client-side before sending them to the screen.
Neither of these projects currently provides an ideal high-level API for application developers. While it will be possible to write directly to the Render layer, it's probably too much of an impedance mismatch for most applications. Similarly, the current Libart API doesn't provide any way to use the hardware acceleration that Render provides.
Thus, I'm working on a slightly higher level API for Libart, one with basically the same semantics as the existing API, but with the actual representations of data structures abstracted. Thus, a Libart+ "shape" can be a bezier path, a vector path, an SVP (sorted vector path), or a pile of triangles optimized for the Render extension. Similarly, a "picture" can be a packed RGB or RGBA buffer as now, or may be a handle to a pixel buffer actually living on the video card, accessible through the Render extension.
I want this to be a beautiful API for applications to write to. The main advantage is that it can automatically negotiate which functions should be performed server-side and which client-side. For example, no video cards today can actually deal with bezier paths directly. If this ever changes, then Keith can add the relevant stuff to the Render extension, I can add the code to Libart+ to recognize it, and apps will automatically win.
Further, this architecture provides for richer functionality than Render provides, without loss of performance in the common case. Right now, I'm adding the PDF 1.4 blend modes (Multiply, Overlay, Hard Light, Soft Light, etc) to Libart. These blending modes just get implemented in software.
Lastly, I have to say that I think Keith is making exactly the right decisions to keep Render low-level, lean, and simple. I have great confidence that he will ship something soon that provides useful access to hardware acceleration. It is refreshing to see well-engineered stuff coming out of the X world again, after many years of bloated, nearly useless crap from the X consortium and The Open Group. Gambai!
Well, speaking just for the antialiased font problem, I think Linux is going to see some really good news over the next few months. I've been hacking on high performance aa font rendering using Freetype2, and I've got some working code in the Nautilus CVS, as part of librsvg. All of the font integration code is going to get released as LGPL (librsvg is GPL) and I hope and expect lots of other projects to pick up on it.
Not only that, but the XFree86 render project has all of a sudden picked up some momentum. I have confidence that the designs floating by on that mailing list will lead to nice, clean hardware accelerated aa text soon. While we're at it, we'll fix the XLFD mess and problems like client and server fonts not always matching.
This is a hell of an exciting time for advanced 2D graphics under Linux. Gambai!
But hopefully people won't consider IBM to be an Uncle Tom because of this.
If you haven't seen the ad, btw, here's a transcript:
I just love the way he pronounces "software" - it's sexy. One thing though: how come he pronounces Linux as
I watched Cube the other day, and noticed that the soundtrack featured either a dot matrix printer or a really good simulation. I was idly thinking that it would be neat to a whole piece based on it, but these guys have obviously beat me to the punch.
I also have a Graphtec X-Y plotter, which makes neat sounds, especially from programmatically generated images, such as a cardioid. I've been hacking it to do pencil and watercolor images, with promising results.
Oh well, back to paid hacking now.
Someone is doing something about free tools for the .doc file format, rather than whining, and he only gets a +2 (as of the time of this writing)? Have the moderators recently had a brain transplant operation, on the donor side?
Meept!
There's enough misinformation posted here that I feel some factual information is in order. I am doing work for Eazel on a consulting basis on graphics and rendering. Librsvg (the renderer for the reduced SVG subset) is my baby.
Yes, Nautilus has the capabilities to do fairly advanced antialiased rendering. The current development snapshot has the option to use the antialiased renderer in the Gnome Canvas (joint work between Federico Mena-Quintero and myself). This does full alpha-blending and enables the use of icons with semitransparency. The Xlib renderer will probably remain an option for those with slower computers. Icons can be provided in both SVG for full scalability, or in PNG in a graded series of sizes.
My current project is integrating Freetype 2 text with librsvg, adding antialiased text capabilities with both TrueType and Adobe Type1 font support.
The current architecture of X makes it relatively straightforward to implement antialiasing and alpha compositing within a window, but impossible to composite across windows. Thus, Aqua effects such as having windows cast soft shadows, or having drag'n'drop icons antialias correctly, are currently beyond the scope of what X can do.
There is active work ongoing to add true alpha to X, led by Keith Packard of SuSE. I'm following this work closely, and am eager to see it come to fruition so that we can start to apply a rich imaging model across the entire screen.
Raster is doing some very cool work with EFM. Some people seem to think there's a kind of war going on between the Gnome and E camps. I don't see it this way at all - to me, it's a friendly competition in the best sense of the word. Raster is at the cutting edge of graphics capabilities, while Gnome is doing more work on integration and making sure everything works well on a broad range of systems and configurations. Both approaches have their merits, and if nothing else Raster's work serves as excellent protypes for Gnome development. I had lunch with Raster and Andy last week, and we had a really nice discussion about extending X, getting access to hardware acceleration for antialiasing and compositing, and so on. We also talked about some of the requirements for making sure all this stuff is useful from the Gnome Canvas, and I'm hopeful good stuff will come of it.
I also want to talk a little about antialiased text. The best of all possible worlds is an unhinted, antialiased display at 140 dpi or higher. Since those displays aren't widespread yet, we have to make do with some tradeoffs. The most fundamental tradeoff is between edge sharpness on one hand, and smoothness on the other. Also hanging in the balance is the faithful reproduction of the glyph shape. Whenever you antialias, the edges become softer. However, you can sometimes get a slightly better tradeoff by aligning vertical and horizontal stems to the pixel grid, thus ensuring sharp edges for these, while diagonal and curved segments get smoothly antialiased. However, this process does distort the font somewhat.
In order to take advantage of 140+ dpi displays, you have to write your apps to be resolution independent. Fortunately, with the Gnome Canvas (which is what Nautilus uses for its icon view), it's pretty straightforward - in fact, there's a zoom control that scales the whole canvas uniformly. I was surprised and a bit disappointed to see that Aqua is not resolution independent, and in fact has many of the dimensions hardcoded. Thus, down the road I think it's not unreasonable to expect free software to have the best rendering, bar none.
It's a lot of fun to be developing this stuff, and I'm looking forward to getting a desktop with advanced graphical rendering into the hands of lots of people.
A working URL is here.
Rob Pike's presentation was discussed on Advogato about a month ago. I'm biased of course, but I think there are some very interesting points.
I think you'll see the crispness of the 16kHz cutoff in these graphs.
First, you didn't say which encoder you're using. There is a tremendous amount of difference, and the most popular coders seem to be among the lowest quality.
Any MP3 coder is going to give you muddy hi-hats at 128kbps. That's because the hi-hat sound is incredibly complex. Getting all the nuances and subtleties perfect requires a lot of bits. At 128kpbs, the encoder does what it can, but can't possibly get it all in there. That's why they sound muddy.
There is no reason for a good MP3 coder to significantly distort bass sounds. If it's changing a smoothly varying timbre into one that's "flittery," then you're seeing variation from frame to frame, a significant problem with all MP3 coders other than Fraunhofer's newer ones. If you're getting this effect with Fraun, I'd be very surprised.
The 16KHz cutoff is frequency-based (not exactly an FFT, but similar). Look at some spectrum analysis data - you'll see it's pretty crisp.
MP3 at 128kbps definitely does distort the sound. That rate is just at the knee - a lot of people can't hear the difference of going to a higher rate, while just about everybody starts hearing the degradation at lower bitrates.
But my original point was not that MP3 is flawless, it was that the loss is in sonic complexity rather than frequency response. Because the degradation caused by traditional analog processes such as mic's, tapes, speakers, etc., can all be well quantified in terms of loss of frequency response, it's tempting to use the same criteria to judge digital compression. However tempting, though, it's wrong.
Ok, saying "MP3 wacks out music's treble and bass" is pretty inaccurate.
The overall frequency response of MP3 is essentially flat. If you do the standard audio tests of sine waves at various frequencies, you'll get basically perfect fidelity. That's because sine tones are not very complex and thus compress very well.
MP3, like all lossy compression schemes, removes information complexity from the signal, so that it fits into a much smaller bitrate channel. The function of the magical "psycho-acoustic model" is to separate out the complexity that you can hear easily (for example, the attack on a snare drum) from complexity that you can't (ie small signals at frequencies that are close to frequency peaks, so are masked out). At any given bitrate, MP3 encodes as much as possible of the former signal and ditches the rest. The higher the bitrate, the more gets encoded.
Now, that said, at 128kbps, the better quality MP3 encoders suppress frequencies higher than 16kHz. The reasoning for this is very sound: most people (myself included) can't hear these frequencies at all. Nonetheless, because they're up there in the frequency spectrum, they can encode quite a bit of informational complexity - in fact, the 16kHz to 22.05 kHz band has almost exactly enough bandwidth to encode two telephone conversations. By ditching this band, the MP3 encoder gets rid of a lot of informational complexity that generally can't be heard anyway, leaving more for the actual music.
If you insist that you can hear near-ultrasonics, then simply encode at 160kbps, or use a better encoding format than MP3, such as Vorbis.
Speaking of which, my understanding is that MPEG-4 is absolutely riddled with patent problems. I'm surprised this wasn't mentioned in the article. If you rush to adopt MPEG-4, you've given up the right to whine about big evil corps and their patents - it's you who's adopted patented technology. Support a free video codec instead.
First, LAME was not developed in a "clean room" at all; it's based on the ISO reference code, which is horribly buggy and far from optimal. Blade is based on the same code, but doesn't have anywhere nearly the same level of work put into it.
Second, while cleanroom techniques are a fine defense against copyrights, they make no difference whatsoever for patents. So the idea of starting a new cleanroom MP3 encoder project wouldn't really help matters.
What would, though, is the creation of a new format that is free of intellectual property problems. While you're at it, wouldn't it be nice if it included amplitude shaping to make transients sound crisper, and used a few other techniques to achieve better quality compression with MP3? Oh, and why not lots of work integrating it into free software tools such as XMMS? Why doesn't somebody do this?
Ah yes, they have, they have.
Nobody forced you to adopt the standard. Now that Vorbis is out, there's an excellent alternative to MP3, both technically superior and free of intellectual property problems.
Ok, so there isn't a huge archive of illegal vorbis files available on Napster/Gnutella. Yet. Maybe you'll have to sacrifice a little convenience and have a little patience, just in order to stand up for what's right. It's your choice, though.
I agree that not everyone has fat pipes, and I don't want to be a techno-elitist.
However, waiting interminably for pages to download seems to me to be more a problem of bad Web design than inadequate compression. For one, it's very common to see images out there that could be compressed a lot more than they are. For example, when images have sharp chroma boundaries, a lot of people crank up the quality setting to the max to try to compensate for JPEG's well known chroma bleeding problems. However, with good software (like the Gimp) in skilled hands, you can adjust the chroma subsampling to 1:1, which will give excellent results at low Q, ie a better tradeoff.
JPEG works pretty damn well. JPEG2000 is better. But I am not yet convinced that the advantages are really worth the pain of upgrading to a new format, especially if it's not free as JPEG baseline is. If you really care about compression, there's plenty you can do using existing tools.
Last time Slashdot covered this story, the EE Times article had a very hyped-up comparison showing JPEG2000 to be dramatically better than plain JPEG. Upon closer examination, while JPEG2000 is better, the difference is not very dramatic, as this comparison shows.
If this technology is not free for free software implemenation, forever, then my advice is to avoid it like the plague. I hope they do release the technology for free, but even then some care is called for. After all, you definitely don't want to send a JPEG2000 image to a browser that doesn't properly support it. One can only hope that the browser support is better than that for, say PNG.
The idea of sending images at multiple resolutions, one for the screen and one for printing, is an excellent one. However, it's not fundamentally the responsibility of the image format, but rather of the hypertext protocol. The idea has been around for a while - the first time I saw it was in Ted Nelson's Xanadu proposal. Damn, the old guys stole all our best ideas! Again!