XnView Software

Turns out that if you try different filters in the export window, xnview's export function gets better results than pngout (not just this pngout plugin, but pngout in general).
Save as->52.3K
Pngout->46.8K
Export /w "sub" filter->40.2K
Most of the filters on the export screen get around 52K for this image, one was up to 60~something.
Looks like a slight improvement to xnview's export dialog would get better results than continuing work on this pngout plugin, just add an option to have xnview try all filters & use the one with the smallest size. (Which would also be faster than pngout.)
{Note: The above uses a truecolor image.}

With a 256 color image, pngout gets slightly better results. Both save as & export reate a file that is 24.9K, while pngout makes one that is 23.2K.

btw, There's a typo in the plugin. It says "the original image will be overwrited, continue?", it should say "overwritten".

Calvin Hass ([url=http://www.impulseadventure.com/photo/jpeg-color-space.html]JPEG Color Space Conversion Error[/url]) wrote:Any time that you convert an image from one color space to another, you are almost always guaranteed to introduce some error (image degradation) in the resulting output. This is because most images are defined in 8-bit precision per channel (24 bits/pixel), and if you output to a format that is also only 8-bit precision per channel with a floating-point conversion, you are going to have to perform some degree of rounding or truncation to end up at an 8-bit integer again.

This answers some of my questions, but I still don't understand why decompressing/converting the JPEG image to BMP format with XnView doesn't introduce that YCbCr-to-RGB roundoff error.

BMPs are truecolor, JPGs are truecolor, there is no color conversion taking place.
Now, BMPs -can- be indexed, but they only become so if -you- make them so. By default they are truecolor.

The same holds true for JPG->PNG conversion (if you don't use an optimizer like pngout). Open a JPG in Xnivew, then save it as a PNG (don't use export, don't use pngout, just save as).

It might just be the presence of an ICM profile, have you checked the image for one? The images I tested had no chroma residue.

Drahken: This is one of the conversion equations (there are a lot of variations, I don't recall which JPEG uses, this is rec. ITU BT.709):

Y = 0,7154 G + 0,0721 B + 0,2125 R
Cb = -0,386 G + 0,500 B -0,115 R
Cr = -0,454 G - 0,046 B + 0,500 R

Truncate all results to int. Then the reverse transform is applied when opening:

R = Y + 1.54(Cr - 128)
G = Y - 0.459(Cr - 128) - 0.183(Cb - 128)
B = Y + 1.816(Cb - 128)

Pick any given set of three values and run them through, see what kind of error you get. =p A good transform will have a half-bit of random dither, but practically none actually do. Unfortunately, there are various ways to speed up the conversion that can make it even more lossy, plus enough subtle variations in the equations that some softwares use the wrong one. Or just plain bugs, at least one got bluer with every re-save...

You won't see a difference on comparing the jpg to the saved png, because you can't compare different colorspaces, so the jpeg will be converted to RGB to compare. Of course, no differences, if it's all done with the same algorithm. =p

There's such a thing as YCbCr PNG and RGB jpeg but I've never seen either in the wild. (RGB jpeg-ls is popular in science though.)

(I wrote most of this before I did more testing and realized it didn't really apply to the problem, but I figured why let it go to waste, eh?)

Drahken wrote:Looks like a slight improvement to xnview's export dialog would get better results than continuing work on this pngout plugin, just add an option to have xnview try all filters & use the one with the smallest size. (Which would also be faster than pngout.)

That's what I was hoping this would be originally, it doesn't really make sense to me as it exists now. But as a test module until integration with export, it's fine.

• <-- Moderator's note: This post has been split off from “Catch O' The Day”. -->

Not a catch of the day, if I understand the purpose of this thread, but maybe a good catch for some XnView users, that does not need its own thread: Ken Silverman offers a new PNGOUT.EXE version 2015-02-13 . I can't tell what's new, apparently he gave up on maintaining change logs years ago.

omniplex wrote:Not a catch of the day, if I understand the purpose of this thread, but maybe a good catch for some XnView users, that does not need its own thread: Ken Silverman offers a new PNGOUT.EXE version 2015-02-13 . I can't tell what's new, apparently he gave up on maintaining change logs years ago.

Hello,
Nice tool, even available into linux ... I have made some tests, but for bigs png files it spend a lot of time to process.
**** for multple .png - Parallelized via ladon to use all CPUs # An other tool for .jpg - Re-compress JPEGs - Given the same visual perceived quality for a given image.
https://github.com/gunta/image-recompress
ex:

omniplex wrote:Ken Silverman offers a new PNGOUT.EXE version 2015-02-13 . I can't tell what's new, apparently he gave up on maintaining change logs years ago.

An export plugin-in (Filter » PNGOut) is already included in XnView-win-full.exe and XnView-win-full.zip.

• \XPNGout.ini
• \AddOn\pngout.exe (02/Jul/2011)
• \AddOn\PNGout.xnp
• \AddOn\PNGout.lng

It's also available as separate download.

You can even integrate pngout.exe into XnView's plug-in for RIOT as an external optimizer.

Related topics:

• PNGout
• PNGout
• PngOptimizer (Freeware)