Slashdot Mirror
JPEG2000 Coming Soon
Sonny writes "In a few months time, internet users will be able to make use of the JPEG2000 standard which, its developers claim, enables web graphics to be downloaded much faster than is currently possible. This will not only make graphics-heavy web pages easier to download, it will also preserve image quality. The JPEG standard compresses image files which are then transmitted across the web faster than uncompressed files. Now, researchers at universities around the world have developed JPEG2000, the next-generation image-compression technology under the auspices of the International Standards Organisation. It is the first major upgrade of the standard since it first appeared in the early '90s. What is also important about the technology is its ability to send files without loss of data, which is not the case with current JPEG files. To take advantage of a JPEG2000, web browsers will need a Plug-In for either Internet Explorer or Netscape browsers. These free plug-in's are expected to be available later this year. The extension for the new files will be ".jp2"."
And only two years late, too!
Loneliness is a power that we possess to give or take away forever
Oh, and FP, BITCHES!
"I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush
More pr0n, quicker.
If we aren't all using PNG right now, there's no way we're gonna be using jp2
I think we're just stuck with jpeg and gif for about the next 5-10 years, until browsers in general get reinvented.
Why .jp2??? Why not .jpeg2. This legacy DOS naming convention drives me nuts. Not even Windows is crappy enough to still require 8.3 filenames.
I still cringe when I see default.htm. It's a frickin' html file, name it properly.
-Ben
The JPEG standard compresses image files which are then transmitted across the web faster than uncompressed files.
excellent, using jpeg2000 increases my bandwidth too!
There I was thinking they downloaded at the same speed but in less time!
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I don't want to be a nay-sayer in any way, but I predict that this will catch on about as quickly as PNGs replacing GIFs. Most professional quality sites still use GIFs instead of PNG, even though tools such as Adobe's Imageready and Macromedia's Fireworks have supported the PNG format alongside GIFs for a while now AND most major browsers support PNGs natively (which wasn't the case not too long ago, with IE4, I believe).
.jp2 format doesn't require a plugin for 99% of the browsers out there, it won't be widely used, IMHO. Of course, I could be wrong and the .jp2 format might not even be meant for wide-spread adoption, and mainly for particular niche uses (such as viewing hubble images or replacing the need for lossless TIFFs).
Until the
Just my $0.02.
What is also important about the technology is its ability to send files without loss of data, which is not the case with current JPEG files.
JPEG does support a lossless mode, it's just that no one uses it. To paraphrase, JPEG supports a lossless spatial algorithm that operates in the pixel domain. Some amount of prediction is used, resulting in about 2:1 compression, but the error terms for the predictions are included in the data stream (encoded using either Huffman or arithmetic coding), resulting in no net errors.
What's a lot more exciting is JPEG2000's use of wavelet compression, which isn't mentioned at all.
porn sites get more efficent, making more money, or will they lower their fees...
tough choice.
Runnin' On Empty
About time! JPEG 2000 was mentioned in Electronic Engineering Times many years ago. The next revision of Artwalker.com (where you explore the world though landscape paintings) will be completely displayed using JP2 because it has one vital characteristic: Images can be scaled in real time (via the server). For example, instead of displaying a thumbnail of say 50x60 pixels, and having the user click the thumbnail to view the full size image (say, 640x480), a JP2 image can be made to display as a percentage of the total size of the display window (or browser width) in a similar fashion to a vector graphic, such as that generated by Flash. This will be excellent for mobile devices with differing screen resolutions and make for some very cool ZOOM tools on browsers and in Photoshop etc. We have been waiting for this since 1996, when we launched Artwalker! Soon it will be time to get going on converting all our high resolution images to JP2. A lot of work!
O'WONDERWe're working on it.
See this bugzilla entry for Mozilla's jpeg2000 progress.
Doesn't seem too promising:
If you look at appendix L of the jpeg2000 draft, there are 22 companies who believe that implementing the spec may require use of their patents.
PNG still hasn't taken off despite being supported in all major browsers (now if only IE did proper alpha, any year now...), how much chance does an image format that requires third party plugins have?
no, it's subdivided many, many times. mostly by factor of 2, but probably adaptated (like 800px -> 200px+600px).. it should stop subdividing at about 8.
fucktard is a tenderhearted description
I want to delete my account but Slashdot doesn't allow it.
Don't think that just because it causes the user to download a plugin that web developers will be afraid to use it. After all, just look at Flash.
However, I think it'll really catch on whenever the next versions of the browsers are released with standard support for JPEG2000.
...smaller files than JPG.
Sorry, try again. An image compessed with PNG (even at the highest compression setting) will tend be considerably larger than the image compresed with JPEG. What PNG gives you is lossless compression and an alpha channel (that's not even properly supported in many browsers).
I read the internet for the articles.
I thought this was a good comparasion between JPEG and JPEG2000.
I remember a similar promise made about LZW compression in the GIF standard by Compuserve. What is to stop these companies from requiring license fees at some arbitrary point in the future once the technology is widely used?
Additionally, there doesn't seem to be very much due dilligence performed in regards to other patents over the techniques utilized in the standard. Even if all of the known patents are licensed royalty-free, there exists the very real possiblity that a submarine patent will be exposed, after the standard is widely utilized, of course.
Of course, this won't matter once all of our PCs are replaced with sealed, SSSCA-compliant, government issued "convergence appliances"... :-)
I've been involved in JPEG 2000 for a while now, and come to the conclusion that..
:).
:) karma in offtopics.
A) It's an excellent codec, though computationally heavy
B) The design of the codestream along with JP2/JPX file format has a lot of potential to create a "new" type of image that isn't just a picture. Yes, you've heard this before, but this time it's built in at a codec level. In stream ROI's, very flexible reconstruction and compression controllable through great numbers of options - and that's only the codec (at a *very* rudimentary level
C) It won't succeed without a decent opensource, "IPR free" (as much as is possible) implementation.
D) Read C again. It's important
To this end, I've started (with support from others in the JPEG 2000 community), a JPEG 2000 Group (See http://www.j2g.org - It's very sparse at the moment, but if you're interested, bookmark it and come back in about a month). Tom Lane and IGJ have expressed no interested in JPEG2000, for various reasons (which I don't entirely disagree with, but I'd rather be proactive and try to correct flaws than walk away totally).
The aims of the JPEG 2000 Group are to create a public, open source (probably BSD license) implementation of "Part 1" (This is the codestream syntax, codec, and file format wrapper). We'll also provide a community JPEG 2000 resource. To facilitate this, we've already attained a Class C liaison with the committee. This grants all members the option of acquiring the standard free of charge. We also get a minimal channel back into the process to give opinions.
The point of this ever rambling post is this : We need members. The standard is large, and the support around it will be larger. We need volunteers who would be interested in assisting in the creation of the codec. Sadly, "Membership" is going to require some form of contribution and commitment to acquire copies of the texts you'll need - I hate this as much as you, but it was accept it, or don't get any copies at all (without $$$). If you're interested in contributing in any way (code, documents, testing, support), please drop by the at forum - Even if its only a passing interest, I'd be happy to go into more detail regarding the project (or just JPEG 2000 itself). I'd do it here, but I'd loose all my (low
So, rather than bitch about the lack of a free implementation and how late it is, and how it'll never get used, come and help out! You know you (might possibly | maybe | someday) want to!
anytime soon that is. To take advantage of a JPEG2000, web browsers will need a Plug-In for either Internet Explorer or Netscape browsers. I don't mind downloading a plug-in to get faster images. but the average user only knows plug-ins as the airfreshener glad makes. Not to mention will a company be willing to switch over to using this format since most average users won't see. Unless IE, netscape, mozilla, etc get support for it by default it won't be used to much.
web browsers will need a Plug-In for either Internet Explorer or Netscape browsers.
or some of us that compile our own code and use dynamic and static libraries, the change would be as transparent as recompiling libjpeg.
just another reason I like open source.
badness 10000
It's good to see the porn comments piling up. This is worse than the body count in a bad slasher flick.
--- I used to moderate, then I read the -1 articles and decided having to filter through them was not worth it.
What a narrowminded and stupid thing to say. You will never update a browser that removes standard features? So in otherwords, you want your browser (/OS/all other programs etc) to be a collection of legacy junk which can never be changed for fear of alienating you? Changes sometimes need to happen, and given that by the time the change to 6.0 happened there was no plugin that I ever ran into that didn't have an ActiveX version, there's no reason for your ranting.
Everyone is still using old formats like GIF and JPEG.
But there are other, more powerful formats.
For a non-descructive compression, the PNG format is fortunately getting more and more popular, although the late inclusion in Internet Explorer slows down its wide adoption.
But when it comes to a destructive compression, there's an excellent (and not new) format made by AT&T and called DjVu. It was one of the first wavelets-based format.
DjVu is really better than Jpeg. Images are better looking (more contrast, less pixels with odd colors), and files are way smaller. Plus you can smoothly zoom any DjVu image without getting big and ugly blocks.
DjVu has been available for a while as a plugin for common browsers.
There's a 100% free implementation of the format called DjVuLibre .
However, nobody uses it. I don't understand why. Some times ago, it may have been because compression was slow. But nowadays, it's no more a valid point.
People are enthusiast for Jpeg2000. But why would Jpeg2000 be adopted while DjVu has never been?
{{.sig}}
Because you can write a plugin/ActiveX control today and have anyone who uses a compatible browser download it (in a small download) tomorrow. It takes a lot longer to roll a new release of a browser, and a lot of people won't upgrade.
Now that everyone has broadband and can play streaming video.....
It's always good when the submitted story is more up-to-date than the site it links to. The current press release" on the site is dated August, 2000.
Could this story be submitted by an insider? Hmmm... I know, I know, Slashdot != "investigative journalism"
Some people have a way with words, and some people, um, thingy.
According to this pdf,
.9
the report compares 4 compression codecs, and found for a small sample found:
MEAN LOSSLESS COMPRESSION RATIOS (big is good)
------------------
JPEG 2000: 2.5
JPEG-LS: 2.98
L-JPEG: 2.09
PNG: 3.52
JPEG-LS is was usually the best, but PNG had a few really good sample that pushed its average up. Actually, these outliers appear important, because that is what really separates the codecs on this metric.
Lossless Decoding Times, relative to JPEG-LS (big is bad)
-----------------
JPEG 2000: 4.3
JPEG-LS: 1
L-JPEG:
PNG: 1.2
This doesn't make JPG2K appear too impressive. What it does offer, however, is features. Like Region Of Interest (ROI) coding, good lossy compression, random access, and other goodies that some people may really care about. The report claims that png doesn't do lossy encoding, which is news to me, but it does appear to be one of their major selling points for jpeg-2000 over png.
Hey, I've implemented a JPEG-2000 codec using
a BSD-style license.
It's been tested at the MIT biodmedical department already for compression of medical images.
It's available at http://j2000.org/.
It would be nice to see this work in my favourite browsers.
Several things, besides simply "good compression."
JP2 uses wavelet compression such that an image is effectively compressed at various resolutions below the originally, independently. Not only does this allow a high level of redundancy removal (which is why wavelets are good in the first place) and thus high compression, but jp2 tags each of these sections (subbands) separately in the compressed file.
So what? Well, a file with all of these sections is effectively a losslessly compressed image. However, this file can be further compressed (loss-ily) by simply throwing out some of these tagged sections! That is, you can make a "lossless" thumbnail image by keeping all the lower resolution subbands. Or, you can get a lower-quality (but smaller) fullsize version by throwing out some subbands at each resolution.
Better still, this manipulation can be done without decompressing the original image. Simply using only certain tagged sections of the file.
Consider this possible application of all this: Digital Cameras. A camera could take images at full resolution and lossless quality until the memory card starts filling up. Then, gradually as more and more room is required, it could quickly reduce the size or quality of previous pictures to make room for new pictures. Thus, you always have "enough" room for more pictures, provided you don't mind the quality reduction.
Of course, there are numerous uses for web applications -- thumbnails and full-sized images could be the same file, provided the web server knows how to parse the image file. (Little or no computation necessary, just sending parts of the file)
Anyways, JPEG2000 is very very cool.
Yes but this change "needed" to happen because MS managed to become the big player, and didn't want people writing plugins that would work with MSIE and Netscape, they wanted them to write a MSIE only ActiveX control, and then decide the extra effort needed to support Netscape wasn't worth it.
It's not like oh, say, dropping a.out because it doesn't support all the debugging symbols you might need, or it is hard to support shared libs with a.out...in that case you are really buying something for your pain. In MSIE's case they are getting something for your pain, and what they are getting is more pain for you.
Not my idea of a good deal, but if you like it, go for it.
"What a narrowminded and stupid thing to say. You will never update a browser that removes standard features? So in otherwords, you want your browser (/OS/all other programs etc) to be a collection of legacy junk which can never be changed for fear of alienating you?"
Um, no. I don't want to upgrade to a browser by a company who wants to bend standards in their favor, leaving other browsers unable to cope. The advantage to Netscape Style Plug-ins over ActiveX controls is that they play in other browsers like Netscape (DUH!) and Opera. This isn't a case of an old standard no longer being followed, it's a case of MS changing the de-facto standard so that IE remains dominant. So no, I'm not willing to change browser/OS/etc over this.
Now that IE doesn't support non-standard controls, this means that anybody who makes an IE plug-in is stuck making an ActiveX interface.
My favorite browser is Opera. It doesn't support ActiveX. According to their site, it won't support ActiveX. Here's a quote:
"Opera does not support ActiveX, nor does it support VBScript. There are three reasons for this:
Opera Software AS is committed to supporting open Internet standards, recommended by the W3C, something neither ActiveX nor VBScript, being license issued Microsoft technologies, are.
The second reason is much more simple: There's just not enough market demand for these technologies to warrant the cost of implementing them.
In addition, some reports raise the question of how secure ActiveX is. It has been claimed that ActiveX has serious problems with security, and some even say that the problem is an almost complete lack of security. The same concerns have been raised about VBScript."
So besides making me stick with an insecure plug-in interface, what other reason is there for me to go to IE6 or newer?
"Changes sometimes need to happen, and given that by the time the change to 6.0 happened there was no plugin that I ever ran into that didn't have an ActiveX version, there's no reason for your ranting. "
Changes? Sure! But to disable a widely used technology? Uh uh. Sorry. I'm not rolling over and taking that. True narrowmindedness would be if I were to say "Okay Microsoft, thank you for making the choice for me. You know more than I do!"
As for not being able to get an ActiveX version of a plug-in, I can give you an example: The company I work for. (Who shall remain nameless.)
IE 6's betas supported our plug-in just fine. And then, once it was released, I had customers telling me it no longer worked. Somewhere between beta 2 and release they removed support for it. Did they tell us (a registerred MS Developer...)? No. They just did it. Their knowledge base called the removal of Netscape Style Plugins 'a security feature."
Interesting, I guess not being able to run as much stuff means less chance of security breach. Whatever. Maybe if MS had said "In 6 months when IE 6 is released, it won't support NSP's" Id have little room to gripe. But MS just did it. So my company (a startup company I might add) is forced to write an ActiveX control. We looked into it, and its not as easy as it may seem. For one thing, our product has a lot of web-based features that would all need to be rigourously tested. Since browser functionality is not our core focus right now, we don't have the engineering time to spend on it. Do our customers understand that? Only after I explain our priorities to them.
The worst part is that IE doesn't give any clue as to what is wrong. The behaviour of running a NSP on IE is the same as not having a plugin installed at all! What a wonderful way to prevent MS from getting customer service complaints!
In any case, thanks for calling me narrow-minded even though it's pretty obvious I know more about this topic than you do.
Getting back to the original topic, I hope the JPEG2000 group releases a Netscape Style Plugin so I can use it with Opera. I am geninuinely concerned that what they'll do is release an ActiveX version because IE is the dominant browser, and that's it. If they do that, they'll be further supporting MS's dominance. Unfortunately, I can see JPEG2000 causing that if the images are really as compressed as they say.
"Derp de derp."
Am I missing the joke - is this some sort of overdue April Fool's joke? Did this story get sent here by Mallett's time machine from last week?
/. just regurgitate somebody's press release?
Or did
As far as I can tell with a quick google, nothing has been done with this standard since early 2000 (maybe that's why the standard name hasn't been updated, eh.) I wouldn't hold my breath waiting for widespread adoption any time soon...
"I don't give a flip if it's a plugin, activex, or a fucking fred flintstone bird inside a camera...if I can still access the SAME content, and it still renders correctly, and perhaps renders more reliably and quickly, well, let them do what they will. "
You'll give a flip when you decide to switch to a new browser (or a new OS that doesn't have IE on it) and half the internet doesn't work for you.
I can't believe people are actually responding with "It's okay that the internet only works with IE!", did I wander off of Slashdot and not realize it?
"Derp de derp."
While you don't often see it "in the wild" as it were--except in some Japanese manga newsgroups where it's the standard since it's lossless--it's very often used when working with graphics. Unless you need to save with seperate layers, why use bulky formats like .PSD or .PSP when doing graphics work and needing to save your work losslessly, when .PNG is usually so much smaller? I save everything as .PNG for future work, and then when it goes up on the Web I can batch output crappier-quality .JPEGs.
So, the PNG format is a resounding success among those who work with images, and then we dumb it down to JPEG or GIF for the end users.
All that said, I don't see the JPEG2k standard really succeeding--now that more and more users are getting faster and faster connections, there's not that much need for the smaller filesizes. Combine that with the fact that users have to install a plugin to see them--and God only knows which browsers and what versions they may be using--and I don't see webmasters clamoring to adopt it, and if they don't adopt it in large numbers, the format will never catch on. So it's very iffy at the moment, IMHO, as to whether the new standard will ever replace the old--certainly not in 5 months from now, and probably not even in 5 years from now, since the need for file size savings keeps slowly evaporating.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
The extension for the new files will be ".jp2"
.jp2
I wonder what the Pope thinks about the file extensions being callled
This will not only make graphics-heavy web pages easier to download
Oh great! Even more websites designed with the idea that Photoshop is a webdesign tool and that the best way to make a webpage is lots of massive images instead of text and styling.
Mumble mutter grouse.
Good thing it looks like it'll take ages to catch on.
Karma: T-rexcellent.
I thought this was a good comparasion between JPEG and JPEG2000.
Good one. Thanks for the link.
Looks like JPEG2000 finally got things right for the human eye:
- Higher compression ratios just gently blur details, rather than creating artifacts. Losing the extra information leaves the part that DID get through intact.
- The text says the compression allows for progressive downloading. This implies that the coding scheme does something like working upward in spatial frequency - encoding the basic stuff first then sending progressively finer deltas. For a given compression ratio just stop the downloading (or file saving) when you have enough.
- The compression seems to match eye processing so well that highly compressed (100:1) images actually look BETTER than the basic image. The features important to the eye (facial stuff, especially eyes) gets through or even enhanced, while unnecessary detail - including sampling artifacts - gets selectively blurred out. Something like the soft-focus filter in portrait photography. The only thing in the samples that got noticably worse at high-compression is hair, which just gets a bit blurry. (Meanwhile, JPEG looked like it had pixelated measles.)
Of course the images selected for the demo could have been optimized for the compression scheme. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
true enough. In a perfect world all relevant file data including type would be internal to the file itself, so it couldn't be screwed up so easily by changing the name or mistyping.
Heck, I don't see why there should be any more than one file type for still pictures (or audio, or video, or indeed any media in general), with an internal marker indicating what the file format and compression is. Having to worry about changing a reference to a file (say on a web page) because you changed the file type and therefore the name is a pain.
---If you can't trust a nerd, who can you trust?
Unfortunately, one effect of better compression will be more bloat -- web pages with more graphics and more advertising. This is because with better compression, there is more information transmitted per byte, thus giving more value, so the decision about whether or not to include pictures tips in favor of more and bigger images. Thus the average size of a web page and all its components will increase.
If you think the images are valuable, as many web designers seem to for incomprehensible reasons, that is a good thing. But if you do not value lots of images, that is a bad thing. So, better compression harms those with slower links, those who detest advertising clutter, and those who seek concise information rather than flashy presentations.
(I am not opposed to better compression, just pointing out an unintended consequence.)
If there's any indication that this will actually be out in a few months, I missed it.
If there's anything indicating JPEG2000 support for Mozilla, The Gimp, Paint Shop Pro, or Photoshop in the near future, I missed it.
I've yet to see anything that indicates there are no more patent issues and that people can support this format without patent issues (Read "Can the Gimp ship with this?")
Regarding Exploer PNG support:
AlphaImageLoader Filter:
Displays an image within the boundaries of the object and between the object background and content, with options to clip or resize the image. When loading a Portable Network Graphics (PNG) image, tranparency--from zero to 100 percent is supported.
Just because I do miss it, I still see almost no support for the beloved fractal image format *.fif I think it's now part of LizardTech's line of image compression/fractal tools. If you think jpeg200 offers compression, then you missed the fif format completely.
No Zen is good zen
I think it's fair to say that ActiveX is a superior thing to netscape style plugins. for one, you don't haev to download and install, they just work. That's good for 99% of MS's customers. Netscape is pretty much irrelevant at this point anyway.
There was a dead link about "watermarking" on the page. Does this mean we'll be seeing "copy protection" built into images?
.png standard. Human eyes don't see blue well, just make it lossy (one time, saving again doesn't make it worse) in the blue spectrum.
I say we just refine the
~ Why is there no reason modifier for overrated posts?
Nah, it'll probably make easy to download web pages more graphics heavy, if I know today's web designers...
-- Is "Sig" copyrighted by www.sig.com?
I can't wait for the new IE exploit using the jpeg2000 activeX control (sense IE now doesn't support netscape style plugins).
What is pirate software? Software for inventory of stolen treasure?
A few characters per file name - yes those couple of bytes will save gobs of bandwidth.
2. Easier to type.
How often do you actually type file names? I do it once - when I create the file, I think I can afford the few seconds.
3. Backward compatability.
With what??? I am willing to bet that whatever you dig up that requires 8.3 will not be compatible with the actual file format.
I cringe when I see people have named the file some big long gobbledegook like bobbys_8th_book_report.doc when bookrep8.doc would have done just fine.
Yes, that's a stupid name, and no bookrep8.doc is not better. Who numbers their bloody book reports? I think little bobby will get a bit confused a few years down the road when he gets to bookrp48.doc How about "steppenwolf report.doc"? or "glass bead game report.doc", I really do think I see how these are better than stpwlfrp.doc and glbegarp.doc
sic transit gloria mundi
Comparisons with png/gif history are NOT valid here, although such ARE usually a foolproof tao of the karma-gatherer ;). Those who make them are probably not aware of the difference in quality/size ratio between wavelet compression and the current (pathetic) jpeg. It is not only "beefed up" jpeg, people. It is qualitatively different, using completely different philosophy and algorithms so smart that the FBI people probably got them from aliens in exchange for not drilling their testicles. They lied, of course - but the aliens delivered.
What thrills me even more is the possible application of wavelet compression algorithms in 3D.
See this for a dramatic flash-based demonstration of advantages - notice that it says 4kb!:
http://www.luratech.com/index_e.html
It's still useful for a human being to be able to take one look at a filename and determine the type. I think 4 letter extentions are the maximum usable for that purpose, and 3 is good.
Vintage computer games and RPG books available. Email me if you're interested.
WTF are you talking about? The poster specifies that it's fine to use the new version as long as it's supported. That is to say that it's unreasonable to prevent him from using the new version as long as it's accessable to others. That's a completely different thing from what MS did, which was to implement a new way of doing things specifically to prevent others from supporting it. There's nothing at all hypocritical about saying 1 and not 2.
There's no point in questioning authority if you aren't going to listen to the answers.
LuraTech has been shipping a JPEG 2000 broswer plugin (and Photoshop plugin) for a while. I've had problems with their jp2 file format. It's a new and very complex standard so expect some startup pains. http://www.luratech.de/index_e.html
Dr. David Taubman was one of the authors of the JPEG 2000 spec. His book on JPEG 2000 is now available. He has also released a very nice SDK for compressing, decompressing, manipulating and streaming JPEG 2000. It's called Kakadu and you can read more at http://www.kakadusoftware.com/. The source code for Kakadu is packaged with the book. There are demo images and software at this site also.
Let's be honest, IE has a rubbish renderer, full stop. It's not just this.
Two things scream out at me. One, I can reliably set up layouts with nested tables which, under IE, display in a way which is indisputably incorrect. Two, we have a bunch of machines at work which muck about with several sites we've produced. Essentially, IE doesn't render the images right. Occasionally it doesn't render an image at all (rare but has happened, and it doesn't leave a placeholder because it doesn't realise it hasn't shown it up) until the image is clicked on or scrolled off the screen and back on. More commonly, it sticks a suprious transparency in place of white on some images, or even effectively makes the whole image slightly opaque. When there's an image background, that gets messy...
Bottom line, it's sloppy.
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!
You have an interesting point--bandwidth is getting more dear, now that the pyramid-scheme banner advertising revenue outfits have been going tits-up. However, I just don't see most website owners risking their livelihoods by implementing an image format which most of their customers, plugins or no, may not be able to read--particularly since so much of web layout is done using images these days instead of text.
Think about it--how many users are set to automatically download plugins as needed? Almost none because of security reasons. herefore, some active decision is needed on behalf of the user to actually install the plugin or not. What will be the user's reaction if he goes to the site of WidgetCo, doesn't know what to do with this dialogue box about installing stuff (especially if he's been told be friends or company that installing strange software can be dangerous, or if he's been molested by the likes of CometCursor), says "No", and gets a page of big X's where all the buttons and banners should be? Well, it might well be to go to the site of WidgetBiz instead to get his widgets there.
This is why I really don't see JPEG2k taking off. It's a risk most companies won't take--you don't want your users not being able to use your site. Look how long it took Flash to become as common as it is today--many years, and then only because it started shipping by default with Windows.
I have no doubt that IE7 will have JPEG2k support--poor and half-hearted support. As with most Microsoft products it'll probably take the until the second major release to get it right, so let's say IE8 will have fully implemented JPEG2k support out-of-the-box. How many years will it be until that's out? And how much further along will available bandwidth be by then?
I could well be wrong, but I just don't see this taking off. Unlike Flash did, it doesn't bring anything spectacularly new to the table--a few people have been talking about the visual effects you can get using wavelet images, but those same effects are common (if poorly implemented) Flash effects today, in addition to the many other effects Flash does. So that leaves us with the better compression over JPEG as its big marketing point...and I just don't see that being enough to get website owners to risk alienating end users. So *at least* until great JPEG2k support ships with IE out of the box, and that version of IE is common, I don't see JPEG2k going anywhere except into some niche markets.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
That may be, but that alone isn't a reason to drop support of the plugins.
I fully agree that the file extention should be the last thing a program bothers checking, but extentions are still good for human use. What you're saying could be applied to CDs; cases should all be blank, just look at the CD inside. And you're correct, the wrong CD could be in a given labled case. But that doesn't matter; it's not the end-all and be-all of file indexing. It's just a useful thumbnail.
Vintage computer games and RPG books available. Email me if you're interested.
Yes this is karma whoring a little, but it's a good article
I hope they have added a metadata section where data like author, date, etc could be attached internally to the image.
I always thought it would be cool if your digital camera could include the settings (fstop, exposure time, ISO, etc, compression ratio) along with data, time and author directly in the image file.
Here's a summary of the jpeg2000 situation that I wrote up, but never made it into bugzilla:
Heck, I don't see why there should be any more than one file type for still pictures (or audio, or video, or indeed any media in general), with an internal marker indicating what the file format and compression is.
Ever heard of TIFF? That's basically what TIFF is, a picture format that lets you specify compression type, and pretty much everything else, inside the file. Why don't people use TIFF much? A big part of the reason is that there's so many options nobody supports them all, so you have to be careful when exchanging TIFF files that all sides can read them. Also, whereas a PNG's data is always sorted in an order easy to display, a TIFF can be in arbitrary order.
That is, the main advantage PNG has over TIFF is that you know what's in the file and that it will be easy to display. Your format would have all the problems of TIFF, except that instead of writing one reader for TIFF's elegant internal format, you have to write an endless stream of readers for an endless stream of internal formats.
Are the three extra 0's really necessary? why is it called JPEG2000 when the year 2000 was 2 years ago? why do people insist on stupid marketing hype names? why the f/* can't it just be called JPEG v2 or JPEG2? WHY? This is the problem with our world, just like iBook and easyJet, why do people have to come up with this out-dated, over-used, "oh I'm so arty" bull shit? It's not cool, its not fun. Names don't suddenly become boring and grey if you don't string words together or not capitalize the first letter. We're not writing code, and most of the people who do come up with these names are not really geeks so they don't have any excuses such as 'I never name variables with spaces' or 'I never capitalize names or 'i's'. Lots of systems don't have problems with spaces (especially Win. 9x where I see way to much of this) anymore so why do people do it? its just annoying to the point of making a perfectly sane person write a long post ranting about it.
I wouldn't mind normally, but if this is going to be used for the next 10 years, lets not give it a stupid name.
I'm sure this has already been mentioned but I couldn't be bothered to go through 200 posts.
Now I must prepare to be modded down
This comment does not represent the views or opinions of the user.
but... surely .jpeg2000 would be more accurate
--- My dad's political betting
I have a file of OCR'ed pages from a book, all UTF-8 text, all named *.txt. file correctly recognizes 226 out of 229. The other three it seems to believe are "MSX game cartridge dump"s. So if I'm working along through the book in your file manager, I get to these pages, and the file manager opens up a game emulator, which will then spaz out on poorly scanned poetry.
The problem is not so much that file is wrong, it's that file is unpredictably and unfixably wrong. If I have a JPEG named foo.txt, then I know why stuff isn't handling it right, and can fix that easily. If I have a text file named foo.txt that file thinks is a "MSX game cartridge dump", I can either change the data (which is unacceptable) or change the magic (which has further unpredicatble results, especially if I have MSX game cartridge dumps somewhere.)
So, no, when I tell the computer a file is a text file, I don't want the computer second guessing me. All it does is add frustration to my day.
Er, shouldn't that be:
/usr/bobby/school/english/reports/steppenwolf . oc
The directory structure should be descriptive as well, so the filenames can be trivial.
---
Book(n): Utensil used to pass time while waiting for the TV repairman
Is JPEG2000 an open standard, or is it encumbered by patents? Will open source implementations be possible or does someone need to be paid licensing fees?
To Whom It May Concern:
Sadly, nobody. You're lucky if it's spelt right.
Dave
I write a blog now, you should be afraid.
Tell that to all the Mac, Linux, and Opera users out there.
"Derp de derp."
Yenc is a different matter entirely--it's taken off on USENET because it allows faster uploading and downloading for those who transfer massive amounts of binary data by about 33%. That's significant because the hardcore binaries group users leave their machines connected an ungodly amount of the time to their NNTP servers, sucking down pr0n by the thousands of JPEGs and mp3s and videos by the megabyte.
.jp2 images.
In such an environment Yenc encoding instead of UUencoding makes a *very* significant difference. However, the people who are hardcore USENET users are *not* the same as those who are average Web users. Huge difference. Yenc got so big so fast because the hardcore users have the clout in USENET--they're the ones who post most of the content, and if you don't Yenc, you don't get their content.
The Web is completely the opposite of this model--it's a lowest-common-denominator place, where the average end user is the target market and competition between websites is fierce. In the binary USENET groups there are few content providers and many leeches whom no one cares about, with the content providers (posters) having near-total conrol. On the Web there are many content providers, all vying to get as many eyeballs and consumers as possible--the average consumer counts big.
So, any content provider who switches to Yenc on USENET doesn't have to care at all about the dork who wants to keep using an outdated OE to access newsgroups--his audience is his fellow posters, all of whom know about and are starting to use Yenc too. On the Web, a content provider who switches to JPEG2k is risking financial ruin if too many of his customers use software that refuses to view
HUGE difference.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
"Microsoft is the company that supported both plug-in interfaces for a long time, but Netscape only ever supported their own parochial nickle-and-dime plug-in interface, which totally sucks. Get your facts right. "
h .c gi?options=index&name=150
First off, I think you present good thoughts, although you did aim them as an attack towards me, hence the 'get the facts right' comment.
Tell you what though, I'll present you a 'mudslinging-free' response. First, though, I never ever ever said that the NSP interface was superior in any way. The benefit to it that I give any care to is that it works with nearly every browser out there. If it's clunky, fine. I never made a case that it wasn't. Because of that, nearly everything you said in your post had nothing to do with what I said. The reason I posted Opera's comments on the matter was that it strengthened my case that not everybody wants to go ActiveX just because MS says so. Their comment about security got my attention. I didn't think I needed to elaborate on it because I thought it was pretty obvious why ActiveX is a security problem, but I guess I need to explain it.
Any app that supports ActiveX can call any ActiveX control. When we had an ActiveX control, emails in Outlook, for example, could call the control and activate it. Pretty snazzy, eh? Well that exact same feature that I just described means that e-mail can be a launching mechanism for ActiveX controls. Uh-oh, can you say vulnerability? All somebody has to do is create an ActiveX control that has a backdoor in it. And then, to activate that back door, they have so many ways of doing it it's not even funny. They could send an email to trigger the backdoor, they could create a webpage with specific HTML to do it, and so on. Before you tell me this isn't possible, consider that the reason MS is hit so hard by virsues is because it has too many features that are easy to exploit. All it takes is a creative mind and time to do it. Is it as easy with NSP? I'm no developer, but your case that NSP doesn't have a whole lot of features lends itself to the idea that no, it's not as easy.
You are correct that I didn't post my quote very well. I apologize for that. I have a bad habit of posting before reading. You want a link? Fine, here it is:
http://www.opera.com/support/supsearch/supsearc
Pardon me for not doing that right away, thought I'd save you all the trouble by copy/pasting it. Notice it's on Opera's site.
As a plug-in developer (I'm not personally one, but my company used to be...) I don't care who implemented things better. It's a matter of supporting our userbase. Gee whiz, it certainly would have been grand of Netscape to support ActiveX. They didn't. And when we started, it was 50/50 Netscape and IE. In other words, we had to make the choice to support one or the other. We didn't have the resources to do both an ActiveX control and a Netscape Style Plugin. We *tried* but it was very difficult to maintain consistency across them both. It turned into an engineering-moneypit. We needed two different engineers to keep both plugins going. With the NSP interface, we were able to keep it to one. Could better management have eased that problem? Oh yeah, I don't doubt that. Remember, though, that this is a small company and we had to do with what we had.
There are support problems with that as well. It takes a lot of HTML code just to throw up an ActiveX control in a web page, embedding an object is far more simplified. Technical support was a problem, particularly when some people didn't realize they had to play with their security settings from time to time to get it working.
For my company in particular, the Netscape Style Interface was *our* best choice. Keep in mind, this was a company of like 15 people. Also keep in mind that the interface is a WC3 standard. This means that future browsers down the road, in theory, should be supported. I was able to get our plug-in to work in Opera. We certainly didn't want to close any doors. When you're a big company, you can make choices like that and call it 'policy.' When you're a 15 person company, you want to do absolutely 0 to piss anybody off. If you've never worked in a company that small, don't tell me I'm wrong.
So yeah, IE supported them both, and yeah Netscape flubbed the implementation of it. So what? If MS was so in the right to drop NSP support, how come they did it just before releasing IE6? How come the only real update to IE 5.5 SP 2 was to take away NSP support?
Why didn't MS just say "This is an old standard. We're dropping it in the next release of IE in a few months, please be prepared."? This is the part that offends me the most! If MS had done that, I wouldn't be whinging now. This thread would not exist.
"Derp de derp."
Look, I'm a web consultant, I work with a lot of clients and see a lot of attitudes about new technologies, and basically the rule at the moment is that if it wasn't part of the standard distribution of Netscape 4.0 or IE 4.0, you can forget about it. Netscape 4.x and IE 4.x still have just barely enough market share that organizations refuse to abandon 100% support of them.
I think they'd still be trying to demand complete support of IE 3.0, market share be damned, except that it wasn't Y2K compliant. (I think it can still be run, but doesn't work right.)
If I went to a client and told them "use this new image format, it'll save you 90% of your present bandwidth usage, but all of your users will have to install a plugin," they'd fire me for incompetence and use the money they had been paying me to buy more bandwidth.
It doesn't matter how much better the new format is. If it requires 10% of users to install a plugin to use a site made with it, companies won't even consider it. When 95% of users have it preinstalled companies will think about it seriously, and companies that really *need* it will go for it. The rest will worry about losing 5% of potential customers and decide against it. When 99% have it preinstalled, they'll probably use it and not worry about it, unless it has been too long since the technology first came out and they've become convinced that there must be something wrong with it because nobody uses it, like DHTML. (DHTML is now catching on, but I still run into clients who insist that I musn't use it because it doesn't work... while telling me that HTML, Javascript and CSS positioning are just fine.)
"Things like the crossover plugin alleviate the pain of much of these problems, of course. Alternatively your vendor could take the time to write a bridge for ActiveX controls."
We tried that, didn't work initially. If we find some more time we'll investigate it further.
"If that's not enough for you, then maybe you should find something to do that doesn't involve computers, as you're clearly not ready to accept the realities of them. "
The reality is that MS is going to own everything. No, I don't want to accept that. I conceed that having IE be the dominating browser out there is better for the end users. Consider the price we pay for it though. Personally, I like having choice.
I switched to Opera because a.) it has some really nifty and useful features, b.) it's far easier on my memory resources. I guess I should just stick with MS though, that way I can buy a brand new computer every 1.5 years just so I can do the same stuff I've alwasy been doing. Why not? I have money to burn on porn surfing.
"Derp de derp."
Yet again, a filetype goes from reasonably self-explanatory (.jpeg2) to cryptic (.jp2) in order to fit into Bill's broken inherited-from-CP/M-80 filesystem. They merely follow in the fottsteps of their predecessors (e.g.
I guess I should be grateful that it's not
Got time? Spend some of it coding or testing
I think JPEG2000 COULD take off. (notice I'm not saying would yet...)
There's a new market out there that is starved for bandwidth. The Wireless-PDA market. I think there is a wireless Internet Modem out there running at roughly 19kbps. A 5x reduction in size (that somebody else in this thread mentioned) would have a humungous impact on the ability to use these devices. If that's the case, then sites setting themselves up for PDAS would be quick to adopt JPG2k, assuming that the PDA's or Phones connecting to them could use it.
Lets say that happens. Let's say somebody like AvantGo takes advantage of it. It wouldn't take long for JPG2k to reach such popularity that the newer browsers start to support it.
It wouldn't be hard to do that. If JPG2k uses a different extension, then it'd be trivial to write code that assigns an alternative extension if the browser supports it. That'd be kind of neat, actually:
"if you want this site to come down faster, download the latest browser."
Hmmmmmm...
"Derp de derp."
We should have a server that sends the appropriate file type depending on the client request. So if Apache gets a request from an old version of Netscape, it'll send the picture compressed as .jpg/gif, if it gets a newer Mozilla, it'll send .jp2/png, if it gets a PDA, it'll send a 16-color greyscale, etc.
The server is probably a good place to do this (maybe with some mod_rewrite hack), since it could be responsible for caching heavily-requested conversions.
Anything like this exist? Similarly, I've always wanted to find some nice way to keep my photo-album online in the highest quality, but only send scaled-down images to casual visitors (as well as thumbnails). http://ids.sourceforge.net/ looks like it comes the closest to this kind of thing, but looks a bit too server-heavy (doesn't seem to support caching).
- and found it to be an incredible codec.
:P), not to mention a more robust error handling and inclusion of data to tell if you 'cropped' a file
Some of the really really neat features are 'streamable' files- want a thumbnail? Yank off the first 1k of the file. Want an 8x10? Grab the next 500K. Want the full thing? Pull the remaining chunk.
Better still, you can 'order' the file- give an 8x10 as only 30% quality, which is quite good, with the first 10% of the file... or stream a bit more and get better quality. IE the more you can afford to wait, the better the image will look.
Of course there's also the compression and support for large coulor spaces (do we have to talk about file formats and function again?
Also, block size- jpg was limited to 8x8 chunks- j2k starts at 64x64.... so as you can imagine, a large bit of data can be compressed into a very small amount if you are sampling at 64x.
I can not WAIT till this codec is accepted by the industry- there is so much potention it's killed me not to have it available sooner.
Look, now we can do compressed, lossless graphics without GIF's! That means there's no more need for the Unisys LZW patent ---
We have the way out!
Tired of FB/Google censorship? Visit UNCENSORED!
The web pages for djvu talk about the GPL'ed version including a decoder and a "simple bitonal (black-and-white) encoder" and a "very simple color encoder." This makes me wonder how the free encoders are and how they compare in compression and speed to other free encoders, such as those for jpeg and png.
A detailed positive answer to this question might make it worthwhile to more people to risk a couple hundred dollars of their time to try to install DjVu.
t.
What the hell, plugin for Photoshop costs 79$ ?! Does this mean that there'll never be FREE jpeg2000 encoder? That would kill jpeg2000 before it even gets started. I would never pay that much for image compressor, no matter how good it is.
Longer extensions work just dandy with Windows, and have done for seven years - there's no reason why people shouldn't use the extension 'jpeg2'
Heheh.
:)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
/usr was where the user files were kept, way back when. Then one day, someone ran out of space on their root disk... The solution was to create a user called "bin", give it a home directory /usr/bin, and put the less important binaries there.
/usr. The only argument that still works in favour of /usr is making it a network drive. The people who do that will have to customize a bit when the rest of us drop /usr. I am sure they will hate me, both of them.
These days when disks are enormous and logical volume management ensures that you can just add whatever space is necessary where it is needed, we should get rid of
Finally! A year of moderation! Ready for 2019?
What I'm talking about is comparable to the current digital video scene, specifically the semi-open architectures like Video For Windows, Quicktime, and MPEG4. In those cases, producers generally want to worry about codecs (compression/decompression modules) as little as consumers, so a few select ones predominate at any given time until better ones come along. Thus while the stream of internal formats may be endless, it's actually a slow but steady stream. In the better architectures, all codecs are registered and on file with a central server, so if you don't have the necessary codec you can download it automatically. If you really wanted to, you could even include the necessary codec (or whatever) in the file, with a properly designed architecture.
TIFF could be adapated to do all of this with a little effort. AFAIK the main thing holding it back are poor implementations of the TIFF specification and possibly Adobe's ultimate control. MPEG4 is supposed to do for video what I am suggesting, and is actually able to handle all sorts of multimedia data besides mere video. The only thing I worry about with these formats is the overhead they need to be able to specify so broadly.
---If you can't trust a nerd, who can you trust?
The guy writes some working code and gives it away for free. The spec is the documentation for the standard, and anyone who can understand code can figure it out if they want to, but probably won't need to because he has an API, and you rip him a new one for this? That's harsh. This code is hardly 'uterly useless'. In fact, it's the only thing I've seen without Luratech all over it and a generous license to boot. Oh, mabye you work for Luratech. Sorry.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
You could try it yourself, go to that nasa site blue earth or something, get a 50 MB tiff and compress it to a jpeg. Then compress the original and the jpeg with jp2k and see what the difference is. An increase in filesize of two doesn't seem that unreasonable to me. Transcoding only works when the first encoder is very near to lossless.
t.
There is lots of argument on all points of this. My opinion is that putting all the data in the file is the best solution, primarily because it can't get lost when the file is transmitted somewhere, but also because it is easy for a program to read, write, and alter it. But there is a lot of legacy files with no space in them to put such information. I consider the Mac id and the filename extension to be pretty much the same solution (put a few bytes of id somewhere other than the data stream).
The only argument against doing this is the impracticality and expense of putting this circutry into each case, and the need to have designed CD's from the start to have space for this data. This actually matches the arguments against putting all data into the file stream (arguments I am finding very weak nowadays).
Violating the rules of "file" will cause it to fail.
Sure. The problem is not file, but in people wanting to use file automatically. A large portion of the files on my disk don't have magic numbers, so file can't be used automatically to identify files for a file manager.
In any case I would expect it to be much more reliable than either filename extensions or Mac ids, both of which have the problem that they can be changed without changing the data and they can be lost in transmission.
I think the main argument against "file" for everything is the speed issue. We need a system where getting the first 1K or so of a file is as fast as reading it's name.
you would see "file" improved to the point that it identified everything 99% accurately
If you know how to do this, why don't you do it? I'm sure everyone would love a 99% accurate file.
In any case, 99% isn't good enough. 99% means everytime I try and look at every file in a 100 file directory, one will be wrong. By the nature of your solution, that one will be almost completely unfixably wrong. Running across bugs of your system every day is not acceptable.
if you include accurately identifying a file without magic numbers as "I don't know what this is" rather than some random type
Why is "I don't know" better than "UTF-8 text with CRLF line endings"? And how exactly do you distinguish between a typed file and a file that just happens to start with those magic numbers?
you would quickly see magic numbers stuck on everything,
In other words, you think you can do this, and the world will beat a path to your door to serve you. Not likely.
raw UTF-8 would have a UTF-8 encoded non-marking-space
The UTF-8 BOM causes all sorts of problems with the standard Unix text tools. What tools take one off and put one on is an ugly complex question that requires changing about every program that might output text.
We need a system where getting the first 1K or so of a file is as fast as reading it's name.
I.e. we need a system where it takes as much time to read the directory listing as it does to read the directory listing and open the file. Sounds like efficency to me.
The frames of a MNG datastream can be in the JPEG (JNG) subformat as well as in the PNG format. Read the JNG spec at the PNG web site, http://www.libpng.org/pub/mng/
"UTF-8 text with CRLF" is what I meant by an "I don't know" answer. The way you distinguish a typed file that just happens to start with the magic bytes is you look at more bytes until you are reasonably certain this really is the file type you want.
The UTF-8 BOM causes all sorts of problems with the standard Unix text tools. What tools take one off and put one on is an ugly complex question that requires changing about every program that might output text.
Raw text tools would be edit the text to put the BOM mark there (or remove it, or change it to something else to outwit the file system). My proposal is that the standard read/write of files is unchanged. It is the program's responsibility to read/write the identifier. For the vast majority of Unix text files you would put a comment line at the start with the id. Take a look at how Emacs can have an id at the start of the file for ideas. The BOM is not needed for data files that belong to a particular program, in fact the BOM can be used to identify raw text.
We need a system where getting the first 1K or so of a file is as fast as reading it's name.
I.e. we need a system where it takes as much time to read the directory listing as it does to read the directory listing and open the file. Sounds like efficency to me.
The idea is that getting at least the first block of bytes of a file mapped into memory is much faster than opening the file. On Unix I propose that a block of data of a guaranteed minimum size be stored in the Inode and that getting it would be as fast as getting the permission of a file today. You may have to use a different call than open. Reading the names of files would be just as fast as it is on Unix today, but running file would be similar to getting the executable or directory bits for each file.
A lot of newer filesystems do pack small files into the inode (reiserfs, BFS, and xfs too, I think)... This is not too much of a leap from storing the first few bytes of a large file there too. (I would modify your statement about "mapping" the beginning of the file though - a simple read() will be much much faster when you consider the page table manipulation overhead of mmap()).
Have you looked at reiserfs? Hans Reiser shares this philosophy - although he is aiming more toward supporting things like hierarchical configuration documents being expressed as dense directory trees with tiny files, each holding only a few bytes (as opposed to a single text file with internal hierarchical structure, eg XML). I remember Reiser saying something like "who needs extended file attributes when you have very fast directories?" (*)
* incidentally, consider that Microsoft invented the Registry (which is essentially an in-memory filesystem) because storing all that data in a directory tree was too slow with NTFS...
Of course MicroSoft did something stupid. The registry is exactly the type of thing that Reiser (and I) am trying to get away from. Yet another file format and library to read it, so that all the tools you have to read an existing one cannot be used on it. In many ways the mess of /etc is perferrable since it allows *some* file manipulation tools to work, you can create or delete a whole catagory of information using normal tools, though trying to change individual records requires specialized programs (ie a text editor).
They should have either fixed their filesystem to support many small files. At least used a XFS type interface so the same calls could be used to manipulate the registry as any other files, this I hope will be what Linux does if they are forced to do it by the need for compatability or because nobody fixes the file system to be faster.
Have done for at least 3 times as long under Unix and other systems (UCSD etc), but DOS/Windows set the pace with filetypes, and apparently still does. Sigh.
Got time? Spend some of it coding or testing