Jump to content

Talk:JPEG 2000

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Comparison to JPEG-LS

[edit]

Seems like there should be a section on this (not just split between Advantages and Disadvantage. It is part of the historical development of JPEG of which J2K is a later format. It should talk about WHY it was proposed after it had developed JPEG-LS, in other words the comparison to original JPEG is somewhat false. Maybe the article also needs a history section (although maybe this should be first added in the article on the Joint Photographic Experts Group). —Preceding unsigned comment added by 70.22.160.136 (talk) 16:30, 10 January 2010 (UTC)[reply]

Availability

[edit]

The article states in the references that the final standard is not available freely. I think this might be wrong. As the JPEG consortium is a group of ISO and ITU-T all standards get published on the ITU-T pages as "Technical Recommendations". See T.800 to T.812 for the JPEG 2000 standards. —Preceding unsigned comment added by 213.196.221.2 (talk) 13:39, 20 July 2008 (UTC)[reply]

Edit

[edit]

The article mentions that 'editability' is a feature of JPEG 2000, but does not explain. If I knew anything about this, I'd fix it.

This is likely referring to the fact that JPEG is lossy compression only, so every time you edit it it loses fidelity (loses information every time you safe). Eventually the image is degraded terribly. JPEG2000 has lossless compression as an option. This means you could make changes to the file, and save it without losing fidelity over time. For this reason lossless image formats are better than lossy ones. However, they take up more space (all that information that you'd otherwise get to throw away in a lossy format). So there is a pro and a con to lossless formats. JPEG on its own is best used as a one shot conversion from a lossless format in a read-only sense, like for distributing on the web where you don't care about editablity but do care about small images. JPEG2000 however is capable of making even smaller images with the same apparent visual quality as JPEG. So JPEG2000 beats JPEG in this area as well. Where JPEG is better is that more devices support it, and it takes less computing resources to decompress. I'd edit the article myself but I hate wikipedia. — Preceding unsigned comment added by 24.57.154.225 (talk) 05:12, 5 August 2016 (UTC)[reply]

Disadvantages?

[edit]

Right now the article looks like it was written by some JPEG 2000 promotion group, with the first section being "Superiority of JPEG2000". I chuckled when I saw that. I think this should be renamed "Advantages" and another section with "Disadvantages" created right below. Disadvantages possibly being slower compression/decompression (not so good for digital cameras with limited processing power), patent issus (mentioned at the end of the article), lack of support and very slow adaptation, and that images that are "good enough quality" with no visible artifacts are pretty much same size with JPEG and JPEG2000. At least in my tests JPEG2000 seems to win only with quality that clearly shows some noticeable artifacts; It's just that JPEG then shows more. So it's questionable if the format is all that useful, as images with no visual artifacts are usually desirable (and not that big either). Magnus below at Test-Image-section also said something that confirms my observations: "But I think that JPEG2000 isn't better than JPEG at higger queality, it smooths more de image and deletes some detail that JPEG show it." At some compression ratio for some images, JPEG2000 may indeed look worse for the same file size. Negleting to mention this in the article is just hiding the facts. Also in my experience, lossless JPEG2000 is worse than PNG (compressed with pngcrush) even for photos, not just diagrams as the article suggests.

But I didn't edit the article because my info may be wrong or old. Someone better informed should do it if she seems it as appropriate.

There sure should be a section on disadvantages. I tried out JPEG 2000 a bit. And well, the disadvantages outweigh the advantages. First of all, although it eliminates the "jpeg artifacts", it smooths the image too much. A #8 compression on jpeg 2000 is a much larger files size than a #8 regular jpeg, and if compensated to match file size, the regular jpeg preserves more detail. And anyway, hardly any applications support jpeg 2000, so what's the use? Althepal 03:27, 8 January 2007 (UTC)[reply]

I wonder if it would be okay to insert into the article criticism that isn't backed by any notable publication. I too find J2K disappointing. The only thing it might do better than JPEG is extreme compression (say 1/50), and that's not what most people are after. The only general use for it I can think of is lossless photos compression that compresses better than PNG and is somewhat compatible. But that isn't too promising considering JPEG-LS almost always compresses better and always requires much less horsepower. Maybe the situation could be better with better encoders (and maybe they have improved sincen I last tested)?

So what do you reckon, should this be added in? ehudshapira 06:26, 17 June 2007 (UTC)[reply]

In that context, I also wonder about the third paragraph, "As of 2017, there are very few digital cameras that encode photos in the JPEG 2000 format". Why would a camera want to use a JPEG format? They have enough storage space. You'd want to use a lossless format for cameras. Maybe even RAW, but certainly not JPEG-like.

User ehudshapira wrote: The only thing it might do better than JPEG is extreme compression (say 1/50).

My reply: If you simply feed an image into JPEG 1991 and JPEG 2000 and do extreme compression on it, JPEG 2000 will definitely come out looking better. However, for extreme compression JPEG 1991 is just about as good as JPEG 2000 if you do things as follows in the 1991 compressor. First the compressor reduces the image size -- by a factor of two for each of horizontal and vertical, for instance. Then the smaller image is compressed in the ordinary JPEG 1991 way. Later, the decompressor decompresses it in the ordinary way, and then the image is zoomed back up by the factor of whatever it was reduced by. The consequence of reducing and re-expanding it is an image that suffers from some blurring artefacts. The re-expansion is done by interpolation. Blurring is not as objectionable to the human eye as the texas chain-saw massacre of blocking and ringing that happens in JPEG 1991 when you do extreme compression on it. What JPEG 2000 produces under extreme compression is a blurry image and it does so by reducing the image's resolution, which is the same thing as reducing the size. The 1991 standard doesn't include the feature of reducing and re-expanding for extreme compression. User sean 89.234.85.117 20:36, 5 July 2007 (UTC)[reply]

Test-Image

[edit]

Perhaps, somebody can work it into the article.80.185.8.102 20:58, 1 January 2006 (UTC)[reply]

It's an interesting test image; it has been saved at 20% quality (6.9kb), and the JPEG2000 image has been saved with the same file size.
But I think JPEG2000 isn't better than JPEG at higher quality. It smooths more of the image and deletes some detail that JPEG would show.
I have found another comparison with some levels of compression with the Lura Wave plugin for Irfanview :[1] and these are the results:
Images in EMBED tag (browsers with a JPEG2000 plugin)
Images in IMG tag (browsers with naive JPEG2000 support, as Konqueror)
The frist table are images without colour subsamplig (4:4:4), and the second with a 4:2:2 subsamplig.
Sorry if my English is very poor.
--Magnus Colossus 16:08, 16 February 2006 (UTC)[reply]
i demand lena. 60.48.74.92 00:40, 27 July 2006 (UTC)[reply]

JPEG/JPEG 2000 comparision with JPEG images?

[edit]

I don't understand why the test images provided here try to show the differences between JPEG and JPEG 2000 by showing them next to each other on a JPEG image. This is like comparing CD quality sound and HD quality sound by copying both of them on a Audio CD... --Abdull 21:01, 12 June 2006 (UTC)[reply]

I just came here to say the same thing. They took a JPEG 2000, turned up the loss, and then to show it to people on Wikipedia, they re-compressed it as a JPEG? If the final JPEG as saved at really high quality settings, then it's not as bad as the recording example given above, but it is still NOT VALID. It can NOT be a fair comparsson of the artifacts of JPEG-2000 vs JPEG when they're both a JPEG! It needs to be something lossless. I assume PNG is the most widely supported by web browsers?

Fixed. I hope you like the new image. --Shlomi Tal ☜ 18:45, 24 June 2006 (UTC)[reply]

Is it possible, that the images of the JPEG/JPEG 2000 comparison have been mixed up? It's obvious, that the doggie's picture called "JPEG" looks way sharper and shows much more detail than the JPEG 2000 picture. I don't really know JPEG 2000 from own experiences, but wasn't it intended to be superior compared to JPEG? Regards, Elmario —Preceding unsigned comment added by 92.228.10.74 (talk) 04:41, 9 August 2009 (UTC)[reply]

They haven't been mixed up: if you zoom into the JPEG one, you will see JPEG artifacts (8x8 blocks), but if you zoom into the JPEG 2000 one, you will see that it looks completely different. It's not surprising that the JPEG one looks sharper, since bluriness is a JPEG 2000 artifact. --Zundark (talk) 08:52, 9 August 2009 (UTC)[reply]

Section on Techical Discussion

[edit]

I've read the techinal description section, and I think it can be re-written a fair bit. In particular, the description can be organized much better, and the rich feature set offered by J2K can be made more explicit (eg: the progressive nature of the code-stream, compressed domain manipulations, and so on).

I'll probably be able to do this in a little while - but since I'm new to editing Wiki, I thought I'd make a post first and get people's opinions on this before I did anything substantial.

--Brokentooth 22:21, 20 July 2006 (UTC)[reply]


I don't know how to use WIKI, but its stated that wavelet compression is more computationally intensive than regular jpeg. This is simply not true, wavelets are FAST/simple TRANSFORMATIONS!! compared to DCT based transforms. 

Jpeg2000's ability to store lossless images is an important difference, as well as its support for higher colour bitdepth.

Also its a ability to perform partial/resolution decompression is important. The FBI use a wavelet image format just for this reason, so that finger print databases can be analysed quickly. Ronx  —Preceding unsigned comment added by 81.156.139.110 (talk) 04:58, 23 May 2009 (UTC)[reply]


Section on Coding in Technical Discussion

[edit]

The section about layers and packets is confused. Layers are not groups of packets, packets are groups of layers. See "JPEG 2000 Part I Final Committee Draft Version 1.0" (ISO/IEC JTC 1/SC 29/WG 1 N1646R) Page 61, Annex B.8 Packets.

-- Emily

Free software

[edit]
Regardless, however, of the monetary cost of licensing JPEG2000 patents, it would still be impossible to comply with the Debian Free Software Guidelines (the acid test of software freedom) with freely-licensed patents unless the licenses were redistributable and irrevocable, even if the licensed application is modified. This alone could hamper adoption of JPEG 2000 for web purposes as it would exclude open-source web browsers (most notably Gecko-based browsers) and popular LAMP web applications.
I know very little about free software licensing in general, but surely it could be implemented in a library with free software compatible license (even tho the license itself obviously wouldn't be a free software license) and therefore included as a non free software portion of a free software application. Non free software proponents may not want to do this, but it sounds to me like this is suggesting it's not possible to have JPEG2000 support in freesoftware which I'm pretty sure isn't true. Besides that can't you write the source code even if you can't distribute the binaries? Isn't this how XviD works? Also, VLC seems to have survived despite including support for the patented XviD...? Not to mention GIF was supported while it was patented. I understand why free software proponents dislike (or hate) patents, but I feel the current wording is misleading as it appears to suggest patents must be a deathnell Nil Einne 15:12, 11 January 2007 (UTC)[reply]

Yes, Debian can put software in the non-free section when it doesn't meet the DFSG, and has before.


[edit]

I wanted to bring this up because doing a patent search on "wavelet transform" and "wavelet image" seems to bring up many patents, possibly around 500 or so. So the statement about the heavily patented area seems to be true on it's face although there's not a study or a white paper to point to. Just a patent search will bring the facts to light.

Emmanuel Devys (talk) 15:50, 23 October 2019 (UTC)Note: JPEG 2000 makes use of Discrete Wavelet Transform. It appears that: - no legal issue is identified on the entry for Discrete wavelet transform (DWT) in Wikipedia. If there are any legal issue, they should be identified under the Discrete Wavelet Transform entry (and possibly referenced in JPEG 2000). They should NOT appear here by some magic (because we speak of JPEG 2000 or ITU T.801 or ISO/IEC 15444-1) see https://wiki.riteme.site/wiki/Discrete_wavelet_transform - a search on Discrete Wavelet Transform on European Patent register (between 1998 and 2001) see https://register.epo.org/smartSearch?lng=en provides only one patent: EP0855838 - A method for digital image compression using Discrete Wavelet Transform DWT, submitted by Andrew, James Philip for CANON KABUSHIKI KAISHA on 21.01.1998. It seems to be a General compression method which preferably employs a discrete wavelet transform (but not a patent on DWT) - a search on Discrete Wavelet Transform on http://patft.uspto.gov/ (between 1998 and 2001) provides 78 patents, most of them using DWT (instead of claiming any paternity), some of them adressing audio, video, and several apparatus for diverse usages of DWT. => This is far from the "many patents, possibly around 500 or so" that may be identified today on this well-known mathematical transform (and technology), which is in computer science / information processing textbooks.Emmanuel Devys (talk) 15:50, 23 October 2019 (UTC)[reply]

this phrase: "JPEG 2000 is not widely supported in present software due to the perceived danger of software patents on the mathematics of the compression method, this area of mathematics being heavily patented in general[citation needed]."

is invalid. Do it based on any research?

"perceived danger of software patents " can't be the reason of not widely support. The work processed to clean up JPEG2000 standart from submarine patents is a lot bigger than for example JPEG or GIF. But JPEG and GIF is more sphread now. So this assumption on reason of "not widely supported " must be removed ASAP, it is just lie.

You can argue about whether there's a "danger of patents" or not, but there is obviously a *perceived* danger. I came here looking for the reasons why W3C rejected jpeg2000. IIRC it was due to perceived patent danger. Anyone got info on this? Gronky (talk) 16:15, 18 February 2009 (UTC)[reply]

Please point me to the fact that "W3C rejected jpeg2000" —Preceding unsigned comment added by 78.24.75.214 (talk) 16:20, 5 March 2009 (UTC)[reply]

is there any fact for this "Because of this statement, controversy remains in the software community concerning the legal status of the JPEG2000 standard." ? Looks like it is somebody's opinion. —Preceding unsigned comment added by 78.24.75.214 (talk) 16:23, 5 March 2009 (UTC)[reply]

Emmanuel Devys (talk) 15:50, 23 October 2019 (UTC)Additional Note: The risk of patent claim on JPEG 2000, more than 15 years after its publication, should be related to facts, as follows:[reply]

- registered patent claims by ISO on 15444-1, from ISO patent database (extract for ISO 15444-1) at https://www.iso.org/iso-standards-and-patents.html Among the patent holders candidate, it seems that only the following were granted patents: Patent holder/Company Patent number Licensing declaration Telcordia Technologies Inc. 4,829,378 unknown IBM - N.Y. 4905297 4633490 4935882 4467317 4295125 4286256 4463342 4463342 5099440 4652856 4891643 Option 1: RAND & Free of charge Mitsubishi Electric Corporation 2128115 2128110 unknown

These patents may be searched on the US patent database cf. US patent : http://patft.uspto.gov/netahtml/PTO/srchnum.htm - IBM does not seem to be an issue (choice of Option 1). - The Telcordia Technologies Inc. / Bell Labs. and now Iconectiv does not seem to be an issue to the JPEG 2000 compression / decompression. (the patent claim may be checked at http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=4829378.PN.&OS=PN/4829378&RS=PN/4829378). - The Mitsubishi Electric Corporation patents are registered in Japan. 2 Japan patents 2128110 and 2128115 that have been expired since 20090131, 20100226 respectively (source Mitsubishi Electric Corporation, Corporate Licensing Division)

- search on "JPEG 2000" on European Patent register (between 1998 and 2001) see https://register.epo.org/smartSearch?lng=en For a search between "jpeg 2000" pd="1998:2001", no patent is registered For a search between 1998 – 2006, 2 patents registered, submitted in Nov. 2004 (therfore posterior to the publication of ISO 15444-1)

- search on "JPEG 2000" on US Patent http://patft.uspto.gov/netahtml/PTO/search-adv.htm, Request : AN/Ricoh AND ISD/1/1/1978->31/12/2002 AND SPEC/"JPEG 2000" 1 result Ricoh Patent 6,492,916 Schwartz , et al. December 10, 2002 Inventors: Schwartz; Edward L. (Sunnyvale, CA), Gormish; Michael J. (Redwood City, CA) The object of this patent claim seems to be based on JPEG 2000 and its implementation. However, it is posterior to first version of JPEG 2000 / T.801 (March 2000).

- JPEG 2000 is handled / used by Safari on the internet, and it does not seem that Apple faced any legal issue about this.

- JPEG 2000 is widely used for Medical imagery (DICOM see https://wiki.riteme.site/wiki/DICOM), most national Libraries and organization having to archive patrimonial digital documents, since 15 years, without sign of evidence of any legal issue.Emmanuel Devys (talk) 15:50, 23 October 2019 (UTC)[reply]

One of the list of patents from IBM - N.Y., 4463342, has been mentioned twice, but the patent database excel spreadsheet from ISO also lists it twice.146.115.133.92 (talk) 01:31, 24 February 2024 (UTC)[reply]

Removal of Original Research

[edit]

Wikipedia has a prohibition on adding original research to the encyclopedia. As it's an encyclopedia, not a publishing platform for new information, a fundamental goal of Wikipedia is that all articles are supported by reliable, external citations. This prohibition includes using sources (such as patent databases) to synthesise a conclusion not contained directly in the sources. As such I've removed the original research on patent databases that was added to the Legal Status section in revision 922669987.

If you would like this kind of information to appear in the JPEG 2000 article of the encyclopedia, you can find independent research from a reliable source to summarise and cite. For more information on the policy and its definitions, see Wikipedia:No Original Research. — Saxifrage ✎ 00:01, 15 August 2023 (UTC)[reply]

"JPEG 2000 is included in most Linux distributions."

[edit]

What is this supposed to mean? AnonMoos 03:03, 5 October 2007 (UTC)[reply]

I think it means that most Linux distributions SUPPORT it as a standard. Inclusivedisjunction (talk) 07:01, 19 January 2008 (UTC)[reply]

Well, what does that mean, then? Debian Linux has the libopenjpeg2 package, but only eight other packages use it, only two of them are actual applications, and only one of the two (krita) deals with normal bitmapped images. In other words, AFAICT virtually no applications can show or save JPEG 2000 images. /JöG (talk) 21:08, 28 November 2012 (UTC)[reply]

Just a clarification: ImageMagick and GraphicsMagick are able to display and save JPEG 2000 files. Ubuntu can show JPEG 2000 in the thumbnails and is able to open them. --Cantalamessa (talk) 14:32, 29 November 2012 (UTC)[reply]

machine judgment of quality

[edit]
Images machine-judged to be of equivalent quality for both compression schemes often look better to humans in JPEG 2000 at low bitrates.

I am removing the above because all it means is "A certain machine test of image quality doesn't work". If humans judge that one image is better quality than another, then a working metric will give them different scores. The whole purpose of such a metric is to predict human judgment of quality. TomViza 19:48, 4 November 2007 (UTC)[reply]

Article cleanup

[edit]

The tone, partiality, article structure, and difficult readability all need to be addressed. The article is not only extremely technical it is addressing the perceived advantages of JPEG2000. Non-technical users will not understand this article even at the introduction. It needs the more technical bits moved to another section and a gentle introduction, history, and body copy must be written. --KJRehberg (talk) 05:07, 17 January 2008 (UTC)[reply]

What is the perf difference?

[edit]

The article makes it sound like the encoding and decoding performance is significant, but I see no hard numbers. I looked for them on the web, and couldn't find any either. If someone has some speed and/or memory numbers, it would be nice to add, because this article has the important numbers in many other places. KeithCu (talk) 10:17, 15 March 2008 (UTC)[reply]

Thumbnails?

[edit]

It seems a bit silly to me to feature thumbnails of comparisons, since at low resolution all three versions are indistinguishable. Of course they can click on the images for a larger image, but it's preferable to be able to see the artifacts alongside the explanatory text. I'd suggest creating an actual thumbnail-sized demonstration image, and making the image somewhat bigger (e.g. 300px wide). Dcoetzee 06:15, 6 August 2008 (UTC)[reply]

Comparison w/ Mr. Sid?

[edit]

As I understand it, Mr. Sid (.SID from Lizard Tech) is still the industry standard for compressing geospatial imagery but I see no mention of this format. JPeg 2000 is the new kid on the block. —Preceding unsigned comment added by 66.100.151.133 (talk) 21:37, 10 October 2008 (UTC)[reply]

Basic (Part1) and Advanced (Part2)

[edit]

Applications are compared regarding their support for Part1 and Part2. Perhaps the table JPEG 2000 image coding system - Parts could be more verbose on what the Parts are about? "Extensions, (.jpx, .jpf)" is not sufficient IMHO.--78.49.169.37 (talk) 18:07, 11 March 2010 (UTC)[reply]

Acrobat support

[edit]

Having searched on the web for converters from JP2 to JPG (or anything else) and found many that are quite pricey, I've since found that Acrobat version 8 can read jp2, and this is worth noting in the table. MS Office 2007 doesn't appear to support jp2 import. 92.9.57.63 (talk) 11:00, 21 April 2010 (UTC)barry.sandell@gmail.com[reply]

Illegal abbreviations

[edit]

The submitted picture labels file size in "KiB". Abbreviation standards are quite clear (see http://wiki.riteme.site/wiki/SI for example). The only acceptable abbreviation for kilobytes is kB. Postlewaight (talk) 18:20, 6 October 2010 (UTC)[reply]

See binary prefix. --DaBler (talk) 19:29, 6 October 2010 (UTC)[reply]

Colour Transforms

[edit]

In this section is the wording:

"This step is called multiple component transformation in the JPEG 2000 language since its usage is not restricted to the RGB color model."

Typically chrominance subsampling is applied in YCbCr images because the Cb and Cr (i.e. Chrominance) are separate. I think the correct wording should be "... since its usage is not restricted to the YCbCr color model". Although it is in the standard, I don't really see how you would get benefit from applying it to RGB space. If someone more familiar with JPEG 2000 could explain, it would improve the article. — Preceding unsigned comment added by 86.25.246.8 (talk) 15:00, 2 January 2012 (UTC)[reply]

Tiling

[edit]

In the Tiling section it says:

"The disadvantage of this approach is that the quality of the picture decreases due to a lower peak signal-to-noise ratio."

PSNR is a measurement of the quality therefore this statement is saying "It's bad because the results are not good". I would expect tiling to be a trade off between 1. dividing the image into more manageable chunks and 2. introducing more chunks adds overhead in the case of a fixed bit rate budget. — Preceding unsigned comment added by 86.25.246.8 (talk) 15:04, 2 January 2012 (UTC)[reply]


Sample image?

[edit]

Shouldn't wikipedia actually provide a .jp2 image for people to view (even if most browsers would still show the "broken image" symbol)? There doesn't actually seem to be a Jpeg-2000 format file anywhere in the article or the links! — Preceding unsigned comment added by 87.194.171.29 (talk) 00:13, 28 April 2012 (UTC)[reply]

It couldn't be hosted at the moment, it is an unsupported file type. A repository of weird media formats for quick tests would be nice. Check out Mplayer, I vaguely recall that they have lots of test files. –89.204.138.28 (talk) 22:31, 21 January 2014 (UTC)[reply]

best of jpeg for photo graph

[edit]

I have a PSD file that is full quality but when I try to save it as a JPG file, the quality is a little bit less. What I want to ask you is..... how do I to save the image in JPG or JPEG or jpeg2000 format preserving the quality of the image? what format is best of foto print quality ? 

pls help me  — Preceding unsigned comment added by 117.204.244.154 (talk) 16:11, 9 April 2013 (UTC)[reply]
".jpg" and ".jpeg" are just filename extensions, they both are used for JPEG, which is always lossy. JPEG 2000 is not JPEG; JPEG 2000 can be lossy or lossless. If you want to preserve the quality completely, you need a lossless format. A free lossless compression format viewable in web browsers is PNG. If you want to save image in an open format, but preserve data like layers (though not viewable in a web browser), try OpenRaster. --AVRS (talk) 16:55, 9 April 2013 (UTC)[reply]
This isn't really the place for this kind of question, but Photoshop has been able to save lossless JPEG2000 for years now. If you're just doing adjustments, you should be doing non-destructive editing on camera raw files whenever possible and saving to the "most lossless" format when raw isn't possible. That generally means 16 bit TIFF (compressed or no) but for stacked HDR it might not hurt to save the 32 bit EXR file the merge produces without doing any tone-mapping to it in case you want to make a variant later without merging raws again.
Then again, if you save as quality 100 JPEG it would take thousands of saves before you can tell the difference. If you're shooting JPEG in-camera you're already screwed as far as having quality preserved because you've lost a bunch of color information.
Photoshop, which he asked about, can't save as "OpenRaster", which apparently GIMP doesn't even support fully which isn't a good sign. --A Shortfall Of Gravitas (talk) 19:18, 28 September 2021 (UTC)[reply]

Jargon

[edit]

This article uses jargon for which there is no Wikipedia entry, like "codestream" for example. A search for "codestream" on the wikipedia landed me back on this article. This is not what Wikipedia articles are supposed to be like, in my opinion. Feraudyh (talk) 17:04, 7 November 2013 (UTC)[reply]

I moved the explanation to the lead section (second paragraph.) Apparently contributors here don't agree on a spelling (codestream vs. code stream vs. code-stream). I added Video compression picture types to See also, found in a search for "code stream". –89.204.138.28 (talk) 22:22, 21 January 2014 (UTC)[reply]
The proper word is "bitstream". Kegon (talk) 13:26, 8 August 2014 (UTC)[reply]

It also used bitrate and bit rate inconsistently

Windows & Microsoft Products

[edit]

It would be a huge boon for many users of Wikipedia if the article contained a simple statement to explain that all versions of Windows and Microsoft products (e.g. Office) do not appear to have any native support for JP2, and that the only way of viewing or using JP2 files is to download one of the software packages listed, so they can then view or save the file in another format as required. Stub Mandrel (talk) 20:16, 8 August 2015 (UTC)[reply]

Or just trash Windows and use GNU/Linux, which is the general solution for any such issue. ;) Nemo 11:40, 2 February 2016 (UTC)[reply]

Options for lossy compression in various implementations

[edit]

http://www.digitizationguidelines.gov/still-image/documents/JP2LossyCompression.pdf is very interesting, we should probably copy their page 12 table into the article. Nemo 11:39, 2 February 2016 (UTC) There is an inconsistency with the image that is used to illustrate the wavelet. It is described as a lossless wavelet, so I assume that would be LGT 5/3 - but it is references as "CDF 5/3" - though the CDF wavelet is actualye "CDF 9/7". I am not sure what it should be, so I did not make an edit. — Preceding unsigned comment added by 84.210.70.104 (talk) 14:29, 27 July 2020 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on JPEG 2000. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 19:12, 27 February 2016 (UTC)[reply]

PNG is better comment

[edit]

One of the sections talks about PNG being better for images with a lot of pixels of the same color as a throwaway slap in the face with no references. PNG by default can compress to many different sizes. You need to run a special optimization tool in order to find "a best" (not the best) condition under which you can compress the PNG to get near-optimal space. My own testing which has no place in a wikipedia page is in 400 dpi scans of A4 and larger sized photographs which are either mostly white or mostly black. In these cases the latest builds of libopenjpg and Photoshop itself show file sizes considerably smaller than PNG. 10% smaller in fact than PNG files that have been optimized by the minimum result of pngcrush and optipng. So my use case matches what is tossed out here in wikipedia perfectly but my results certainly do not. Sample output: 

7.5M    220230001.tif ; source file, ZIP compressed greyscale mostly-black TIFF file

668K    220230001.lossy.jpf ; JPEG2000 lossy compression (Adobe Photoshop defaults)
968K    220230001.c7.jpg ; JPEG lossy compression 7
968K    220230001.c9.jpg ; JPEG lossy compression 9
5.5M    220230001.j2k ; opj_compress lossless JPEG 2000 compression
5.9M    220230001.pngopt ; (minimum size file in a contest between optipng and pngcrush)
6.1M    220230001.png ; standard PNG produced by Adobe Bridge

So, PNG in this case is a good improvement over ZIP compressed TIF, and the optimizers give a slight benefit. But J2K is much better and the lossy compression results are the best of all.

This kind of throwaway statement said with great authority is a hugely bad thing when not backed up. Someone researching file formats for an application will read something like this and then dismiss JPEG2000 as being without merit as apparently it was not designed to compete with other lossless implementations (they why did they bother making a lossless implementation if they didn't want to compete, according to wikipedia?) and it as well does not perform as well as the others. So that will be the beginning and the end for our researcher who will now move on to PNG vs. TIF. And that is bad, as wikipedia will have misled him.

Own research of course has no place on wikipedia, I only use this as a basis to insert the "citation needed" flag on the statement that PNG is simply flat out better than JPEG2000 lossless. Obviously it's not true as a sweeping statement, there are perhaps some conditions where it may be true, but this is why a citation should be used and this statement needs to be backed up. It may have just been typed in by "some dude" who likes PNG. — Preceding unsigned comment added by 24.57.154.225 (talk) 05:28, 5 August 2016 (UTC)[reply]

I can confirm an increase in compression ratio in continuous tone images, such as photographs and scans. However, JPEG 2000 is still a poor choice for lossless compression, if the compression and decompression speed is also taken into account. 10% gain is not much at the cost of waiting 7 to 9 times longer to see the image. Consider that you have a directory of large scans and want to generate thumbnails for them.

The case where bandwidth is very expensive, but computation power or time unlimited, is a very special one. Usually technological advancement improves on both, and demand for resolution and quality, as well as responsivity always increases no matter how fast your hardware is.

JPEG-LS compares favorably to both PNG and JPEG 2000. A colorspace transform usually, but not always, improves compression at next to no cost, and PNG does not have this. The compression is much faster than PNG, decompression is only 2 times slower. No current tool does this, but it could even encode twice to choose the best color transform, and still be fast. 

Uncompressed            500,180,278
PNG @ level 8           246,045,253
JPEG-LS IrfanView       226,237,704
JPEG-LS PS B-=(R+G)/2   202,566,001
JPEG-2000 Lossless      205,220,247

JPEG Arithmetic Q 98    111,733,024
JPEG Huffman Q 98       125,693,254

JPEG2000 lossy Q 98      54,421,300

Decompression time: 

JPEG-2000 to PNG time ratio   7.15
Ari to Huffman time ratio     9.09
JPEG-LS to PNG time ratio     1.95

Full text of my original research. — Preceding unsigned comment added by J7n (talk • contribs) 06:25, 19 January 2018 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified one external link on JPEG 2000. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:23, 16 April 2017 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on JPEG 2000. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 18:12, 21 May 2017 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified 7 external links on JPEG 2000. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 22:20, 18 November 2017 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified one external link on JPEG 2000. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 13:14, 22 January 2018 (UTC)[reply]


Supported apllication

[edit]

Is there a need for a incomplete list of software supporting Jpeg2000?

185.101.14.10 (talk) 14:48, 7 February 2018 (UTC)[reply]

Does anyone actually use the DRM bit? (Secure image extension, part 8)

[edit]

Random hopeful question: there's a DRM extension to the JPEG 2000 standard. I know almost nothing/nobody uses jp2 - but of those who do, does anyone actually use the DRM extension in the real world, or know of such use? Googling turns up academic papers and hypotheticals.

I have heard of one real-world use case, where a porn site tried to use this to secure images. The customer had to install a browser plugin, and nothing worked very well, and it was a support nightmare, and they gave it up.

My interest is because there's JPEG Committee people still trying to shove this into ordinary JPEGs ... - David Gerard (talk) 12:05, 4 March 2018 (UTC)[reply]

the word "hardware" is COMPLETELY ABSENT

[edit]

Can anyone explain how the word hardware can be absent from this article? — Preceding unsigned comment added by 119.18.13.17 (talk) 14:31, 17 April 2018 (UTC) This format is not well supported by hardware (or software).RGB213 (talk) 07:05, 19 June 2019 (UTC)[reply]

Link farm moved from article

[edit]

These links were filling "external links". If they are references, there should be inline reference links - David Gerard (talk) 15:48, 11 June 2018 (UTC)[reply]

Relevance of this?

[edit]

In June 2013, in an interview with Bertram Lyons from the Library of Congress for The New York Times Magazine, about "Tips on Archiving Family History", codecs such as FFV1, H264 or Apple ProRes are mentioned, but JPEG 2000 is not.

And? FFV1 is video for Windows, which the majority of people (who are on Windows) had access to through Windows movie maker. It's not really an archival format, but it's accessible from the majority of computers in use. H.264 isn't really archival either but it is (and was) a universal codec that can be played on pretty much everything. It's likely that "smart" TVs will still include H.264 decoding support 20 years from now. Video cards could hardware encode it very quickly back in 2013. ProRes would be good enough for archival but is kind of questionably necessary -- cameras consumers could afford weren't generally shooting video in 10bpc 4:2:2 or in any sort of intra format, so the best archival would have been whatever came out of the camera... but at least it can be played back in realtime on a mac (as long as Apple doesn't decide that they're going to support an entirely new format and chuck that one down the drain) or in 3rd party players. From my limited knowledge of Apple's software you can encode to prores in something that comes with the OS. You won't be watching it on smart TVs, but that's a different matter.
Now we come to JPEG2000... first of all most people don't have a way of encoding it. There isn't some default software anywhere (yes linux users, we know about ffmpeg and no we don't need to know the command line you're using to install it) that will, because it's not a good codec for playback, and it produces enormous files. If he was talking to other librarians about archival format, in the sense of the word archival that means "this is going to be stored forever and accessed rarely through special machines", he probably would have mentioned it.
Here's a fun example that's a bit overkill. I just took an easy-to-encode 600MB 27s example video I shot at 4k 8bpc 4:2:0, and re-encoded it in Adobe Media Encoder as a 12bpc 4:4:4 lossless JPEG2000 in mxf. I passed the audio through as raw PCM. The original video was 179Mb/s. The JPEG2000 MXF ended up weighing in at 8.7GB with a bitrate of 2.4Gb/s. Nothing standard will play mxf files, so I tried VLC, which wouldn't even try to decode the video stream. MPC-HC did a bit better and after about 10s was able to play a bit over a second of the video before freezing up trying to decode frames and ending up picking up a few again about 15s in. I gave up on playing it after that. To play it on normal devices, I had to re-encode the JPEG2000 as HEVC. That's apparently low bitrate for a JPEG2000 because media encoder's highest constrained bitrate broadcast profile specified 51.2Gb/s as the limit. A more realistic 4:2:2 8bpc encode was over 800Mb/s and still couldn't play back in realtime.
My point of all of that is that the whole sentence is a non-sequitur... in the context of "family history" nobody wants a format that their computer can't properly deal with playing now when the 179Mb/s H.264 the camera spit out was just fine... so I'm going to go ahead and remove it; I think it's trying to prove some point that wasn't being made by the article (and the article is paywalled). --A Shortfall Of Gravitas (talk) 06:13, 22 October 2021 (UTC)[reply]

Increased size limits?

[edit]

I've recently hit the JPEG limit of approximately 65K pels in X or Y (see: [2]). Does JPEG2000 increase that limit? If so it should be mentioned as an advantage.

Mike mfc (talk) 13:51, 1 June 2023 (UTC)[reply]

Yes, the maximum width and height in JPEG 2000 is 4,294,967,295, compared to 65,535 in JPEG. I haven’t got a citable reference for this at the moment though. --Zundark (talk) 12:41, 15 July 2023 (UTC)[reply]
OK, thanks! mfc (talk) 13:13, 22 July 2023 (UTC)[reply]

Apple planning to abandon JPEG 2000 in Safari 18

[edit]

According to the French technology news website MacGeneration, Apple is officially planning to remove JPEG 2000 in Safari 18. This marks the official end of JPEG 2000 in web browsers as far as we know. Even the official WebKit blog has stated that Safari 18's beta has removed support for JPEG 2000, right when WWDC 2024 was happening.

Hopefully these sources can be helpful for updating JPEG 2000's Wikipedia entry regarding Safari 18 dropping support for the image format.

https://www.macg.co/logiciels/2024/06/safari-18-abandonne-le-jpeg-2000-144235 https://www.webkit.org/blog/15443/news-from-wwdc24-webkit-in-safari-18-beta/ DeveloperPudú (talk) 01:26, 14 June 2024 (UTC)[reply]

Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:JPEG_2000&oldid=1228943744"