Package Details: mozjpeg 4.1.5-1

Git Clone URL: https://aur.archlinux.org/mozjpeg.git (read-only, click to copy)
Package Base: mozjpeg
Description: Improved JPEG encoder
Upstream URL: https://github.com/mozilla/mozjpeg
Keywords: c cmake encoder jpeg make mozilla
Licenses: zlib, IJG, BSD-3-Clause-Modification
Conflicts: libjpeg, libjpeg-turbo, mozjpeg-git, turbojpeg
Provides: libjpeg, libjpeg-turbo, libjpeg.so, turbojpeg
Submitter: afontenot
Maintainer: begin-theadventu
Last Packager: begin-theadventu
Votes: 30
Popularity: 0.196525
First Submitted: 2015-08-14 12:26 (UTC)
Last Updated: 2024-04-18 10:57 (UTC)

Dependencies (3)

Required by (1041)

Sources (1)

Pinned Comments

afontenot commented on 2024-04-18 04:00 (UTC)

Hi all,

I'm disowning this package for the following reasons:

  • The project is basically dead, no commits in 6 months.
  • The project maintainer hasn't rebased it on libjpeg-turbo 3.0, making this package basically useless because it's designed to replace the system's dynamically linked libjpeg: https://github.com/mozilla/mozjpeg/issues/437
  • A new JPEG encoder called JPEGLI is released and basically eats Mozjpeg's lunch on every single image I've tested. It's much superior. I strongly recommend anyone who needs a JPEG encoder to switch to this; an encoder cjpegli is included in the libjxl package in extra.

Unfortuantely, jpegli is not (yet) a drop-in replacement for libjpeg, because it is also based on the 2.0 version of libjpeg-turbo.

For comparisons between JPEGLI and MozJPEG (and other codecs), please check https://afontenot.github.io/image-formats-comparison/#sunset&JPEGLI=l&MOZJPEG=l

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

MarsSeed commented on 2022-03-09 13:01 (UTC)

@afontenot Thanks for the update and for enabling tests! For me they are very fast and all of them passes.

afontenot commented on 2022-03-09 01:20 (UTC)

@MarsSeed that's irritating, I didn't realize the AUR DB worked like that. I try very hard to avoid forcing pointless rebuilds with a pkgrel bump, but that would have been appropriate here. I'll do that.

MarsSeed commented on 2022-02-11 14:36 (UTC)

@afontenot Thanks for the change! Please also bump to pkgrel=2, as AUR hasn't refreshed the package metadata in its DB, so AUR helpers can't make use of the new provides information during dependency resolution.

afontenot commented on 2022-02-10 17:59 (UTC)

@MarsSeed Done; I think other packages that explicitly depend on a version when they actually don't need it are broken, but if it eases compatibility I guess its fine.

MarsSeed commented on 2022-02-10 12:55 (UTC)

Please kindly declare explicitly:

provides=(libjpeg.so=8-64)

Doing that will inform AUR helpers that look at that field and should prevent conflicts during installation/upgrade of this and Arch packages that hardcode depends=(libjpeg.so=8-64).

magicgoose commented on 2021-08-17 22:04 (UTC)

you can work around this by changing the provides to "libjpeg-turbo=2.1.0" in this PKGBUILD (or whatever the required version is when you read this).

Unfortunately this doesn't help anymore. I changed the line to

provides=("libjpeg" "libjpeg.so" "turbojpeg" "libjpeg-turbo=2.1.1")

and when I install, I get error:

error: failed to prepare transaction (could not satisfy dependencies)
:: removing libjpeg-turbo breaks dependency 'libjpeg-turbo=2.1.1' required by lib32-libjpeg-turbo

I remember it worked some time ago, so this must be because of some pacman change? (just a guess) Any ideas what to do with this?

afontenot commented on 2021-05-20 10:48 (UTC) (edited on 2021-05-20 10:58 (UTC) by afontenot)

@juliusk: you can work around this by changing the provides to "libjpeg-turbo=2.1.0" in this PKGBUILD (or whatever the required version is when you read this).

I'm going to have to have a think (and possibly ask on the mailing list) about the best way to go here. The issue is that lib32-libjpeg-turbo is requiring a specific version of libjpeg-turbo. Several problems:

  1. I don't know if lib32-libjpeg-turbo actually needs a very specific version of the libjpeg-turbo library or not.

  2. I don't know if the version of libjpeg-turbo that the latest release of mozjpeg is based on is actually drop in compatible with the specific version of libjpeg-turbo requested. Unfortunately mozjpeg doesn't get updated very often. Promising users that it's compatible by changing the PKGBUILD seems risky.

  3. This is probably a moving target, since any time anything bumps the version requirement for libjpeg-turbo I'd have to update the PKGBUILD. In light of 1 and 2 I don't know that that's advisable.

Quick edit: now that I think about it, it seems like the solution might be removing lib32-libjpeg-turbo and using lib32-mozjpeg instead. That's not my package so I'm not sure why it might not work, but I'll try to have a look at that too.

juliusk commented on 2021-01-15 10:12 (UTC)

The install fails for me:

error: failed to prepare transaction (could not satisfy dependencies)
:: removing libjpeg-turbo breaks dependency 'libjpeg-turbo=2.0.6' required by lib32-libjpeg-turbo

afontenot commented on 2020-11-25 23:19 (UTC)

@eschwartz: thank you as well! I was pretty sure about the libjpeg-turbo dependency being wrong (because it would prevent you from using certain drop-ins), but it looks like that's now been fixed in the mpv package.

« First ‹ Previous 1 2 3 4 Next › Last »