Slashdot Mirror

GNU Generation, a student association at the Swiss Federal Institute of Technology of Lausanne, proudly announces the release of GNUWin-II,
a collection of free and open source software for Windows, which luckily contains most of the software that was proposed some days ago on slashdot.

It comes on a CD with more than 50 applications, articles, and a four-language (yes it's swiss)
html based interface to help newcomers discover Free Software.

The complete GNUWin-II can be browsed online.
The ISO image of the CD
can be downloaded here or better on Swiss SunSITE mirror ftp or http. It is also possible to order a CD in Europe.

• http://metwww.epfl.ch/lecteur_disques/MainLectDisc E.htm
• http://www.elpj.com/frameset.html

Here

Less pretty but more understandable

Actually you can get a set of Adobe Type 1 fonts for LaTeX from the AMS. You can then make TeX use these standard PostScript Type 1 fonts in the PDFs it produces. More details here and here. You can also make LaTeX use the standard PostScript fonts for its body by using the \usepackage{times} directive in the preamble.

My university is running a research project on "tracking 3D textured object in the presence of aspect changes". Using a computer, a camera and holding a box in your hand, you can animate a light saber.

Here is information about the project and this is an image of the laser sabre in action.

Here is a movie (37Mb) showing it in action.

Now, all you have to do is to buy the handle from parksabers.com to get the real feeling ;o)

My university is running a research project on "tracking 3D textured object in the presence of aspect changes". Using a computer, a camera and holding a box in your hand, you can animate a light saber.

Here is information about the project and this is an image of the laser sabre in action.

Here is a movie (37Mb) showing it in action.

Now, all you have to do is to buy the handle from parksabers.com to get the real feeling ;o)

My university is running a research project on "tracking 3D textured object in the presence of aspect changes". Using a computer, a camera and holding a box in your hand, you can animate a light saber.

Here is information about the project and this is an image of the laser sabre in action.

Here is a movie (37Mb) showing it in action.

Now, all you have to do is to buy the handle from parksabers.com to get the real feeling ;o)

First off, if you just want to make sure the colors are visible on top of each other, you could calculate the luminance of each color using .30*R + .59*G + .11*B and make sure that those numbers differ signifigantly. Some other rules of thumb are here, under color rules.

As far as color discrimability, you might want to look for info on MacAdam's ellipses of just noticeable color differences. There's a picutre on this page which shows the main idea: how different a color has to be in order to notice the difference depends on what color it is. Humans can discern more shades of green than red or blue.

Adobe should perhaps not doing intellectual terrorism, otherwise somone could try to look how secure their webserver are, or things like that...
Just for fun, DeCSS source code
And why moderating, long life Internet Free Speech !?
Note : my friends of Ysagoon team are NOT responsible for this message, even if our website is linked.

Ahhh!!! Good recommendation, but the more recent theory can be found here (CSP is "so last week"): Calculi for Mobile Processes

In 2.2 and later, using the iproute2 interface, you can route traffic through multiple interfaces and connections will go through in a semi-equalized fasion. "ip route add default nexthop via <addr> dev <device>", and repeat for as many interfaces as you have.

This causes new connections to choose one or the other interfaces, a single connection's traffic goes through one or the other but not both. This is in 2.2 without the DiffServ patches; patched 2.2 and stock 2.4 can make both interfaces be used equally instead of on a per connection basis with the equalize keyword on the ip command.

Self-replicating constructs are sometimes called von Neumann machines. It's a pretty cool idea that the popular media invariably links to Terminator (in the same way that all news stories about comic books must include Bam! Pow! or Holy [foo], Batman! in the title).

EUDEM - The European Union in Humanitarian DEMining is another anti-landmine group, which provides a clearinghouse for technical information.

This isn't half as freaky as this cyborg eel. It may only have a few neurons, but its still a real cyborg. No pictures but this is the robot model they used, scroll down its the one in the middle. This is a picture of the lamprey eel.

I can also see the preview for 'cyborg wars' on Comedy Central.

Two of the many projects can be found here and here.
However things have been moving more slowly with the new chips on the 5mx (see the mailing list).

You can of course connect your psion 3 or 5 to your Linux desktop, without supplanting your PDA's OS.
Derwen

I want something the size of a psion (preferably with a small keyboard) which can run gcc, has a serial port, uses AA batteries (so I can replace them with a quick visit to a newsagent), has at least a 24hr battery life, has a PCMCIA slot (probably for a 340mb IBM microdrive or an ethernet card) and fits nicely in my pocket.

He, actually, I believe shaldannon was talking about the new support for binary integer literals added to 5.6.0. You can say stuff like 0b10000 and get 16, and so on. That'd be nice to have in C, actually. Too bad it didn't make it into C9X (the new updated C standard). Time for another GNU extension, perhaps? ;^)

Cheap gig, great. More support for and old conecpt in networking. I just wish there was more support for a certain networking technology which would in turn help another related project. Instead we see a lot of progress in gig because its easy. Throwing bandwith and a bunch of buffer space in a switch is a crummy way to do QoS.
Aside from the ATM vs. Gig rant, this really doesn't mean a whole lot. Yeah LANs are fast, this isn't news to anyone. I don't see anyone complaining about the network performance on their desktop at 100Mb/s switched. So whats the deal? The big step forward in networking is when we can see something that gets close to the performace of atleast 10Mb/s to residential and buinesses that doesn't cost a small fortune.

Making routers actually pay attention to QoS bits, and defining specific queuing behavior for them.

This is happening, largely as a result of an IETF standards effort called DiffServ, which is defining building blocks from which the network behaviour required by a particular application can be provided, even in the presence of network congestion. Most routers today can interpret 8 priority levels (IP Precedence) of which 6 are user accessible - unfortunately they are not set up to do this because it is a configuration nightmare. The good news is that my company and others are going to take out the configuration hassle and make it easy for ISPs to configure their routers for DiffServ (we make network management software to configure this).

Most twitch games will want priority queuing, or at the least some guaranteed access to bandwidth for critical packets. Unfortunately this is exactly what Voice over IP (VoIP) requires, which is probably much more lucrative for the ISPs since it can be charged by the minute... Dedicated gaming networks may well be able to set priorities that make sense for gamers, though.

A "realtime" packet should never be added to a queue if there is another one from the same connection that is already in the queue. Multiple queuings just add latency that can't be controlled at the application level. Jump-to-head-of-queue would sure be nice, but that's probably too much to ask for in the name of "games".

This is like many multimedia applications, e.g. VoIP and videoconferencing, where if a packet is delayed it is no use so it might as well be dropped. One approach to this is for the application to become adaptive (or maybe the IP stack or linmodem code, given some hints from the application), i.e. to not send packets so frequently in times of congestion. At least then the offered load to the network is reduced, which is important in the non-DiffServ case.

The other approach is to use DiffServ to implement a low latency service, in which every suitably marked packet goes right to the top priority queue. Through careful limiting of what traffic gets into the network with that packet marking, the idea is that the top priority queue is almost always empty so low latency packets go right through every router with minimal queuing delay.

It's worth noting that if the queuing is working properly, the 2nd packet should never run into the first packet anyway, so it's probably easier just to throw DiffServ at the problem. This also avoids the need to keep track of things on a per-flow basis - when there are 1000s of real-time sessions going through a larger router, you really don't want to have to keep track of sessions (aka flows in QoS speak).

The Linux host sending the packets could implement the 'dump earlier packet' behaviour in its queuing mechanisms, but it would have to be per-flow, and the same arguments apply - it's better to reduce host, modem and router latency so that the packets go right through and have no chance to bump into earlier packets.

If you're interested, the Linux-DiffServ project is based on the 2.2 kernel - they've done a pretty flexible and complete implementation. More general links on QoS including DiffServ can be found here, under the Links button.

DiffServ technology is coming, and in fact exists in basic form in every Cisco router. The big issue for gaming is getting ISPs to implement DiffServ, and to charge for it in a sensible way so it's accessible to gamers.

Be careful : the JPEG2000 decoder you linked is based an older version of the Verification Model of the JPEG2000 standard (it uses VM3.1B, and the latest one is VM5.2 ...). Though it gives you some idea about the global performance of this algorithm, the final result should be slightly different ... Moreover, the code of this decoder may not be released, since the rights are owned by Motorola (this project was a partnership between EPFL and Motorola). BUT there is another decoder written in Java (see here ) which is not publicly accessible for the moment (only the JPEG members can access it). The latest JPEG meeting proposed that the final JPEG2000 standard would consist of a text AND a reference software (written in C or in Java) which may be accessible to anyone, lucky guys !

I don't see what *you're* seeing. The JPEG2000 looked better than the vanilla JPEG in all cases, IMO, and the difference was most noticeable at for more compressed files. Compare the JPEG2000 to the JPEG for this image and see what I mean. The JPEG2000 is very nice, with smooth curves (!), while the JPEG looks like something done on an Apple IIgs.
---

I just don't see what you're seeing. The standard JPEG in the demos are on the right, with the J2000 (extention j2k?) being loaded in the applet on the left. The JPEG appears, IMHO, to have more detail, although supposedly the J2K image is smaller in size (The site offers no size comparison, but the color JPEG image is only 32892 bytes).

Since the JPEG image is only 33K (and has excellent detail - check it out for yourself), I don't see why the extra compression is worth the degradation. With faster connections to the 'net becoming more prevalent, we will soon find that we are willing to wait an extra second to download a higher quality image.

I see this situation as analogous to the memory crunch in the days when 512K RAM was "enough for anybody". Some applications were written in pure assembly(or C, of course) just to squeeze out that extra bit of performance and tighten the memory usage. When processers became faster and memory larger, applications began to sacrifice speed and memory usage for other things (such as development cost/time, maintainability, etc).

As downloading 33K begins to resemble loading a 512K text-based application on your modern PC, higher image quality may begin to become as/more important than compression.

I'd give my right arm to be ambidextrous...

There are some examples using a java applet to render the actual jpeg2k image clientside, which makes for a more impressive demonstration.

http://ltswww.epfl.ch/~neximage/de coder/applets/ They're very slow, though.

Since the comparison in the EE times article is so useless, I decided to do my own testing. I started with the JPEG2000 applet on the NexImage site, and the example they gave there.

I found that the comparison on their site was biased rather strongly in favor of JPEG2000, in two ways. First, their JPEG encoding for comparison was notably inferior to libjpeg 6b with Huffman table optimization. Second, the comparison at very high compression ratios is not particularly meaningful. When compressing at 96:1, there is virtually no image detail present above half the original image resolution. Thus, scaling the original image down prior to compression (the usual practice with JPEG images) produces good results with standard JPEG.

When these biases are removed, the quality gap between JPEG2000 and JPEG narrows substantially. JPEG2000 is somewhat better, most noticeably in its relative lack of chroma bleeding, but the margin is quite slim. My recommendation is to make up the difference by using a little more bandwidth and/or storage.

I've prepared a summary of these results, with example images, on a comparison page. The page is on the slow side of a DSL, so please be gentle :)

I hope the examples on this page aren't typical - the original jpeg seemed to do a much better job - no "out of focus" and no loss of small details.

Here are some quotes from an article about JPEG2000:

Since August of 1998, a team within the Digital Imaging Group (DIG) has been developing a rich file format for JPEG 2000

It surely took a long time to develop it. I hope it's worth it.

Image authors will also have the option of saving the picture in lossless format for archival storage

This is great! It means I no longer need to keep all of these uncomressed BMP files lying around.

Wavelet technology also provides for a continuous download stream of data that allows the user to control the amount of image resolution desired

This is also great. If I understand it correctly, it will allow you to download 30% of the image and get 30% of the quality, download %50 and get 50% quality or download it all and get full quality. But I might be mistaken.

Another innovation is that a new standard, "sRGB" will be the default colorspace for this format. In the current JPEG standard, there is no notion of default colorspace. This lack of precision contributes to inconsistent JPEG color rendering

This is a Good Thing, too. Great for printing.

The JPEG 2000 standard for metadata also provides for extensibility of the metadata properties. In other words, new functionality can be added without having to rewrite the standard. And speaking of adding information, the metadata catalog can be modified without having to rewrite the entire image file. These abilities make for a very nimble, adaptable image file format

Well, we don't seem to need this (using different formats is easier). If the format is too extensible, it can lead to the "get-the-latest-viewer-you-moron!" syndrome, like all the problems with the HTML that we have now.

If all goes as planned, the official schedule for implementation will be released in January 2000

Other good links:

JPEG2000 Requirements and profiles document, V.6.0
SEMINAR ON IMAGING SECURITY AND JPEG2000 - this is an interesting collection of documents about digital image security and watermarking. These gyus take security seriously!
JPEG2000 bitstreams - actual .j2k files for your viewing pleasure (I wish a had a viewer :-)
JPEG2000 Decoder (Version 2.3.1) - written in Java, the source is not available yet (it will be)

Here are some quotes from an article about JPEG2000:

Since August of 1998, a team within the Digital Imaging Group (DIG) has been developing a rich file format for JPEG 2000

It surely took a long time to develop it. I hope it's worth it.

Image authors will also have the option of saving the picture in lossless format for archival storage

This is great! It means I no longer need to keep all of these uncomressed BMP files lying around.

Wavelet technology also provides for a continuous download stream of data that allows the user to control the amount of image resolution desired

This is also great. If I understand it correctly, it will allow you to download 30% of the image and get 30% of the quality, download %50 and get 50% quality or download it all and get full quality. But I might be mistaken.

Another innovation is that a new standard, "sRGB" will be the default colorspace for this format. In the current JPEG standard, there is no notion of default colorspace. This lack of precision contributes to inconsistent JPEG color rendering

This is a Good Thing, too. Great for printing.

The JPEG 2000 standard for metadata also provides for extensibility of the metadata properties. In other words, new functionality can be added without having to rewrite the standard. And speaking of adding information, the metadata catalog can be modified without having to rewrite the entire image file. These abilities make for a very nimble, adaptable image file format

Well, we don't seem to need this (using different formats is easier). If the format is too extensible, it can lead to the "get-the-latest-viewer-you-moron!" syndrome, like all the problems with the HTML that we have now.

If all goes as planned, the official schedule for implementation will be released in January 2000

Other good links:

JPEG2000 Requirements and profiles document, V.6.0
SEMINAR ON IMAGING SECURITY AND JPEG2000 - this is an interesting collection of documents about digital image security and watermarking. These gyus take security seriously!
JPEG2000 bitstreams - actual .j2k files for your viewing pleasure (I wish a had a viewer :-)
JPEG2000 Decoder (Version 2.3.1) - written in Java, the source is not available yet (it will be)

Here are some quotes from an article about JPEG2000:

Since August of 1998, a team within the Digital Imaging Group (DIG) has been developing a rich file format for JPEG 2000

It surely took a long time to develop it. I hope it's worth it.

Image authors will also have the option of saving the picture in lossless format for archival storage

This is great! It means I no longer need to keep all of these uncomressed BMP files lying around.

Wavelet technology also provides for a continuous download stream of data that allows the user to control the amount of image resolution desired

This is also great. If I understand it correctly, it will allow you to download 30% of the image and get 30% of the quality, download %50 and get 50% quality or download it all and get full quality. But I might be mistaken.

Another innovation is that a new standard, "sRGB" will be the default colorspace for this format. In the current JPEG standard, there is no notion of default colorspace. This lack of precision contributes to inconsistent JPEG color rendering

This is a Good Thing, too. Great for printing.

The JPEG 2000 standard for metadata also provides for extensibility of the metadata properties. In other words, new functionality can be added without having to rewrite the standard. And speaking of adding information, the metadata catalog can be modified without having to rewrite the entire image file. These abilities make for a very nimble, adaptable image file format

Well, we don't seem to need this (using different formats is easier). If the format is too extensible, it can lead to the "get-the-latest-viewer-you-moron!" syndrome, like all the problems with the HTML that we have now.

If all goes as planned, the official schedule for implementation will be released in January 2000

Other good links:

JPEG2000 Requirements and profiles document, V.6.0
SEMINAR ON IMAGING SECURITY AND JPEG2000 - this is an interesting collection of documents about digital image security and watermarking. These gyus take security seriously!
JPEG2000 bitstreams - actual .j2k files for your viewing pleasure (I wish a had a viewer :-)
JPEG2000 Decoder (Version 2.3.1) - written in Java, the source is not available yet (it will be)

• http://diwww.epfl.ch/lami/robot s/K-family/vacuum.html
  
• http://www.eureka.com/whatsnew/robotvac.h tm. Hmmm, this looks, *exactly* like Electrolux's, and the two pics there are identical to ones found on Electrolux's site.