Talk:Lossless JPEG

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

Patents?[edit]

Is JPEG-LS subject to patents in any developed country that require payment by implementors? --Damian Yerrick () 14:07, 16 July 2006 (UTC)[reply]

I'm fairly sure that JPEG-LS is subject to patents, but that its license requires no payments for use (see HP's license for JPEG-LS, which I haven't read all of, to be sure). Calbaer 21:55, 17 July 2006 (UTC)[reply]

title[edit]

since this covers all 3 lossless JPEG formats shouldn't it be titled appropriately, i propose "lossless variants of JPEG" Plugwash 17:08, 31 July 2006 (UTC)[reply]

Compression Ratios[edit]

JPEG-LS does not get higher compression ratios than JPEG2000 with any of the public domain software. For a test, I compared JPEG2000 (Meesoft Image Analyzer) to JPEG-LS (University of British Columbia's implementation) on Kodak test images. (http://r0k.us/graphics/kodak/) JPEG2000 got more than a 2:1 compression ratio on all of them, and they correctly decompress losslessly. JPEG-LS did much worse; some of them were larger than the original PNG files.

If JPEG-LS is able to get higher compression ratios than lossless JPEG2000, why does every JPEG-LS implementation I try do a little better than PNG, but much WORSE than lossless JPEG2000? Korejwa 19:38, 15 August 2006 (UTC)[reply]

There are many potential explanations for this, including a suboptimal encoder, accidental use of lossy mode, accidental use of distorted images, scale of the images lending themselves less to lossless coding, or the fact that only natural images were used (where the two JPEG methods are reported to be competitive) rather than artificial or compound images (where JPEG-LS wins hands-down). A more comprehensive citation is needed for this, but JPEG's own comparison of 2000 with the older LS (UBC implementation) on seven images from the JPEG 2000 test set showed LS winning most of the time, so that's what I went by. Unfortunately, the test set is not freely available due to copyright issues. The sentences could be changed to:
  • JPEG 2000 includes a lossless mode based on a special integer wavelet filter (biorthogonal 3/5). JPEG 2000's lossless mode runs more slowly and often has worse compression ratios than JPEG-LS, especially on artificial and compound images[1]. However, it is scalable and progressive, and, because its algorithm is more similar to JPEG 2000, it is more widely supported[citation needed].

In summary, though, I don't know what accounts for the difference. Hopefully you can hazard a guess. Calbaer 21:20, 15 August 2006 (UTC)[reply]

Let's be bold and change it Joachim.Kluge 07:48, 7 February 2007 (UTC)[reply]

In my experience, JPEG-LS is better than JPEG 2000 lossless mode for grayscale images, but it isn’t the case for color images. JPEG-LS usually compress color components independently, while JPEG 2000 can employ reversible color transform (RCT) to remove inter-color correlations. JPEG-LS part 2 specifies a new color transform technique but it has not been popular. 124.87.182.116 19:33, 10 August 2007 (UTC)[reply]

BTW: jpeg lossless mode (not jpeg LS) seems to often compress worse than png. For fotos the compression rate is similar to png, often a little above 50%), but for line-drawings, it falls much behind (probably because it needs to store at least one bit per pixel and color). --77.3.85.66 (talk) 17:21, 26 January 2016 (UTC)[reply]

The JPEG lossless compression article doesn't contain anything interesting, there was a "Merge" proposal, but its discussion page was deleted. Shouldn't it be simply redirected to the Lossless JPEG page? cojoco (talk) 00:25, 11 December 2008 (UTC)[reply]

I agree. Having many pages talking about essentially the same thing is really confusing to someone unfamiliar with the subject.202.21.130.193 (talk) 21:04, 15 January 2009 (UTC)[reply]

And you've done it! Excellent, thanks. cojoco (talk) 11:08, 18 January 2009 (UTC)[reply]
Or rather, excellent thanks to Plugwash! cojoco (talk) 11:11, 18 January 2009 (UTC)[reply]

Category[edit]

This article is listed in Category:Lossy_compression_algorithms, which I find quite paradoxal given its title, but I am not sure I should just remove it. Ffx (talk) 13:44, 22 January 2009 (UTC)[reply]

Comparison with PNG?[edit]

I think a section to this effect would be in order. Does anybody here have the expertise to write it? -- Smjg (talk) 19:39, 5 July 2009 (UTC)[reply]

In general, PNG is highly optimized for "cartoony" or "diagram"-type images, with fairly large areas of flat color, while most photographically-oriented compression processes are designed to accomodate a little "noise", or random variation inherent in digitizing information captured from external sources... AnonMoos (talk) 02:06, 7 July 2009 (UTC)[reply]
Maybe, but your statement is in no way specific to lossless JPEG. Most other photographically-oriented compression processes I know of are lossy, so this would need special treatment. -- Smjg (talk) 13:10, 12 September 2009 (UTC)[reply]
The probable result of a PNG / Lossless JPEG comparison test would be that PNG would beat the pants off of Lossless JPEG for certain restricted types of images which PNG handles very well, while Lossless JPG would have a consistent (though not necessarily large) advantage over PNG for other types of images... AnonMoos (talk) 15:56, 12 September 2009 (UTC)[reply]

about: "since the Inverse DCT is not rigorously defined"[edit]

I cannot find anything about this in the DCT article. Maybe we should name the real problems: Reduced color resolution and quantization. It would, for example, be possible to use the lossy jpeg, and use an entropy coder to save the residual errors. Speed/compression may not be that good. --Arnero (talk) 15:51, 8 May 2010 (UTC)[reply]

More on "the Inverse DCT is not rigorously defined" The inverse DCT in JPEG standard is rigorously defined. The problem is in a concrete DCT implementation. Indeed, DCT is specified with functions 'cos' which produces irrational (even transcedental) outputs. Therefore any finite-precision implementation is actually an approximation of the DCT. This causes a mismatch between between original and reconstructed sources even if quantization scaler is 1. —Preceding unsigned comment added by 199.203.96.62 (talk) 12:53, 31 October 2010 (UTC)[reply]

Section "LOCO-I" is copy-vio?[edit]

  • Where is the "Fig. 3" that is mentioned in the text?
  • What is C?

--RokerHRO (talk) 12:05, 13 April 2011 (UTC)[reply]

You just need to scroll up. It's referring to the figures that were previously used to discuss plain lossless JPEG. — trlkly 07:45, 23 October 2011 (UTC)[reply]

ll-mode[edit]

The article says about LL mode of standard JPEG:

This mode is quite popular in the medical imaging field, and defined as an option in DNG standard, but otherwise it is not very widely used because of complexity of doing arithmetics on 10, 12 or 14bpp values on typical embedded 32bit processor and a little resulting gain in space.

But this LL-mode of standard JPEG is used by cameras (Canon CR2, Adobe DNG,...) to encode RAW image data. Probably because these arithmetics are the easiest way on embedded hardware.

--77.8.118.19 (talk) 03:55, 19 January 2016 (UTC)[reply]

What is the LS in JPEG-LS?[edit]

What does the "LS" in JPEG-LS stand for? I would think "lossless" would be JPEG-LL. Other readers might also like to know... — Preceding unsigned comment added by 118.0.51.1 (talk) 12:48, 29 November 2017 (UTC) "Low-complexity Standard"?[reply]

Interesting question. Skimming the standards document, I don't see anything that jumps out, except that there's a least squares component to it. It could just be that "LS," spoken aloud, sounds a lot like "lossless," and that the standards committee never explicitly gave a reason. It could be like Windows XP, where there were general ideas, but what was settled on was just something that "sounded right" for the application. We have a similar ambiguity with JPEG XL. Adding such conjectures to the article would, unfortunately, contradict Wikipedia policy, so - unless someone finds a better explanation - this is all we'll get. Calbaer (talk)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 4 external links on Lossless JPEG. 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: 18 January 2022).

  • 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:45, 6 January 2018 (UTC)[reply]

JPEG-LS in Medical Uses[edit]

With regard to this statement: "This mode is quite popular in the medical imaging field, and defined as an option in DNG standard, but otherwise it is not very widely used because of complexity of doing arithmetics on 10, 12 or 14bpp values on typical embedded 32-bit processor and a little resulting gain in space." Actually, the lack of support is primarily because the compression in lossless mode is comparable to other lossless JPEG modes which have already been widely studied; further, the compression gains of near-lossless mode are explicitly prohibited by the FDA -- irreversible compression is not permitted. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3259360/