jpeg compression artifacts
-
- Mitglied
- Beiträge: 65
- Registriert: Mo 27 Apr 2015 21:20
jpeg compression artifacts
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
jpg HQ disabled
jpg HQ enabled
png 16 colours / nearest colour
jpg HQ disabled
jpg HQ enabled
png 16 colours / nearest colour
jpg HQ disabled
jpg HQ enabled
Jpeg compression is set to 60% for all.
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
jpg HQ disabled
jpg HQ enabled
png 16 colours / nearest colour
jpg HQ disabled
jpg HQ enabled
png 16 colours / nearest colour
jpg HQ disabled
jpg HQ enabled
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!
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: jpeg compression artifacts
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.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.
Cheers
Burkhard.
-
- Mitglied
- Beiträge: 65
- Registriert: Mo 27 Apr 2015 21:20
Re: jpeg compression artifacts
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 resolutionbkh 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.
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!
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: jpeg compression artifacts
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.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.
Cheers
Burkhard.
-
- Mitglied
- Beiträge: 86
- Registriert: Fr 23 Aug 2013 05:54
Re: jpeg compression artifacts
There are no artifacts in your posted images
-
- Mitglied
- Beiträge: 65
- Registriert: Mo 27 Apr 2015 21:20
Re: jpeg compression artifacts
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.
The jpeg image is a mix: precisely of the Bayern matrix output (for those cameras using it, of course) and the next lossy compression.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.
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!
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
-
- Mitglied
- Beiträge: 65
- Registriert: Mo 27 Apr 2015 21:20
Re: jpeg compression artifacts
I am happy for you if you do not see any. Bye.Lundberg02 hat geschrieben:There are no artifacts in your posted images
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!
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: jpeg compression artifacts
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:The jpeg image is a mix: precisely of the Bayern matrix output (for those cameras using it, of course) and the next lossy compression.
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.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.
There are enough JPEG tools around to check that HQ in PL really means 4:4:4 subsampling instead of 4:2:0.
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: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",
Glad we agree on that, now.iosoio hat geschrieben:This is the reason I've answered that the green can't get the full resolution.
That's normal and expected, given the way lossy JPEG works. If you have to avoid artefacts, then, by all means, avoid lossy formats.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.
Cheers
Burkhard.
-
- Mitglied
- Beiträge: 65
- Registriert: Mo 27 Apr 2015 21:20
Re: jpeg compression artifacts
Thanks.
This kind of artifacts are actually jpeg related, rather than generically caused by all lossy compressions.
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.
Jpeg behavior is very similar of the one shown by XnView. It even seems that PL and XnView are using the same library.
Bye
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.
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.
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!
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: jpeg compression artifacts
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.iosoio hat geschrieben:This kind of artifacts are actually jpeg related, rather than generically caused by all lossy compressions.
Cheers
Burkhard.
-
- Betatester
- Beiträge: 4021
- Registriert: So 03 Jul 2005 13:35
- Wohnort: Mülheim/Ruhr
Re: jpeg compression artifacts
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: 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.
Here the red/green letter: 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.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
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!
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: jpeg compression artifacts
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.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...
Cheers
Burkhard.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- Mitglied
- Beiträge: 65
- Registriert: Mo 27 Apr 2015 21:20
Re: jpeg compression artifacts
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.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.
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.
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!
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: jpeg compression artifacts
The first file isn't a JPEG but a PNG.iosoio hat geschrieben:Tell me what do you think about this comparison.
Cheers
Burkhard.
-
- Mitglied
- Beiträge: 65
- Registriert: Mo 27 Apr 2015 21:20
Re: jpeg compression artifacts
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 checkbkh hat geschrieben:The first file isn't a JPEG but a PNG.iosoio hat geschrieben:Tell me what do you think about this comparison.
Cheers
Burkhard.
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.
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!
Bravo, sag deiner Mutter, sie soll dich nach Italien bringen, um als Richterin zu lernen!