Talk:Fractal compression

message: What I think this article should look like is something closer to MPEG-1. There are differences, obviously, MPEG-1 is a specific standard, whereas fractal compression is a set of concepts, but as it is this article is more of a set of claims than an explanation of the mechanics of the underlying technology. I'd like to see a separate article on the specific technologies Iterated Systems (and its successors) so that issues like upscaling get a fair hearing.
That's not to say I don't think FC's theoretical advantages in the upscaling field shouldn't get a mention here, obviously they're an advantage, but they should be mentioned in the same way that, say, ease of hardware encoding and decoding are, not as a system of compression in their own rights.
I hope I haven't ruffled any feathers. The idea here is to post a way forward for the article. As it is, it's not a terribly useful article, and the topic itself deserves to have a useful article. --208.152.231.254 (talk) 14:27, 2 September 2009 (UTC)
thread_title: What I'd like to see

message: It claims that fractal compression is for lossy image compression.  This is not true, because there's no reason why it can't be used for lossless compression too (like JPEG too, for example).  Also, stating that JPEG and MPEG are "pixel based" in the sense that (and as opposed to fractal compression) they are "storing pixels" is just plain wrong, JPEG does not store pixels.  It could be said of GIF though.  And finally, stating that fractal compressed images can be recreated to any size without loss of sharpness seems a bit far-fetched. Under some circumstances, you can decode such an image to a higher-than-original resolution, but not to an arbitrary resolution, and not with arbitrary sharpness. 84.73.91.186 (talk) 11:45, 5 March 2010 (UTC)
replies: text: or more precisely not always with artibrary sharpness on everything.  depending on the scaling laws on the particular part of the particular fractal, sharpness may actually increase at higher resolutions and/or zoom levels.  then again it is just as likely to decrease. Kevin Baastalk 20:38, 5 March 2010 (UTC)

text: Thanks this is a small step in the right direction.  Spot (talk) 18:25, 18 May 2011 (UTC)
thread_title:  Opening paragraph has several bogus claims 

message: I just had the chance to have a look at the FAQ and saw that indeed, as user Editor5435 said in the archived discussion, the FAQ is wrong. Or at least misleading.
For instance, when John Kominek is estimating the compression ratios, he makes the following statements: "Exaggerated claims not withstanding, compression ratios typically range from 4:1 to 100:1. All other things equal, color images can be compressed to a greater extent than grayscale images." (emphasis mine). But when he makes the computation for a JPEG comparison he uses a grayscale example and gets some upper bounds of 14.63 or 19.69 (depending on the compression scheme) which indeed do not sound very impressive. But for JPEGs, these compression ratios are, in fact, typical for color images and not for grayscales. I'm recopying the computation he does to have here the reference: "For the sake of simplicity, and for the sake of comparison to JPEG, assume that a 256x256x8 image is partitioned into a regular partitioning of 8x8 blocks. There are 1024 range blocks and thus 1024 transformations to store. How many bits are required for each?
In most implementations the domain blocks are twice the size of the range blocks. So the spatial contraction is constant and can be hard coded into the decompression program. What needs to be stored are:
   x position of domain block        8     6
   y position of domain block        8     6
   luminance scaling                 8     5
   luminance offset                  8     6
   symmetry indicator                3     3
                                    --    --
                                    35    26 bits
In the first scheme, a byte is allocated to each number except for the symmetry indicator. The upper bound on the compression ratio is thus (8x8x8)/35 = 14.63. In the second scheme, domain blocks are restricted to coordinates modulo 4. Plus, experiments have revealed that 5 bits per scale factor and 6 bits per offset still give good visual results. So the compression ratio limit is now 19.69. Respectable but not outstanding."
I highlighted "upper bound" in the quote as this is completely wrong. In fact, what he calculates is a lower bound - that is, no fractally compressed filed using these schemes will exhibit a compression ratio lower than these values. They will all be at least at these values or even higher! Even more, I think the mistake is insidiously misleading as it creates the impression that fractal image compression is not generally effective.
Now, for a color image, using a 4:2:2 color arrangement (i.e. the color components are downsampled by a factor of 2 in each direction, the same as in the jpeg case), the total number of both domain and range blocks reduces by 4. So - for the color components we will have only 7 / 5 bits for the x and y domain block positions yielding a total number of 33 or 24 bits per an 8x8 block and, in the same time, we will have only a quarter of the range blocks. So the final compression ratio must be calculated based on the luminance image and Y-blue and Y-red color component images => 35 bits (luminance, same as grayscale) + 33 / 4 (Y-red color component) + 33 / 4 (Y-blue) = 51.5 bits for the first scheme and 26 + 24 / 4 + 24 / 4 = 38 bits for the second scheme. These bits are packing a block of 8 by 8 pixels, with 3 color channels, each of 8 bits. So the compression ratios are 8x8x8x3 / 51.5 = 29.82 and 40.4, respectively. That is basically the double values computed for the grayscale image.
Now, he then further makes the following statement:"There are other, more complicated, schemes to reduce the bit rate further. The most common is to use a three or four level quadtree structure for the range partitioning. That way, smooth areas can be represented with large range blocks (high compression), while smaller blocks are used as necessary to capture the details." but he doesn't give details about how efficient these techniques can be.
Assuming a quadtree partition with three levels of the range / domain block sizes, this requires additional 3/4 x 2 = 1.5 bits to code the block size (i.e. we need to specify the size level but we're using only 3 of the 4 possible codes given by a 2 bit number). The smallest range blocks would be 8x8, the second level would be 16x16 and the first level will be 32 x 32 pixels. For the smallest block we have the same number of bits as in the previous example plus the additional 1.5 bits for the size level. For the 16x16 block we can reduce the number of needed bits by 2 and for the 32 x 32 by another 2 bits (from the x / y coordinates). For the given 256 x 256 image these blocks would yield 1024, 256 and 64 range blocks. Assuming, that 50% of the image area is covered by the second level blocks and the rest is evenly divided between first level and third level we have a total of 0.5 x 256 blocks of 16x16, 0.25 x 1024 blocks of (8x8) and 0.25 x 64 blocks of (32x32). With theses, the compression ratios would be 36.7 or 49, depending on the coding scheme. For the color image, the compression ratio can be basically the double of this values, i.e. about 70:1 up to basically 100:1.
Yes, the lower bounds for the grayscale image are the values calculated by John Kominek (and wrongfully called upper bounds). But it must be stressed that these are lower bounds. If quadtree partitions are used, the compression ratios will be, typically, about two times larger.
I believe John Kominek is not stressing this fact enough - in fact, like I said above he made a very insidious mistake here by calling the values as upper bounds - and if you couple this with the omission of the color images compression ratios and only the passing mentioning of the further bitrate reductions techniques without estimating how effective they can be, the image compression FAQ is wrong and misleading with respect to fractal image compression.
And what I find disturbing and from my point of view completely disqualifies the image compression FAQ as a good reference is the fact that this mistake was unnoticed for so many years. For 20 years!! 85.204.186.42 (talk) 22:20, 15 October 2015 (UTC)
thread_title:  Image compression FAQ was and still is misleading about fractal image compression. 

message: Hello fellow Wikipedians,
I have just modified 8 external links on Fractal 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/20080303154903/http://www.cas.sc.edu/geog/rslab/Rscc/mod2/2-4/2-4.html to http://www.cas.sc.edu/geog/rslab/Rscc/mod2/2-4/2-4.html
*Added archive https://web.archive.org/web/20080106202236/http://www.byte.com/art/9701/sec12/art1.htm to http://www.byte.com/art/9701/sec12/art1.htm
*Added archive https://web.archive.org/web/20110101235706/http://sciencelinks.jp/j-east/article/200310/000020031003A0228183.php to http://sciencelinks.jp/j-east/article/200310/000020031003A0228183.php
*Added archive https://web.archive.org/web/20080127132016/http://sciencelinks.jp/j-east/article/200214/000020021402A0392249.php to http://sciencelinks.jp/j-east/article/200214/000020021402A0392249.php
*Added archive https://web.archive.org/web/20080131103423/http://sec.edgar-online.com/2001/03/30/0000931763-01-000662/Section20.asp to http://sec.edgar-online.com/2001/03/30/0000931763-01-000662/Section20.asp
*Added archive https://web.archive.org/web/20150923175932/http://www.atp.nist.gov/eao/sp950-3/info_tech.pdf to http://www.atp.nist.gov/eao/sp950-3/info_tech.pdf
*Added  tag to http://www.pcpro.co.uk/macuser/reviews/15870/genuine-fractals.html?searchString=fractal
*Added  tag to http://spiedl.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=OPEGAR000044000010107002000001&idtype=cvips&gifs=yes
*Added archive https://web.archive.org/web/20101023100132/http://www.femtosoft.biz/fractals/fractal.html to http://www.femtosoft.biz/fractals/fractal.html
*Added archive https://web.archive.org/web/20001204165500/http://www.howell1964.freeserve.co.uk/MSc/FIC/FIC_00.htm to http://www.howell1964.freeserve.co.uk/MSc/FIC/FIC_00.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) 03:38, 5 October 2017 (UTC)
thread_title:  External links modified 

message: https://en.wikipedia.org/w/index.php?title=Fractal_compression&oldid=918561590#Implementations
I have changed the wording and section name of Open souce. The source of Fiasco includes a mass of libaries all with have their own licences, some of wich are not FOSS. Therefore, it cannot be reported in good faith that the librariy is Open Source since their are componets of the source which are not FOSS. Femtosoft provided no licence for their binaries or source code. At best, it can be said that Femtosoft is souce distributed free-ware (software that is distributed gratis but is not nessasarily FOSS) and not FOSS as it dose not include a FOSS licence. The omission of copyright does not negate it; if IP lacks a copyright notice, it is not then placed in the public domain. Due to the above discrepancies it is better to label the section Implementations, as neither meet the discriminating criteria to be labelled Open Source.
Seamus M. Slack (talk) 08:40, 29 September 2019 (UTC)
thread_title: Open souce ⇒ Implementations

message: Current article claims right from the start that fractal compression is "lossy" and "for visuals (picture/photo/video)". It would be nice to support those extraordinary claims with strong proof. Fractals and Mandelbrot sets are powerful and broad math concepts, so it is not intuitive that fractal-based compression would be of such limited use. If fractals are iterated long enough that their frequency at least doubles that of smallest signal found in (uncompressed, digital) original, than data loss will not occur per Shannon. It is also not obvious that fractal-based compression needs to be limited to visual data, since even a lossy compression method could be paired with clever error-correction code or machine-learning / neural net tech to flawlessly recovery e.g. textual data and the high storage efficiency of fractal-based compression could make that endeavour competitive. 94.21.160.43 (talk) 20:42, 27 December 2022 (UTC)
thread_title:  Extraordinary claims require strong proof.