Project

General

Profile

Feature #11666

Integrate MozJPEG encoder (to produce more efficiently coded JPEG files)

Added by Sarge Borsch about 1 year ago. Updated about 1 month ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
07/08/2017
Due date:
% Done:

0%

Affected Version:
2.2.5
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

https://github.com/mozilla/mozjpeg
It seems to use licenses all compatible with GPL.

It's compatible with libjpeg API and ABI, and can be used as a drop-in replacement for libjpeg

History

#1 Updated by Roman Lebedev about 1 year ago

Sarge Borsch wrote:

https://github.com/mozilla/mozjpeg
It seems to use licenses all compatible with GPL.

It's compatible with libjpeg API and ABI, and can be used as a drop-in replacement for libjpeg

Sounds like a distro problem then.

#2 Updated by Sarge Borsch about 1 year ago

Roman Lebedev wrote:

Sounds like a distro problem then.

What does it mean?

#3 Updated by Roman Lebedev about 1 year ago

Sarge Borsch wrote:

Roman Lebedev wrote:

Sounds like a distro problem then.

What does it mean?

It's compatible with libjpeg API and ABI, and can be used as a drop-in replacement for libjpeg

^ so distributions can decide to build with MozJPEG instead of libjpeg / libjpeg-turbo, without any changes to the software

#4 Updated by Sergei Datsenko about 1 month ago

Mozjpeg is highly-biased towards producing optimized JPEGs at the expense of high CPU usage during compression, so distributions will never switch to it as a default implementation. But for photoeditors that's would be a better option because producing the best possible JPEG is one of the main goals, right? Also, some optimizations are available only if one uses extended part of the API that goes beyond libjpeg-compatible subset.

Of course ideally libjpeg and mozjpeg would merge and just provide "mode options", but this don't seem to ever happen, mostly because of human nature.

#5 Updated by Roman Lebedev about 1 month ago

Sergei Datsenko wrote:

Mozjpeg is highly-biased towards producing optimized JPEGs at the expense of high CPU usage during compression, so distributions will never switch to it as a default implementation. But for photoeditors that's would be a better option because producing the best possible JPEG is one of the main goals, right? Also, some optimizations are available only if one uses extended part of the API that goes beyond libjpeg-compatible subset.

Of course ideally libjpeg and mozjpeg would merge and just provide "mode options", but this don't seem to ever happen, mostly because of human nature.

I'd start by at least packaging it in the distributions.
Even debian does not have it.
And it does not looks like they want to have it packaged.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741487

Also available in: Atom PDF