Talk:Lossless compression

message: please add a history section for lossless   —Preceding unsigned comment added by Sp0 (talk • contribs) 08:56, 4 November 2007 (UTC)
thread_title:  history 

message: LZMA is an improved version of LZ77 so it should be included in this article. right?
: It is now (you didn't sign you comment so I have no clue when you wrote it).Nicolas Barbier (talk) 10:30, 29 June 2011 (UTC)
thread_title:  LZMA compression 

message: Should we include a short proof for the weaker theorem: "No lossless data compression method reduces the length of all files."?
The weaker form, which does not address the necessity of making some files longer, can be proven in the following way:
Suppose that some compression method existed that reduced the size of every input file.  Then a user could apply the method repeatedly to reduce any file to length zero.
24.17.254.19 23:43, 24 December 2006 (UTC)
replies: text: This weaker version holds even without knowing anything about what lossless compression means: No total mapping from bit (byte) sequences to bit (byte) sequences can produce an output that is shorter than its input for all inputs, simply because in the case of the zero-length input there is no possible shorter output to produce. A property that obvious would probably not do much to improve the article. It is more common for proponents of miraculous compression methods to make the more guarded claim that their method will shrink all files larger than some minimum length; and refuting that leads one to the same kind of counting argument that is already in the article. Henning Makholm 00:26, 25 December 2006 (UTC)
thread_title: Including an intuitive proof of the weaker theorem

message: LZW compression is best(obvious) choice while compressing text documents.It is more of dictionary based approach in which it adds new word found into its database and uses index for that word.Even though it will not give extremely good compression ratios for complex documents.It is fairly efficient for general documents. —The preceding unsigned comment was added by 202.56.254.194 (talk) 10:25, 28 February 2007 (UTC)
thread_title:  LZW Compression: 

message: Question: Should BMP be listed as part of lossless graphics saving methods.
—Preceding unsigned comment added by 193.64.57.253 (talk) 2007-04-13T07:44:30
: No, becapse BMP is not a compression method. The pixel data in a BMP image may be stored with run-length encoding or (in recent variants of the format) other compression schemes, but even in those cases "BMP" itself does not denote compression. –Henning Makholm 14:12, 15 April 2007 (UTC)
thread_title:  Compressive File Types 

message: i've heard the argument that there is no such thing as a TRULY lossless format, that bits a pieces of data get lost with every reformat, even if it is lossless->lossless reformat. can someone clue me in on this and tell me what data is lost? --AlexOvShaolin 03:03, 5 July 2007 (UTC)
replies: text: Don't believe everything you hear. Lossless means lossless. If the decompressed data is not exactly identical to the original, the compression is not lossless. –Henning Makholm 22:57, 5 July 2007 (UTC)

text: Maybe what you have heard is that not any piece of data can be compressed losslessly. Some data must map to itself when a compression algorithm is applied. Think of compressing the following sequence of bits: 01. That's just two bits. To compress it, the result would have to be shorter than the original version: just 1 or 0. Say, 01 is compressed to 0. Here comes the problem. We can now compress, say, 10 into 1, but how to compress 00 or 11? To 0? No, that's 01 compressed. To 1? No, that's 10 compressed! So they are mapped to themselves. This generalizes to large files as well. --ZeroOne (talk | @) 22:04, 6 July 2007 (UTC)

text: OIC, so once its in a lossless format, it can reformat to a lossless format without loosing data, even during compression, as long as the compression is a lossless process. thanx for sheding light. --AlexOvShaolin 00:51, 7 July 2007 (UTC)

text: Alex might be right in the following sense: If we take a video file in lossless format A, recompress it in format B, and recompress it in format A, the resulting file will probably not be equal bit-by-bit to the original one. At least some of the metadata will probably have changed. Hence some information has been lost (and be it only the alignment of some internal fields of the original file). The important thing is that no *useful* information has been lost, i.e., the video data itself is unmodified. The reason why this is still called a lossless compression algorithm is that the compression algorithm is applied to the video itself, and on the video itself, the operation is indeed lossless. Dominique Unruh (talk) 11:31, 30 December 2008 (UTC)
thread_title:  TRULY lossless? 

message: We see
 some individuals to conclude that a well- designed
compression algorithm can compress any input, thus, constituting a
magic compression algorithm.
My algorithm is to use several algorithms and pick the best (and
noting in the header produced which algorithm we chose, for easy
uncompression) ---so there! Yes, can't always compress, but when it
does it is the best algorithm on the block. Do mention please! Jidanni (talk) 20:05, 9 June 2008 (UTC)
replies: text: You can always encode some data into a shorter representation; however, unless you reverse the transformation (decode), it isn't a lossless data compression algorithm.  This most common case of this is a Hash function.  —Sladen (talk) 22:15, 10 June 2008 (UTC)
thread_title: Best algorithm algorithm

message: A big portion of the multimedia section had to do with wavelet transforms and JPEG2000.  JPEG2000 is a lossy compression format, so I removed that portion.  I also took out any reference to wavelet based methods, since it was referenced to the JPEG2000 format.  If someone can provide a good referenced explanation of wavelet based lossless methods that should definitely be added, but note that the wavelet compression page does not have any explanation. Bkessler (talk) 16:31, 11 August 2008 (UTC)
replies: text: JPEG2000 actually has both lossy and lossless modes; but most of its details still ought to be confined to the article on JPEG2000 itself (and likewise for wavelet transforms in general). But this is an old comment so I don't know if you'll respond. Dcoetzee 23:33, 9 February 2009 (UTC)
thread_title:  Mulitmedia Section 

message: I suggest merging universal data compression into the lossless_data_compression#Limitations section.
--76.209.28.222 (talk) 22:35, 9 February 2009 (UTC)
replies: text: I agree, especially since the current article does not provide sufficient context. However, it should be careful to clarify that universal data compression is not at all related to universal codes. Dcoetzee 22:46, 9 February 2009 (UTC)

text: I agree with merger too, but it's been a year now! Pcap ping 21:09, 23 April 2010 (UTC)
replies: text: Finally added the correct merge tags (from a comment at WT:MATH, which suggests improving, rather than merging.)  — Arthur Rubin  (talk) 20:08, 24 June 2010 (UTC)
replies: text: I have deleted those merge tags, since universal data compression has been deleted 19:43, 9 August 2010 by User:Black Kite. —H.Marxen (talk) 04:30, 5 September 2010 (UTC)
thread_title:  universal data compression 

message: Ok, sorry, I accidentally said that GIF was lossless, then I reverted the change.  But in reality, GIF is lossless if the colorspace is limited, right?  I think it would be better to add it back to the list of lossless compressions with a noteL
* GIF(only when there are 256 or less colors).  
Then, idiots like me wouldn't make my mistake sometime in the future ... Currently, GIF is not on the lossless OR lossy compression lists on wikipedia, so what is it ??  I believe that it's either one, the other, or BOTH, but it can't be NEITHER !! SystemBuilder (talk) 23:24, 4 June 2010 (UTC)
replies: text: GIF isn't a compression algorithm. Its a graphics file format, which can use RLE as its compression algorithm. --207.138.32.130 (talk) 00:30, 8 September 2010 (UTC)
replies: text:  You are entirely right, except for the fact that it uses LZW, not RLE, as its compression algorithm. E.g., see the Burn All GIFs campaign. Nicolas Barbier (talk) 10:37, 29 June 2011 (UTC)
thread_title:  Lossless compression with GIF 

message: Could someone repair the formulation 
files of random data cannot be consistently compressed by any conceivable lossless data compression algorithm
into something more exact? Even the formulation random bits is too short to be the right one.
Thank you.  —Preceding unsigned comment added by 90.177.52.52 (talk) 20:31, 13 March 2011 (UTC)
replies: text: What is the inexactness that bothers you? It looks fine to me. –Henning Makholm (talk) 20:42, 13 March 2011 (UTC)
replies: text:  For a subsection on Lossless Data Compression, "random data" is too ambiguous.  If you saved the output of a-million-monkeys-typing-Shakespeare as ASCII text files, that would be universally compressible.  If you saved the bitstream from a cryptography-strength random generator, then no, it would not be universally compressible. Both sources are "random data", but with different entropy.  — Preceding unsigned comment added by 204.9.220.36 (talk) 19:21, 30 March 2012 (UTC)
thread_title:  random data cannot be compressed  

message: It seems that the list currently contains the following, which do not correspond to a lossless compression algorithm:
* Waveform audio format - WAV: WAV is a container format. It typically stores PCM data, which is not compressed, or—if the reduction in bitrate is considered compression—not in a lossless way. The other compression methods that can be used inside a WAV file have nothing to do with "WAV" in itself.
* PCM: See above, PCM is not a compression algorithm, or at least not a lossless one.
* LPCM: As LPCM is a more specific version of PCM, the above argument also counts.
I am therefore removing these from the list.Nicolas Barbier (talk) 08:47, 29 June 2011 (UTC)
thread_title:  Audio formats that don't correspond to a lossless compression algorithm 

message: recently tagged this article for multiple issues (https://en.wikipedia.org/w/index.php?title=Lossless_compression&diff=prev&oldid=645299565), citing "Lists include many unsourced claims of 'near lossless formats', inherently subjective statements".  I'm only seeing one such claim (for JPEG-LS), and the linked article is well-referenced.  "Near lossless" in this sense is not subjective:  it refers to setting a predetermined difference threshold (between the pixel value before and after compression) that is not exceeded by the compression.  JPEG-LS allows such a threshold (even 0 for truly lossless compression) to be specified as part of the compression. -- Elphion (talk) 19:13, 3 February 2015 (UTC)
replies: text: Hearing no response, I've removed the tag. -- Elphion (talk) 23:09, 10 February 2015 (UTC)
thread_title:  Multiple issues tag 

message: A normal number cannot be compressed.  In the Wikipedia article that fact is used as an alternate definition of a normal number.  (By the way, that shows that English is not a normal number.)  This information should probably be integrated into this article.  I don't have any time to do it.  I have added the 'See also' link, but that is not enough.  agb  — Preceding unsigned comment added by 173.233.167.122 (talk) 23:11, 10 February 2015 (UTC)
replies: text: It's of interest at Normal number.  It's not of interest here.  (And it does not show that "English" is not a normal number; English and real numbers are not in the same category.) -- Elphion (talk) 23:34, 10 February 2015 (UTC)
thread_title:  Normal number 

message: Hello fellow Wikipedians,
I have just modified one external link on Lossless compression. 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:
*Added archive https://web.archive.org/web/20090602212118/http://www.unisys.com/about__unisys/lzw to http://www.unisys.com/about__unisys/lzw
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 05:18, 26 May 2017 (UTC)
thread_title:  External links modified 

message: I reverted the removal of the CN tag for the claim that "In fact, if we consider files of length N, if all files were equally probable, then for any lossless compression that reduces the size of some file, the expected length of a compressed file (averaged over all possible files of length N) must necessarily be greater than N."  Is this N the same as the N in the section above?  If so, it's not clear that this N is particularly important -- its behavior may perhaps be a small irregularity.  If not, then it's not clear that the claim is true:  it's easy to devise codes for the 2^N strings of length N s.t. the expected value of the lengths of the encoded strings is < N.  In short, it's not clear how this claim relates to the rest of the section.  I think the whole section would profit from a rewrite. -- Elphion (talk) 07:28, 11 December 2017 (UTC)
thread_title:  Limitation section 

message: Hello fellow Wikipedians,
I have just modified 3 external links on Lossless compression. 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:
*Added archive https://web.archive.org/web/20110717082306/http://studwww.ugent.be/~jdebock/ to http://studwww.ugent.be/~jdebock/
*Added archive https://web.archive.org/web/20101204153125/http://emilcont.webs.com/benchmark.htm to http://emilcont.webs.com/benchmark.htm
*Added archive https://web.archive.org/web/20100821214924/http://heartofcomp.altervista.org/MOC/MOC.htm to http://heartofcomp.altervista.org/MOC/MOC.htm
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 13:45, 6 January 2018 (UTC)
thread_title:  External links modified 

message: The subsection Historical legal issues only mentions legal issues in the first paragraph, then goes on to talk about other compression topics. Compare with e.g. this article. Sjgallagher2 (talk) 14:33, 6 March 2023 (UTC)
thread_title:  Historical legal issues subsection does not talk about legal issues