> -1.
>
> mozjpeg offers slightly improved compression at the cost of up to
> x10 increase in compression time (*). It may be something to
> consider later if they manage to improve the speed although they
> expect that it will always remain slower than libjpeg-turbo.
As I quoted befo
> I don't see any point in forking here.
It's not just a one off patch, they are planning additional features and
improvements (some of which are listed on the issue tracker). Also being
on github lowers the barrier for contributions. So I think forking is
understandable.
> > https://aur.archlinux.org/packages/mozjpeg/
>
> When you take the existing libjpeg-turbo PKGBUILD, change a few lines,
> and remove the Contributor/Maintainer tags altogether, you're not
> showing much respect for the community.
Apologies, that was not my intentions (this has be corrected).
Am 08.03.2014 04:32, schrieb N30N:
> Hi there,
>
> Mozilla have made a fork of the libjpeg-turbo package called mozjpeg,
> which features improved encoding:
> https://blog.mozilla.org/research/2014/03/05/introducing-the-mozjpeg-project/
>
> I'd like to propose making the switch. The "library conf
N30N wrote:
> Hi there,
>
> Mozilla have made a fork of the libjpeg-turbo package called mozjpeg,
> which features improved encoding:
> https://blog.mozilla.org/research/2014/03/05/introducing-the-mozjpeg-project/
>
> I'd like to propose making the switch. The "library configuration
> defaults ar
[2014-03-08 04:32:28 +0100] N30N:
> https://aur.archlinux.org/packages/mozjpeg/
When you take the existing libjpeg-turbo PKGBUILD, change a few lines,
and remove the Contributor/Maintainer tags altogether, you're not
showing much respect for the community.
> I'd like to propose making the switch.
6 matches
Mail list logo
