jpeg compression artifacts

Here everybody can post his problems with PhotoLine
Benutzeravatar
iosoio
Mitglied
Beiträge: 65
Registriert: Mo 27 Apr 2015 21:20

jpeg compression artifacts

Beitrag von iosoio »

As suggested I open this topic for discussing a (by me) supposed problem in Photoline Jpeg compression module which seems (again, to me) causing a kind of ringing artifact around objects if the background is a flat colour.

This artifact seems related to the chroma subsampling because it is much more pronounced when HQ option is unchecked, but here the problem arises.

4:2:2 means that only two samples per colour are taken every 4 luma values, and 4:2:0 (or 4:1:1 with a different matrix/order of sampling) that the sample per colour is only one. It's the way video is captured where luma samples are followed by the blue and red differences.

When YCbCr (4:2:2 or 4:2:0) is converted to RGB, Y, the luma, is usually assigned to the green channel, and consequently the green should have a much higher true resolution compared to the red and blue, but here's the problem.

I've made a simple test of text on three different flat backgrounds: blue, red and green.

As you see the green background shows as much artifacts as the red one and (apparently) less than the blue, which is the colour to which the human eye is less sensitive and, because of this, it gets the smallest number of information even in the Bayer matrix of a CCD/CMOS.

Moreover, if the Web Export HQ means 4:4:4, with this option activated there should be virtually no artifacts with any background colour.

How is it?


-
png 16 colours / nearest colour

Bild

jpg HQ disabled

Bild

jpg HQ enabled

Bild

png 16 colours / nearest colour

Bild

jpg HQ disabled

Bild

jpg HQ enabled

Bild

png 16 colours / nearest colour

Bild

jpg HQ disabled

Bild

jpg HQ enabled

Bild

Jpeg compression is set to 60% for all.
Papa, Papa, ich möchte ein Clown sein, wenn ich groß bin.
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: jpeg compression artifacts

Beitrag von bkh »

iosoio hat geschrieben:When YCbCr (4:2:2 or 4:2:0) is converted to RGB, Y, the luma, is usually assigned to the green channel, and consequently the green should have a much higher true resolution compared to the red and blue, but here's the problem.
Y is fundamentally different from G, just have a look at https://en.wikipedia.org/wiki/YCbCr#JPEG_conversion. Btw., if you want the full resolution of G, the other colour has to be R+B, not just R or B. Anyway, as soon as colour comes into play, subsampling has lower resolution – the only "colour" that uses full resolution is grey.

Cheers

Burkhard.
Benutzeravatar
iosoio
Mitglied
Beiträge: 65
Registriert: Mo 27 Apr 2015 21:20

Re: jpeg compression artifacts

Beitrag von iosoio »

bkh hat geschrieben:Y is fundamentally different from G, just have a look at https://en.wikipedia.org/wiki/YCbCr#JPEG_conversion. Btw., if you want the full resolution of G, the other colour has to be R+B, not just R or B. Anyway, as soon as colour comes into play, subsampling has lower resolution – the only "colour" that uses full resolution is grey.

Cheers

Burkhard.
Hi. Sure Y can't get the full resolution, even in a Bayer matrix based CCD (but not in the previous version of Foveon) it gets around 50%, the remaing half being shared by the red and blue channels; but it takes a much higher relative resolution anyway. This should give less artifacts in the green areas, which does not. Then, yes, the monochrome configuration is the only one for the full resolution :)

Bye.

Bild
Papa, Papa, ich möchte ein Clown sein, wenn ich groß bin.
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: jpeg compression artifacts

Beitrag von bkh »

iosoio hat geschrieben:Hi. Sure Y can't get the full resolution, even in a Bayer matrix based CCD (but not in the previous version of Foveon) it gets around 50%, the remaing half being shared by the red and blue channels; but it takes a much higher relative resolution anyway.
In JPEGs, Y gets full resolution. Y is different from green (and Y in YCrCB is different from Y in XYZ). JPEG doesn't use Bayer matrices. All pure RGB colours have the same spatial resolution in JPEG. You seem to be mixing up a lot of things.

Cheers

Burkhard.
Lundberg02
Mitglied
Beiträge: 86
Registriert: Fr 23 Aug 2013 05:54

Re: jpeg compression artifacts

Beitrag von Lundberg02 »

There are no artifacts in your posted images
Benutzeravatar
iosoio
Mitglied
Beiträge: 65
Registriert: Mo 27 Apr 2015 21:20

Re: jpeg compression artifacts

Beitrag von iosoio »

bkh hat geschrieben:Btw., if you want the full resolution of G, the other colour has to be R+B, not just R or B. Anyway, as soon as colour comes into play, subsampling has lower resolution – the only "colour" that uses full resolution is grey.
bkh hat geschrieben:[In JPEGs, Y gets full resolution. Y is different from green (and Y in YCrCB is different from Y in XYZ). JPEG doesn't use Bayer matrices. All pure RGB colours have the same spatial resolution in JPEG. You seem to be mixing up a lot of things.
The jpeg image is a mix: precisely of the Bayern matrix output (for those cameras using it, of course) and the next lossy compression.

My investigation was about the artifacts seen when the background is a flat colour, you told me that the HQ option means 4:4:4, and, since with HQ activated the artifacts were much less, I've hypothesized the problem was the chroma subsampling.

In reality I think that the supposed colour redundancy information is waved no matter which colour space you choose; and in fact, following this reasoning, if you increase the compression percentage, the artifacts increase as well even with HQ selected. In othe words I personally don't think those artifacts due to the colour subsampling.

Then you said that if I want the full resolution of green "the other colour has to be R+B, not just R or B", and for courtesy (the so called courtesy of dubt) I've thought that no colour sensor but the old foveon outputs a full green channel, thus I've remembered that the green full resolution simply isn't there since the conversion of the raw file, and, unless you assume for full resolution the icoming of the jpeg quantization, the thing has no sense.

This is the reason I've answered that the green can't get the full resolution.

I do distiguish the different phases of the process, I do not mix anything but I've had a practical question to solve in which converge all of them and I didn't solved it: the artifacts on flat colour, green included, are still there.

Bye.
Papa, Papa, ich möchte ein Clown sein, wenn ich groß bin.
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
Benutzeravatar
iosoio
Mitglied
Beiträge: 65
Registriert: Mo 27 Apr 2015 21:20

Re: jpeg compression artifacts

Beitrag von iosoio »

Lundberg02 hat geschrieben:There are no artifacts in your posted images
I am happy for you if you do not see any. Bye.
Papa, Papa, ich möchte ein Clown sein, wenn ich groß bin.
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: jpeg compression artifacts

Beitrag von bkh »

iosoio hat geschrieben:The jpeg image is a mix: precisely of the Bayern matrix output (for those cameras using it, of course) and the next lossy compression.
No. A standard JPEG consists of a full resolution Y image and a Cr and Cb plane, possibly (due to subsampling) lower resolution. Maybe you want to have a look at the [ur=http://www.itu.int/rec/T-REC-T.871-201105-I/enl]JFIF specs[/url]. In cameras, subsampling takes place long after de-Bayering, there is no direct connection between the two (other than for Bayer sensors, 4:2:0 subsampling doesn't lose too much colour information because the sensor never captured it).
iosoio hat geschrieben:In reality I think that the supposed colour redundancy information is waved no matter which colour space you choose; and in fact, following this reasoning, if you increase the compression percentage, the artifacts increase as well even with HQ selected. In othe words I personally don't think those artifacts due to the colour subsampling.
If you use HQ, the artefacts due to subsampling will disappear. All that remains are artefacts due to lossy compression. I suppose you do know what lossy compression means. JPEG quality controls the amount of artefacts, but even at 100, you'll have some.

There are enough JPEG tools around to check that HQ in PL really means 4:4:4 subsampling instead of 4:2:0.
iosoio hat geschrieben:Then you said that if I want the full resolution of green "the other colour has to be R+B, not just R or B",
This was under your (false) assumption that Y was RGB green. I was just trying to explain that not only your hypothesis, but also your experiment to test it was wrong.
iosoio hat geschrieben:This is the reason I've answered that the green can't get the full resolution.
Glad we agree on that, now.
iosoio hat geschrieben:I do distiguish the different phases of the process, I do not mix anything but I've had a practical question to solve in which converge all of them and I didn't solved it: the artifacts on flat colour, green included, are still there.
That's normal and expected, given the way lossy JPEG works. If you have to avoid artefacts, then, by all means, avoid lossy formats.

Cheers

Burkhard.
Benutzeravatar
iosoio
Mitglied
Beiträge: 65
Registriert: Mo 27 Apr 2015 21:20

Re: jpeg compression artifacts

Beitrag von iosoio »

Thanks.
iosoio hat geschrieben:I do distiguish the different phases of the process, I do not mix anything but I've had a practical question to solve in which converge all of them and I didn't solved it: the artifacts on flat colour, green included, are still there.
bkh hat geschrieben:That's normal and expected, given the way lossy JPEG works. If you have to avoid artefacts, then, by all means, avoid lossy formats


This kind of artifacts are actually jpeg related, rather than generically caused by all lossy compressions.

Bild

As you can see in the following 16 colour coded png image, which I assumed as reference, no dots surround the 'C' character and the image is less than a half of the jpeg one.

Bild

Jpeg behavior is very similar of the one shown by XnView. It even seems that PL and XnView are using the same library.

Bye
Papa, Papa, ich möchte ein Clown sein, wenn ich groß bin.
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: jpeg compression artifacts

Beitrag von bkh »

iosoio hat geschrieben:This kind of artifacts are actually jpeg related, rather than generically caused by all lossy compressions.
Yes, of course, Colour reduction causes other types of artefacts, depending on the reduction method (PNG itself is lossless). For images with just two or three colours and a bit of antialiasing, colour reduction works well, while it handles smooth transitions very badly. JPEG, in a sense, is the opposite. But this is all well-known.

Cheers

Burkhard.
Benutzeravatar
Hoogo
Betatester
Beiträge: 4021
Registriert: So 03 Jul 2005 13:35
Wohnort: Mülheim/Ruhr

Re: jpeg compression artifacts

Beitrag von Hoogo »

I've made a preset for the channel mixer that converts a RGB picture to YCrCb. I tried to add the opposite, too, but seems my math really needs some practice... :? Find Zip attached. I stored Y in Green, Cr and Cb for obvious reasons in R and B. I just stored it there! That doesn't mean that G is necessarily most similar to Y!!

Here the red/green letter:
YCrCb.png
YCrCb.png (2.07 KiB) 2476 mal betrachtet
The letter is a generated picture, so we do not have to care about the Bayer matrix of a camera and how it would reduce the resolution.

The finest contrast in this picture is in the Cr-Channel.
Y doesn't have that much contrast, you can clearly see the 31% and 59% that are used for pure read and green.
If you want to create a picture with best contrast in the Y-channel,you would have to choose different colors instead of green and red.

For subsampling Cr and Cb now would be resized to 50%. I'm not sure if Jpg requires some special methods, but I guess it just depends on the coder how that's done. Usually there should be a lowpass filter. Anyways, this decrease in resolution might be nearly invisible for photos, but not for created graphics. Even at the best JPG quality the colors at the edges would be washed, a little bit similar to a filter "soften" in Lab where only a and b are softened.

And after that step the real JPG compression starts, and that simply creates artifacts at 60%. These artifacts will surely spread more when the channel will be scaled to 200% during decompression. And they should be different, too. Without subsampling a channel with sharp edges would be processed, with subsampling the channel will have soft edges.

So far I'm happy with everything ;)

But at the beginning, in the other thread, you mentioned that the Jpgs of PL look worse than the Jpgs of other programs? PS has bound the subsampling to its quality setting, and there are different quantization tables and maybe different low pass filters/methods for subsampling, but beside of that I'd expect that for same size the pictures will look comparable.

If you meant different qualities for different file formats, then I agree.
Zuletzt geändert von Hoogo am Mo 01 Jun 2015 23:42, insgesamt 1-mal geändert.
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: jpeg compression artifacts

Beitrag von bkh »

Hoogo hat geschrieben:I've made a preset for the channel mixer that converts a RGB picture to YCrCb. I tried to add the opposite, too, but seems my math really needs some practice... :?
Here's a zip archive with both the forward and inverse transforms for the channel mixer. Btw., the inverse formulas are also in the Wikipedia article cited above.

Cheers

Burkhard.
Dateianhänge
RGB<->CrYCb.zip
(618 Bytes) 65-mal heruntergeladen
Benutzeravatar
iosoio
Mitglied
Beiträge: 65
Registriert: Mo 27 Apr 2015 21:20

Re: jpeg compression artifacts

Beitrag von iosoio »

Hoogo hat geschrieben:But at the beginning, in the other thread, you mentioned that the Jpgs of PL look worse than the Jpgs of other programs? PS has bound the subsampling to its quality setting, and there are different quantization tables and maybe different low pass filters/methods for subsampling, but beside of that I'd expect that for same size the pictures will look comparable.

If you meant different qualities for different file formats, then I agree.
Hoogo, I'm not using Photoshop since 10 years or so. I don't like software bloat but, more important, I like alternatives, especially if they are as good (or better) as the mainstreams everybody was told to choose.

PhotoLine is an excellent alternative but there are things you can't deny. The following three samples are, in order: {1} compressed with TinyJPEG weighting 841 bytes {2} with PL, 1.64KB and HQ disabled (otherwise it'd been much larger than just 2x circa) {3} with PL, 2.46KB and HQ checked.

Tell me what do you think about this comparison.

Bild

Bild

Bild
Papa, Papa, ich möchte ein Clown sein, wenn ich groß bin.
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: jpeg compression artifacts

Beitrag von bkh »

iosoio hat geschrieben:Tell me what do you think about this comparison.
The first file isn't a JPEG but a PNG.

Cheers

Burkhard.
Benutzeravatar
iosoio
Mitglied
Beiträge: 65
Registriert: Mo 27 Apr 2015 21:20

Re: jpeg compression artifacts

Beitrag von iosoio »

bkh hat geschrieben:
iosoio hat geschrieben:Tell me what do you think about this comparison.
The first file isn't a JPEG but a PNG.

Cheers

Burkhard.
You're right! TinyJPEG modifies the image; imgur (the file hosting site used to upload) detects this and changes the extension. I've forgotten to check :oops:

I don't know if it's the metadata to be wrong rather than the extension but, in any case, JPEGsnoop can't find neither the jpeg marker nor the jpeg data.

Sorry.

Bild
Papa, Papa, ich möchte ein Clown sein, wenn ich groß bin.
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
Antworten