Skip to content

Conversation

vmstan
Copy link
Contributor

@vmstan vmstan commented Jun 5, 2024

Extraction of libvips only components from from #30569

This preserves all of the benefits of compiling libvips individually (Controlled version adoption & Optimized library selection) however Docker image size remains at around 1GB due to inclusion of X11 as required by ffmpeg still being loaded by Debian repos.

  • Removal of ImageMagick: When installed from the Debian repos as libvips42, ImageMagick core is also installed as a fallback for some image formats, when the ultimate goal of Add support for libvips in addition to ImageMagick #30090 is to ultimately remove IM from the codebase entirely for all the reasons why Vips is superior.
  • Controlled version adoption: Vips should be considered as essential as Ruby, Node, Postgres, or any other Mastodon dependency given the importance of image processing. The Debian repos are notoriously slow in adoption of upgrades.
  • Optimized library selection: Compiling these packages from source allows us to use only the libraries that are necessary for Mastodon. For example there is no support included for things like PDF, JXL, JPEG2000, NIfTI, FITS, Matlab, or SVG. Not only is this more size efficient as noted above, it could be considered more secure by lowering the attack surface of the container through removal of unnecessary components but ultimately it is to allow more granular control where there are multiple choices, especially for Vips as further noted below.

Vips compile/library settings

  • Versions can be controlled in a similar method as Ruby/Node through Docker build arguments, to enable easier local testing and customized version deployments. [--build-arg VIPS_VERSION="8.15.2"]
  • Source code is downloaded directly from GitHub and includes a sha256 hash check as part of the process to insure package integrity.
  • Building deprecated components is disabled, building example programs is disabled, building GObject introspection is disabled, building dynamic modules is disabled. (Full list of libvips build options https://github.com/libvips/libvips/blob/master/meson_options.txt)
  • libjpeg-turbo is used for JPEG processing which is 2-6x faster than standard libjpeg. Another option would be to use mozjpeg but this library is not available in Debian and would required another direct compilation.
  • cgif is used for GIF processing, which if not present would require Vips to fallback to ImageMagick.
  • libspng is used for PNG processing, which is similarly more performant than the standard libpng package.
  • libwebp is used for WebP processing.
  • libheif is used for processing HEIC/HEIF images.
  • orc-0.4 is used for some SIMD operations instead of highway due to the Debian repos not containing a version that is suitable for libvips but this could either be compiled directly or evaluated later if Debian packages are updated.
  • libimagequant is used for libvips to write 8-bit PNG and GIF files, with an alternative being quantizr that is not available in Debian repos but could be built directly.
$ vips --vips-config
enable debug: false
enable deprecated: false
enable modules: false
enable cplusplus: true
enable RAD load/save: true
enable Analyze7 load/save: true
enable PPM load/save: true
enable GIF load: true
use fftw for FFTs: false
SIMD support with highway: false
accelerate loops with ORC: true
ICC profile support with lcms: true
zlib: true
text rendering with pangocairo: false
font file support with fontconfig: false
EXIF metadata support with libexif: true
JPEG load/save with libjpeg: true
JXL load/save with libjxl: false (dynamic module: false)
JPEG2000 load/save with OpenJPEG: false
PNG load/save with libspng: true
PNG load/save with libpng: false
selected quantisation package: imagequant
TIFF load/save with libtiff: true
image pyramid save with libarchive: false
HEIC/AVIF load/save with libheif: true (dynamic module: false)
WebP load/save with libwebp: true
PDF load with PDFium: false
PDF load with poppler-glib: false (dynamic module: false)
SVG load with librsvg: false
EXR load with OpenEXR: false
OpenSlide load: false (dynamic module: false)
Matlab load with libmatio: false
NIfTI load/save with niftiio: false
FITS load/save with cfitsio: false
GIF save with cgif: true
selected Magick package: none (dynamic module: false)
Magick API version: none
Magick load: false
Magick save: false

@shleeable
Copy link
Contributor

shleeable commented Jun 6, 2024

Testing this now.

Update: So far so good.

Copy link
Contributor

@ClearlyClaire ClearlyClaire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, having a more up-to-date version with fewer modules we don't use is certainly appealing.

However, there are two things I'm a little wary about:

  • this adds some overhead in updating libvips, e.g. to keep up with security patches
  • this will likely increase image build time, especially on ARM

@vmstan
Copy link
Contributor Author

vmstan commented Jun 6, 2024

This looks good, having a more up-to-date version with fewer modules we don't use is certainly appealing.

However, there are two things I'm a little wary about:

  • this adds some overhead in updating libvips, e.g. to keep up with security patches
  • this will likely increase image build time, especially on ARM

The libvips compile usually adds about 12 seconds to the image build time in my testing. ARM uses the native builder in the GitHub workflow now so it shouldn't be any different?

I just looked at the test build in GitHub actions and it showed the process took 48 seconds there.

@renchap renchap added the docker label Jun 6, 2024
@renchap
Copy link
Member

renchap commented Jun 6, 2024

  • this adds some overhead in updating libvips, e.g. to keep up with security patches

We should be able to have Renovate open PRs for libvips bumps using a custom config: https://docs.renovatebot.com/modules/manager/regex/

@shleeable
Copy link
Contributor

  • this adds some overhead in updating libvips, e.g. to keep up with security patches

We should be able to have Renovate open PRs for libvips bumps using a custom config: https://docs.renovatebot.com/modules/manager/regex/

TBH This kind of housekeeping is generally handled by the non-ruby technical people like myself.

@vmstan
Copy link
Contributor Author

vmstan commented Jun 7, 2024

When paired with #30602 the libvips version will be monitored by Renovate

CleanShot 2024-06-07 at 12 05 45@2x

Copy link
Member

@renchap renchap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! @ClearlyClaire do you want to have a look as well?

@vmstan vmstan requested a review from ClearlyClaire June 12, 2024 13:20
@renchap renchap added this pull request to the merge queue Jun 13, 2024
Merged via the queue into mastodon:main with commit 179f7b1 Jun 13, 2024
@vmstan vmstan deleted the build-libvips branch June 13, 2024 16:27
nomad-geek pushed a commit to dftba-club/mastodon that referenced this pull request Jul 3, 2024
justinwritescode pushed a commit to justinwritescode/mastodon that referenced this pull request Sep 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants