Poor Jpg Quality - SaveImage, #PB_ImagePlugin_JPEG

[nase09]

I would really like to get better results saving jpg-images (SaveImage using #PB_ImagePlugin_JPEG, and Flags=10).
With a quality setting of max (10) its not satisfying getting poor results.. (picture size is less important with a max quality setting..).
(It looks like Chroma Subsampling is used all the time (?) with quality=10 it should be disabled (this can improve pictures e.g. with bright colors a lot..))

[c4s]

In my experience saved jpg's with quality level >= 8 look quite good. What exactly is not satisfying? Maybe you can post an image to reproduce it?

[nase09]

In my experience saved jpg's with quality level >= 8 look quite good. What exactly is not satisfying? Maybe you can post an image to reproduce it?

(I had to look for a free image-hoster first..)
(Original )
(JPG saved with purebasic )

[c4s]

I can confirm that and you're right that it doesn't look very good at all. I mean it's quality level 10/10! So I definately +1 your request.

However you should change the thread title. Currently it sounds more like a bug post then a feature request.
Feature request: Like you said the quality reducing chroma subsampling (and maybe also other methods) shouldn't be used on high quality levels of e.g. >= 5.

Just for the comparison: Saving that image in Photoshop with a quality level of about 4/12 looks way better!

[nase09]

Problem still exists in Version 5.0.
I'm sorry, but the "Save to Jpg Functionality" is quite important, I really think something must happen here (soon)

[Puffolino]

Bad luck, that the range for

the quality parameternhas been definen from 0 to 9 instead of 0 to 99 which would have given us a better granularity to influence the resuoting image size and quality.

[Fred]

We use standard libjpeg so I don't know why the results are bad.

[nase09]

We use standard libjpeg so I don't know why the results are bad.

Thanks for response.
Ok, with this information I tested some more, and it definitely has something to do with Color/Chroma Subsampling.
Is the latest version of Libjpeg used in PB5 ? There must/may be some option controlling the subsampling..
there is a variable called 'do_fancy_upsampling'(boolean) - maybe it does the job (when false, its true by default..).
Other info I found (I'm pretty sure that's what is needed) :

Code: Select all

DDebug() << "Using LibJPEG none chroma-subsampling (4:4:4)" << endl;
cinfo.comp_info[0].h_samp_factor = 1;
cinfo.comp_info[0].v_samp_factor = 1;
cinfo.comp_info[1].h_samp_factor = 1;
cinfo.comp_info[1].v_samp_factor = 1;
cinfo.comp_info[2].h_samp_factor = 1;
cinfo.comp_info[2].v_samp_factor = 1;

Or how about using an other library.. e.g. 'Libjpeg-turbo' - its very fast and used a lot.
(But Libjpeg-turbo is pretty much 'based on' Libjpeg, so I guess the problem can be resolved keeping libjpeg..)

I succeeded saving the pic (given below) with software using libjpeg-turbo. e.g. IrfanView (jpg-options needed: 'Disable chroma color subsampling' and 'Save quality ~ 100') or XnConvert(save-options needed: 'Subsampling-Factor 1x1,1x1,1x1(best quality)' and 'Quality ~ 100')

Here is a pic for easy testing

[nase09]

*bump*
(needed jpg-changes are welcome in v5.10..)

[MachineCode]

JPG is designed for real life images, not text. Your results don't surprise me. You should be using PNG for text.

[luis]

JPG is designed for real life images, not text. Your results don't surprise me. You should be using PNG for text.

It does surprise me (and the original poster), there is no reason for that result.
The instant I saw the difference I thought too about something wrong with subsampling.
In any case, there is something wrong.

[c4s]

JPG is designed for real life images, not text. Your results don't surprise me. You should be using PNG for text.

Professional photographers won't like what you say here...

[ts-soft]

Professional photographers doesn't use JPEG, only WebDesigner

[MachineCode]

Professional photographers won't like what you say here...

Hey, I'm just going by what JPEG was designed for. Have a look:

The JPEG compression algorithm is at its best on photographs and paintings of realistic scenes with smooth variations of tone and color. On the other hand, JPEG may not be as well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images may be better saved in a lossless graphics format such as TIFF, GIF, PNG, or a raw image format.

JPEG is best suited for large photographic images where file size is the most important consideration, such as images that will be posted on the Web or transmitted via email and FTP. JPEG is not suitable for most small images under a few hundred pixels in dimension, and it is not suitable for screen shots, images with text, images with sharp lines and large blocks of color, and images that will be edited repeatedly.

works well on photographs, naturalistic artwork, and similar material; not so well on lettering, simple cartoons, or black-and-white line drawings

It's an industry standard that JPEG is not meant for text, so why complain about the quality when used with text? Use the right tool for the job.

[luis]

It's an industry standard that JPEG is not meant for text, so why complain about the quality when used with text? Use the right tool for the job.

All this is irrelevant when saving the test image to jpg in other software don't exhibit the above mentioned problem.

Moreover what you call text is a pattern of pixels of a certain color. The problem can manifest itself with any kind of images. For example a photographic image of a beautiful sunset with a road sign in the image. Probably what we need it's a flag to simply disable color subsampling.