Jpeg2png: Silky smooth JPEG decoding – no more artifacts (2016)
github.com
github.com
Instead of trying to smooth the entire image, it reduces blocking artifacts by finding plausible coefficients that reduce discontinuities at block boundaries (jpegs are encoded as a series of 8x8 blocks). "jpeg2png gives best results for pictures that should never be saved as JPEG", but knusperli works well on normal photographic content, since it only tries to remove blocking artifacts.
> A JPEG encoder quantizes DCT coefficients by rounding coefficients to the nearest multiple of the elements of the quantization matrix. For every coefficient, there is an interval of values that would round to the same multiple. A traditional decoder uses the center of this interval to reconstruct the image. Knusperli instead chooses the value in the interval that reduces discontinuities at block boundaries. The coefficients that Knusperli uses, would have rounded to the same values that are stored in the JPEG image.
This is essentially the same thing, but using slightly different regularizers. In both cases, an image is found that whose jpeg compression is identical to the given one, by selecting the "most regular" image among the large family of such images. Jpeg2png minimizes the total variation over the whole image, and knusperly only along the boundaries of the blocks. The effect is quite similar at the end.
Also try with: https://github.com/ilyakurdyukov/jpeg-quantsmooth with "-q6" (default setting without luma-aware chroma upsampling)
My guess is that quantsmooth won't handle squares in the background well, but will be better at the edges (without excessive blurring).
Update: I tested it, it's about 10% quality, jpeg-quantsmooth doesn't handle this quality. At 25% quality - result is fine, starting at 20% and less - not good.
Perhaps the synthesis of all three projects combined into one (taking best of each) could give a great result.
So then...
jpeg2png: overblurs and slow
knusperli: does only deblocking, not removes artifacts
jpegqs: fails to deblock low frequencies (less 25% quality)
(As a citation, I can only offer the fact that I've frequently tried to clean up JPEG images I've found online, and Knusperli is usually my first step. It's never a sufficient step, though.)
That's the funniest thing I've read in a while.
"...It can be kept in some of the ordinary structural metals—steel, copper, aluminum, etc.—because of the formation of a thin film of insoluble metal fluoride that protects the bulk of the metal ... If, however, this coat is melted or scrubbed off, and has no chance to reform, the operator is confronted with the problem of coping with a metal-fluorine fire. For dealing with this situation, I have always recommended a good pair of running shoes."
The advantage of those over this is that the encoder knows that the decoder is going to run the filter, and it can use that in its perceptual model to choose an encoding which looks most like the original after deblocking. Video codecs also use the deblocked version as reference frames. So you see these artifacts in mpeg-2 video and jpeg, but not more recent ones.
In newer codecs you can notice that sometimes blocks of 8 or 16 pixels get blurred with a 4px-wide blur, which is barely enough to cover up the edges, but not enough to mask square-ish shapes underneath.
[1] Implemented for a custom compressor: https://hific.github.io/
It's not as easy as "just round" though, because you don't know where the digits start to repeat. A smart function would also print 4.1249999999999 as 4.125.
A fancy unicode version could even include the mathematical notation to print 3.333333333333 as 3.3 with a line over the trailing 3. Or 4.2525252525 as 4.25 with the bar over the 25. Might be asking too much of a simple print function though, this might end up being an extension of the halting problem.
But maybe there could be some heuristics that get it right 99% of the time (with a don't use this library for serious number crunching disclaimer).
A better example would be something like 1/5, which for almost every purpose is better printed as 0.2 instead of 0.20000000298023223876953125. The latter is absurdly long and gives the misleading impression of precision far in excess of the ~7 decimal digits that single-precision floats are capable of representing.
The difference between 0.2 and that long string is due to a slightly different cause than a difference between 3.999... and 4: the latter is likely due to information loss during calculations and may be reduced and sometimes avoided entirely with careful ordering of calculations and using the right rounding modes. But 0.2 can never be exactly represented, even as the input to a chain of calculations. The loss of accuracy is an unavoidable first step of trying to put 0.2 into a binary FPU register.
Students should learn about the pitfalls of floating point arithmetic. But preferably in a way that doesn't leave them with the impression that it is a non-deterministic process that always leaves you with trailing garbage that needs to be ignored.
Then a comparison would take epsilon into account instead of just a bit match.
[0] https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfk... or use your search engine
https://www.reddit.com/r/ProgrammingLanguages/comments/930pc...
Interesting value proposition.
There may be equivalents for other misused file types/formats. The obvious one is the inverse case of photos saved as GIFs, but I imagine audio and text (eg. PDF malapropisms?) are possible too.
Now if only they stopped cropping images to rand()xrand() in timelines pretending they employ advanced ML algorithms to do so :)
The result is very good. The speckling is effectively eliminated without smearing the letters.
JPEG Encoded, 25% quality: http://jubei.ceyah.org/overcompressed/crop-jpg.png
JPEG2PNG: http://jubei.ceyah.org/overcompressed/crop-converted.png
However, now I'm wondering whether my impression that the reference decoded text is easier to read is a form of overfitting. I have spent the past 20 years reading low-quality JPEG screenshots on the internet, maybe the perceptual centers of my brain have developed an unblocking algorithm?
That you can design a better JPEG encoder for a known reference decoder (which decoded version best matches the original), and you can likewise design a better JPEG decoder for a known reference encoder.
But now that there are both encoders and decoders trying to be more efficient and non-blocky respectively... it feels like a mess. Even more so because a decoder never knows which encoder was used, and an encoder never knows which decoder.
Is there any solution to this mess? Is there a best practice here? Since most JPEG's are probably viewed on the web, do all browsers share the same decoder, and so effort is best spent on the encoder? Or even while encoder improvements are made specifically for the algorithms browsers use, can improvements to decoders still be made that remain improvements, instead of e.g. "overfitting" and actually making things worse?
This just feels like a bit of an "improvements race" on both sides which leaves me a little dizzy in trying to understand it...
The naming is also odd. I don't imagine it would do well with text (which are the sorts of images I associate with png) that was jpeg encoded then decoded with it.
I know that mozjpeg [1] features trellis quantization for JPEG encoding. I wonder how this decoder would do with that?
Denoiser in ray tracing are quite a success, and this strikes me as quite similar.
In fact, now that I think of it, you probably don't even need a GANN, since you can create an infinite training set for quasi-free.
> Quis autem vel eum iure reprehenderit, qui inea voluptate velit esse, quam nihil molestiae consequatur, vel illum, qui dolorem eum fugiat, quo voluptas nulla pariatur?
Translation: Who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?
This text could very well be the first page of a softcore erotica (or even hardcore!). The rest of the text is not usually visible. But then again, neither is the rest of lena!
But if it were true, then you'd have it your way: it'd also be inappropriate in professional settings that don't naturally necessitate it.
According to Wikipedia[0], "[t]he placeholder text is taken from parts of the first book's discourse on hedonism." The first book being the first book of Cicero's De finibus bonorum et malorum.
[0] https://en.wikipedia.org/wiki/De_finibus_bonorum_et_malorum
It's a philosophical argument against Epicurianism. Which has as much in common with softcare erotica as the phone book.
Not sure what your point is.
Women are people, they don't care.
Things like the canonical test image being a sexy "come hither" look, coming from a Playboy centerfold, definitely don't help.
And it's not enough to say "well the rest of the centerfold isn't shown". Come on. We all know the source of the image.
And "tradition" is far less important than CS being a welcoming environment for all people.
Computer science is a profession. Let's use images that are appropriate for a professional setting.
Let’s focus on real things, not on this phony issues!
It’s offensive, it keeps women out of CS, it’s a symbol of the patriarchy, etc...
As woman, I am saying this is not the case, at least not for THIS woman: I’ve never felt excluded because of Lena, my CS studies were not impeded by Lena in any way, I have actually used Lena’s image for a small project.
Of course I would accept someone saying that the image offends someone (better if this point is substantiated by evidence) but I absolutely reject people speaking in the name of all women, an saying that Lena offends all women. This is not true!
Also, be careful not to attack a strawman: the issue is of course not just the image.
As a man I experienced plenty of unpleasant conversation about women, conversation which might be referred to as men-talk or some such. Also, I'm not competitive at all, while many men would identify that as manly behavior. One of the few women in my university program confided that this (usually unfounded) self-assuredness was very annoying and a huge turn-off, a feeling we both shared, but would have been regarded as an essential ingredient to participating in that program.
Of course, such issues are also present in the reverse. My wife had similar conversations but about men amongst some female colleagues. Fortunately, we've met enough people to not have to settle for such juvenile views/conversations. I can absolutely see how a woman would find it very difficult to be comfortable in such an environment however, when I didn't even feel part of that mildly macho culture.
Just because something is 'anti-women', does not mean it can only bother women. Our cultures associate many things to gender, which in my view is a leftover of centuries past and we would do well to remove that sort of association. Maybe then, a picture of Lena wouldn't represent a (sub)culture so accurately and be therefore an indicator of the problem.
You are making a much stronger claim without evidence. How is Lena harmful? How many women did Lena drive out of CS?
Do you have some proof, some data, besides neo-Marxist crap such a intersectionalized mysoginistic oppression?
It reminds me of that video that showed that college students are outraged by stereotypical Mexican Halloween costumes, but actual Mexicans are fine with it.
Are you fighting for women, or for your ego?
It feels to me like there's some deeper reason for the gender disparity in tech than Lena. I don't have any issue with changing the picture whatsoever - I'm sure we can find some other picture to use as a baseline (big buck bunny?). But I would be willing to bet that it will do precisely nothing to change the fact that there aren't very many women in CS.
I can think of many other factors that seem more plausible to me. Me and my friends were into minecraft - at the time, you installed minecraft mods by overwriting files inside the minecraft.jar. If you wanted to set up a minecraft sever, you were given some command-line program to run and you had to set up port-forwarding in your router. Just doing this stuff makes you more comfortable with computers, and makes the jump to "I want to start programming" seem much smaller than someone who has never stepped outside Chrome and MS Office. And PC gaming is much more popular among young men than young women, so this avenue of becoming comfortable with the computer is going to be much more accessible to men. Not to mention, if you like games, eventually you'll want to make one - I think every PC gamer has at least thought about installing Unreal and trying to make their dreams into reality. I think if we actually want to increase how many women are in CS (and nothing would make me happier), this is the kind of stuff we should be thinking about, not whether image processing programmers use a picture of an attractive woman with bare shoulders too often.