Slashdot Mirror

If you do that, it's quite possible you'll end up violating a license or two, yes.

Take a good look at the .ocx and .net libraries you have on your system. It's almost certain that at least a couple of those come from some program that you installed, and that can be only redistributed by the licensee, or require paying royalties.

So yeah, if you link against those, and the company that makes them finds out, you may end up in a lot of legal trouble.

For instance, the Second Life client comes with the Kakadu JPEG 2000 image library. But just because you downloaded SL for free, and that put the kakadu DLL on your system, doesn't mean you can take that library, make an application that uses it and redistribute it. See the license. Linden Labs has paid for Kakadu, but that license isn't transferrable, so it doesn't give you the right to use it.

You really have it good with the GPL, because releasing the source works for fixing the problem. Infringe on Microsoft's copyright and it's very doubtful you'll get away so cheaply. Most likely MS will get an injuction against you, and you'll have to pull your product from sale until the case is decided.

It's not JPEG it's JPEG2000. There's a big difference, try it out here: http://www.kakadusoftware.com/

Then you will be looking forward to more widespread use of JPEG-2000 and its associated JPIP protocol which provides progressive quality and interactive (multi-resolution and spatial random access) streaming delivery of (up to, depending on how long you wait) loss-less quality images over something like a 9600 bps GSM link.
Multi-GigaPixel images are not a problem, assuming you don't need to see every pixel in full loss-less quality. Typical loss-less compression is about 2 or 3 to 1. Lossy is pretty good down to about 1 to 0.5 bits per pixel.
Encoding on one of these machines might be a bit of a chore, but viewing with a JPIP client would be quite plausible, if one is ported.
Check out http://www.kakadusoftware.com/ for some JPEG-2000 command line tools (non-Windows users will probably be disappointed with the lack of a JPIP viewer) and http://jpeg.org/jpeg2000/.

I can't speak to the standard, but I can cover our experiences using Jpeg2000. In early 2001, the Second Life team did an evaluation of available still image compression schemes in order to determine whether an off-the-shelf solution would meet our requirements of providing flawless visual reproduction at 10:1 compression while preserving chroma at compressions of 100:1 or more, allowing progressive streaming in order to handle level of detail and mipmapping, and be high performance enough to allow for multiple packet decodes per game frame. We went into the search assuming that we would end up having to write out own compression scheme and were pleasantly surprised by the performance of Jpeg2000. We selected the Kakadu libraries for Jpeg2000 compression and decompression and have been happily using them for 3 years on Linux, Mac, and Windows.

It is a shame that Jpeg2000 hasn't seen wider adoption, as it is visually far superior to Jpeg at similar compression levels, especially in reduced "ringing" around high-frequency edges, and its ability to handle progressive streaming is incredibly useful in interactive environments. In Second Life's case, images as large as 2048x2048 are delivered interactively to the client viewer, with a single packet providing enough detail for distant textures. As the user approaches textures, additional packets are delivered to the client, providing a progressive increase in detail with very low latency, thanks to Jpeg2000's ability to deliver fine-grained increases. Kakadu's high performance has also been critical, since many scenes in Second Life have thousands of different textures in view because of user created and uploaded textures.

Yes. You do a VERY small amount of math to see how much lossiness is acceptable at a given resolution and then send THAT MUCH of the file. If you only want half the detail of a JP2 then you only send half the file. Theres no real 'processing' involved unless you want to get into the cooler aspects of JP2 like the format supporting requests for individual portions of an image (for zooming).

To see some of the cool things that dynamic jpeg2000 serving can do go here and get this then run kdu_show and it will register the jpik:// URL type for you to use in IE then go check out the JPIK image links here which include UDP and TCP images for you to view via the jpik client.
You can do it in linux and non-IE windows too but its more complicated because of not being able to natively call the JPIK client from the browser.

Yes. You do a VERY small amount of math to see how much lossiness is acceptable at a given resolution and then send THAT MUCH of the file. If you only want half the detail of a JP2 then you only send half the file. Theres no real 'processing' involved unless you want to get into the cooler aspects of JP2 like the format supporting requests for individual portions of an image (for zooming).

To see some of the cool things that dynamic jpeg2000 serving can do go here and get this then run kdu_show and it will register the jpik:// URL type for you to use in IE then go check out the JPIK image links here which include UDP and TCP images for you to view via the jpik client.
You can do it in linux and non-IE windows too but its more complicated because of not being able to natively call the JPIK client from the browser.

Yes. You do a VERY small amount of math to see how much lossiness is acceptable at a given resolution and then send THAT MUCH of the file. If you only want half the detail of a JP2 then you only send half the file. Theres no real 'processing' involved unless you want to get into the cooler aspects of JP2 like the format supporting requests for individual portions of an image (for zooming).

To see some of the cool things that dynamic jpeg2000 serving can do go here and get this then run kdu_show and it will register the jpik:// URL type for you to use in IE then go check out the JPIK image links here which include UDP and TCP images for you to view via the jpik client.
You can do it in linux and non-IE windows too but its more complicated because of not being able to natively call the JPIK client from the browser.