Request for Implementing JPEGLI Encoder with Lanczos3 Resampling for Cover Art Rescaling

I am writing to propose an enhancement to MusicBrainz’s cover art rescaling process. The introduction of the JPEGLI encoder, combined with Lanczos3 resampling and a 4:2:2 color subsampling at a quality setting of 75-80, offers substantial benefits. This enhancement will result in higher-quality images with smaller file sizes, maintaining backward compatibility with existing JPEG standards. This request aims to improve the user experience, especially for those utilizing the MusicBrainz Picard app.


1. Higher Quality with Smaller Sizes:

  • JPEGLI provides a 35% improvement in compression ratios at high quality settings compared to traditional JPEG encoders. This means users can achieve the same image quality at significantly reduced file sizes.
  • For example, a 1200px cover art image currently sized at 300 KB can be reduced to around 150 KB using JPEGLI, preserving quality while saving space.

2. Backward Compatibility:

  • JPEGLI is fully compatible with the original JPEG standards, ensuring that the newly encoded images can be read by all existing JPEG viewers and applications without any issues.

3. Enhanced User Experience in MusicBrainz Picard:

  • Embedding cover art into music files often results in increased file sizes. By using JPEGLI, users can embed high-quality cover art into their music files without significantly increasing the overall file size. This is particularly beneficial for users who convert FLAC files to smaller formats like Opus.

Technical Details:

  • Encoder: JPEGLI (libjxl/lib/jpegli at main · libjxl/libjxl · GitHub)

  • API and ABI compatible with libjpeg62.

  • Support for 16-bit unsigned and 32-bit floating point input buffers.

  • Advanced color space conversions and chroma subsampling performed in floating point precision.

  • Adaptive dead-zone quantization for better handling of noisy image parts.

  • Efficient compression of images with ICC profiles in XYB color space.

  • Resampling Algorithm: Lanczos3

  • Offers superior image quality compared to simpler algorithms like bilinear or nearest-neighbor interpolation.

  • The non-separable approach should be considered for its higher image quality despite its higher computational demands.

Space Savings Calculation Example:

  • Consider 100 music files, each 3 MB in size, with a 300 KB cover art image.
  • Total space for cover art: 100 files * 300 KB = 30,000 KB (29.30 MB).
  • With JPEGLI, the cover art size reduces to 150 KB.
  • New total space for cover art: 100 files * 150 KB = 15,000 KB (14.65 MB).
  • Space saved: 30,000 KB - 15,000 KB = 15,000 KB (14.65 MB).

Implementing JPEGLI with Lanczos3 resampling and 4:2:2 color subsampling at a 75-80 quality setting will significantly improve the quality and efficiency of cover art images in MusicBrainz. This will enhance the user experience, particularly for users of the MusicBrainz Picard app, by providing higher quality images at reduced file sizes while maintaining compatibility with existing JPEG standards.

You can test the new encoder with XnView or XL Converter

For some reason you posted this in the MusicBrainz discourse category rather than the MusicBrainz Picard category so it won’t get as much visibility amongst the Picard community as it otherwise might. I don’t know if anyone could move this to the correct category?

As for the proposal, I have no real view about its merits except to say:

  1. The lib for encoding will need to be available with a python binding. Fortunately there is one here however it is in Alpha status and implementation is not complete - which IMO means it is not ready for inclusion in Picard.

  2. It would need to be available for all platforms Picard is supported on - and at present jxlpy’s support for Windows is only partial and a bit manual.

  3. Because it is going to need a new library, this will need to be built into the executable installer builds - so this would need to be a Picard enhancement rather than a plugin.

  4. Using this compression would need to be a user choice in case there is some incompatibility with their player, so there would need to be a UI option to use it or not.

That said, I think that it would be beneficial to create a prototype PR / branch that could be used to evaluate this functionality when run from source (and that can be merged once the library is sufficiently mature) and I would encourage @David_Osipov to create this.

Thank you, I’ve moved it. The server also conducts resizing of cover arts, that’s why it’s kind of tricky. I’m not a dev so not really code with writing code for this functionality.

I think they are talking about using this for the thumbnails created by the Cover Art Archive.


I moved this to the MB Development category.


It seems that way now, but this originally had “[MusicBrainz Picard]” in the subject line.

The thumbnails for the CAA are created by the Internet Archive and we have nothing to do with the process, so there’s nothing we can change there.


@Bitmap: Do you know how to forward this feature request upstream?

1 Like

Sure, I forwarded the suggestion along. But ultimately it’s their decision what encoder to use and what their development priorities are.


Thank you! Should I close this feature request than? I think it’s useless leaving it here opened.

No need to close the thread I don’t think, it’s not a Jira ticket. :slight_smile:

To summarize the response I got: the IA generally only sticks to tooling available from the default OS packages for Ubuntu (though they may switch to Debian?), and they also tend to lag behind on which OS release they use.

So, unfortunately, it seems unlikely that this will be considered at least until a few years after Jpegli is packaged by Debian.


That’s unfortunate and we can’t do anything about it :frowning: Thank you everyone for valuable inputs!

1 Like

That said, it could still be a future enhancement for Picard.