Slashdot Mirror

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!

--Ben

Now, suppose people write code based on this patents and the owner decides to revoke the GPL-use license. Fine, we can't write new code based on that patent any longer. But what happens to GPL code already written? So one can't use the algorithm but can re-use the code? Doesn't make sense.

The language "fully paid up" in the patent grant at http://www.levien.com/patents.html, and the fact that document is called a grant indicate that it is a non-revokable conveyance of rights. While I find software patents in general to be execrable, a grant like this allows patent holders to do right for the public benefit while putting themself at minimal disadvantage to proprietary competitors. Until we get widespread patent reform, we can only hope for more grants like this one.

Repeat as necessary:

XML does not guarentee interoperability, editability, viewability, or manipulation.

Please don't think I'm at all down on SVG. It just seems there's a need to remind people that XML does not cure all your object definition and access woes.

• Be based on a sophisticated imaging model with transparency and antialiasing
  
• Have fonts that didn't suck
  
• Be simple and small
  
• Have hooks for adding hardware acceleration
  
• Work with the realtime capabilities in the OS
  

I'd also like to encourage the Gnome hackers to seriously consider working on an IDE similar to KDevlop. That is simply an amazing piece of work. You have all the documentation and tools necessary to rapidly create KDE applications...and it's very easy to use and intuitive. I know that Gnome has Glade and gIDE and there has been talk of integrating the two, but somehow that doesn't seem like the answer. I think Glade should be integrated into an IDE, but gIDE is no KDevelop, no offense to the author(s). A very functional IDE that even new hackers could use, would go a long way to getting further involvment int the gnome project.
----

What Miguel is missing is that Aqua is not about transparency, it's about Quartz, the Display-PDF rendering system.
The NeXT display postscript system and Sun's NeWS could also handle alpha easily, but does anyone think that the
only useful feature of Display Postscript or Quartz is being able to render alpha?



Miguel is intelligent enought to know we're not just talking about alpha channeling. He was saying that libart provided the necessary tools. In case you are unaware, libart is a library for high-performance 2D graphics. It is the antialiased rendering engine for the Gnome Canvas. It supports a powerful imaging model which is basically the same as SVG or Java2D. It does Vector Paths, Bezier Paths, RGB and RGBA images, Sorted Vector Paths, MicroTile Arrays, and Affine transformations.


The best innovations are built on the shoulders of others, and if Miguel would spend more time learning and stealing
technology from Apple, Microsoft, and even the KDE team, and less time dismissing everything and trying to reinvent
it, maybe GNOME wouldn't be so buggy and unusable.


This exact approach has been what Miguel has sought after. He is frequently quoted as wanting to take the best ideas from companies like Microsoft, get rid of the bad parts, and integrate them into Gnome. I've personally conversed with him about this exact issue while waiting to watch Phantom Menace on opening night. He says that he doesn't like it when everyone goes around saying Microsoft sucks and that's the end of the story. Microsoft, Apple, and others, have made great strides with their Desktop technologies, and Miguel has been borrowing from them, believe me.
----

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 :)

Strangely, I found out about this yesterday, when I followed the lwn link to the FreeGIS web site newly created by Jan-Oliver Wagner in Germany.

This site has links to a number of other interesting free software GIS packages, as well as a couple of sources of data.

It is my hope that a real free GIS community will develop. I have a personal interest in this, as I think my libart 2D graphics rendering library has the potential to render maps at a much higher quality than most proprietary GIS packages today (i.e. antialiasing, semi-transparent layers, combining vector with image data). If there's anyone who's interested in integrating libart's cool rendering capabilities with the cool free software GIS apps, both current and future, please get in touch.

Gill (GNOME Illustrator) is a vector drawing program currently in development, which will use the new standard for vector graphics on the web, SVG.

There are basically two types of color matching that are relevant. The first is Pantone spot colors, and the second is ICC. The latter is generally what you'd use when preparing photos and related images for CMYK offset printing. ICC is gaining ground, and is used as the color matching standard in such emerging technologies as SVG.

Pantone is basically a named collection of colors. The cool thing about Pantone is that you can communicate Pantone colors to professional printers, and they know how to match it. Let's say for example that you're doing a business card, and you want your logo to be in black and a nice deep blue. By specifying Pantone 280, you can be assured that the printers will produce the same nice deep blue that you intended. Incidentally, it's not hard to find a Pantone palette for Gimp if you're skilled at Web searching.

Pantone colors are far less useful when dealing with natural images. The Pantone palette is only a few thousand colors, while the standard for scanned images is sixteen million. These are all the colors between "nice deep blue" and "slightly deeper blue than that". That's where ICC comes in.

ICC basically specifies a transformation from a source color space (say, a calibrated RGB such as sRGB) to a destination color space (say, CMYK values for your particular printing press). In theory, this allows exact color matches between scanned, displayed, and printed images, but in practice things are a lot more complicated because (a) people don't perceive color the same way from an emissive display such as a CRT and reflected color from paper, and (b) not all devices can reproduce the same range of colors. Category (b) is especially tricky because the only way to ensure an exact color match is to use a lowest-common-denominator set of colors. As you can imagine, that's not a good idea. It doesn't look very good. In any case, ICC goes at least partway to solving these things.

Now we get to the patent problem. It appears that Electronics for Imaging has some patents that cover the generic idea of colorimetric matching between scan, display, and print. These patents have recently been upheld in court, so they'd appear to be pretty strong. I don't see a way around them.

As far as I know, these patents only apply in the United States. There is some very interesting development of color management code going on outside the US. Perhaps in 2003, when the most important of the EFI patents expires, this means that color management will be free for all to use.

Hope this clears things up.

Wacom drivers have come with XFree86 since at least 3.3.2. I wasn't into Linux before then so I can't say how long they've been around. Wacom's new Intuos line requires a new module; the Wacom site contains this link. The driver there is for XF86 3.3.3.1; if it doesn't work for 3.3.2, here is a link to a (older) 3.3.2 version. Locate xf86Wacom.so on your system, back it up, and replace it with the downloaded file.

The following are the relevant sections of my XF86Config; modify as necessary.

Section "Module" Load "xf86Wacom.so" EndSection Section "XInput" SubSection "WacomStylus" Port "/dev/ttyS0" DeviceName "Wacom" Mode Absolute EndSubSection SubSection "WacomStylus" Port "/dev/ttyS0" DeviceName "WacomCore" AlwaysCore Mode Absolute EndSubSection SubSection "WacomEraser" Port "/dev/ttyS0" DeviceName "WacomEraser" Mode Absolute EndSubSection SubSection "WacomEraser" Port "/dev/ttyS0" DeviceName "WacomEraserCore" Mode Absolute AlwaysCore EndSubSection EndSection

The Core devices are not necessary unless you want your tablet to always control the mouse cursor. Including them causes a small problem if you want to use the tablet in a window instead of over the whole screen in that the tablet will move the mouse pointer and the in-window pointer at the same time.

You'll want to use GIMP 1.1 to try out the tablet. (GIMP 1.0 doesn't support XInput which is the driver system the tablet runs off of.) Especially relevant are the Ink tool and the "Input Devices" and "Device Status" dialogs.

If perchance you want to use the tablet in X without a mouse, download my Calcomp drivers (whether or not you have a Calcomp tablet); the README file explains how to do it.

ElpDragon.

This is work in progress - the antialiased text integration has not been done yet, even though I do have code for smooth antialiased text rendering from type1 outlines. See this screenshot for a "technology demo."

I personally am not that happy with the idea of taxpayer funding. No matter what the source of funding, there's the danger that the priorities of the funders will distort the work.

So, in an ideal world, funding would operate in a manner analogous to free software itself - totally decentralized, with funding coming from individuals, and with an absolute minimum of extra layers of management and administration.

I've been thinking about how to do this. At the core of my idea is a cryptographically sound mechanism for identifying the members of various groups, for example, legitimate free software developers. My idea is based on certification by peers, and also has the property that it's very difficult to attack, i.e. if some imposters managed to get certified, they'd be able to do only a very limited amount of damage.

The link above talks mostly about the techinical issues. However, the social ones are even more important. Christopher Browne has written a proposal that goes into much more detail at this level - you might have seen his letter to lwn.net a couple of weeks ago.

My ideas are too rough and unfinished right now to do anything concrete. When I get the prototype running, I'll try to write up the ideas in less drafty form.