XnView Software

mozjpeg 3.0 shows a better quality on saving JPEG files, so please consider using it!
http://calendar.perfplanet.com/2014/mozjpeg-3-0/

Yes, it would be awesome!

https://boomswaggerboom.wordpress.com/2 ... -released/

+1

I'd really love this too

o-l-a-v wrote:I'd really love this too

It's an idea, I'm guilty of creating a mozjpeg gallery on WikiMedia Commons, because I missed the fine print, that a better name would be Xiph.org Daala image test suite, mostly proving that BPG is in fact better. And I like their five built-in quant-tables, because whatever it is, at least they reduced it to five interesting cases. XnView could offer this as option in its UI. The libjpeg turbo folks and the mozjpeg folks apparently get along.

Unlike those wannabe- official libjpeg folks, who apparently break backwards compatibility in some kind of war against JPEG2000, JXR, ISO, etc. Their war might be justified, but breaking compatibility is not, and as long as XnView + MediaWiki + many others (excl. FFmpeg) cannot handle SignedShortLosslessBug.jpg they didn't hear the shot about "standards".

*poke*

Anything? It's a drop-in replacement for libjpeg-turbo, better quality, same license. This is a no-brainer for classic and MP alike.

foxyshadis wrote:*poke*

Anything? It's a drop-in replacement for libjpeg-turbo, better quality, same license. This is a no-brainer for classic and MP alike.

do you know if mozjpeg use SSE3 like jpeg-turbo?

xnview wrote:

foxyshadis wrote:*poke*

Anything? It's a drop-in replacement for libjpeg-turbo, better quality, same license. This is a no-brainer for classic and MP alike.

do you know if mozjpeg use SSE3 like jpeg-turbo?

There is no simd minimum. It includes mmx, sse, sse2, altivec, etc, and will use whatever your processor supports. The build will work with whatever minimum CPU you set the compiler to. (-march 386 should even work.)

from mozjpeg

'mozjpeg' is not intended to be a general JPEG library replacement.
It makes tradeoffs that are intended to benefit Web use cases and
focuses solely on improving encoding. It is best used as part of
a Web encoding workflow. For a general JPEG library (e.g. your
system libjpeg), especially if you care about decoding, we recommend
libjpeg-turbo.

Is that a reason not to add support for it?
I use xnconvert for images I use on web too. Would not be a bad move to have both the standard jpeg, plus mozjpeg support as I see it
Web-encoders' (https://imageoptim.com/mozjpeg , http://mozjpeg.codelove.de/) result of conversion looks promising, so I'd probably use mozjpeg for various other scenarios too. Like album art for my portable lossy music collection for instance

i'll try to add it as a plugin

Whoops, missed this. JPEG export and default saving should use mozjpeg, decoding could stick with libjpeg-turbo -- but I bet scaling takes 2-10x as long as decoding anyway. Either way, mozjpeg always saves higher quality than libjpeg and libjpeg-turbo; even if it's a little slower than turbo, I can't think of any reason someone would need realtime writing with xnview (like recording to mjpeg), to make it worth relegating to just a plugin.

Any news regarding mozjpeg and XnConvert/XnView?

XnView is a viewer that also happens to have some editing capabilities. I see no reason wasting limited resource (1 dev) adding every jpg lib under the sun because someone pixel peeping at 200% sees a benefit in saving 2kb.

Because libs like this are like sands on the beach. If you want you can make a plugin and use it yourself.

Yes, jpg is 30+ years old, any 'quality' improvements is the same as saving a few kb here and there.