A Virtual Home

Memory problems with MozJPEG and Pillow

2018-08-19T15:08:00-04:00

We implemented MozJPEG to be used with Pillow 4.x to create smaller thumbnails of files uploaded by users, when we noticed that sometimes this process did not work. We looked into our logs and noticed the following error message I/O suspension not supported in scan optimization. Time to enter the GSO workflow, GSO stands for Google Stack Overflow, in other words search the Internet. The error message results in links to the source code of MozJPEG, not very helpful at first.

Time to brush up on my C knowledge, OK I never programmed in C but that doesn’t stop me from going through the source.

The error message is defined in jerror.h

#endif
JMESSAGE(JERR_BAD_PARAM, "Bogus parameter")
JMESSAGE(JERR_BAD_PARAM_VALUE, "Bogus parameter value")
JMESSAGE(JERR_UNSUPPORTED_SUSPEND, "I/O suspension not supported in scan optimization")

#ifdef JMAKE_ENUM_LIST

So now we have to find the JERR_UNSUPPORTED_SUSPEND constant. Luckily it appears only in one file, jcmaster.c

while (size >= cinfo->dest->free_in_buffer)
  {
    MEMCOPY(cinfo->dest->next_output_byte, src, cinfo->dest->free_in_buffer);
    src += cinfo->dest->free_in_buffer;
    size -= cinfo->dest->free_in_buffer;
    cinfo->dest->next_output_byte += cinfo->dest->free_in_buffer;
    cinfo->dest->free_in_buffer = 0;

    if (!(*cinfo->dest->empty_output_buffer)(cinfo))
      ERREXIT(cinfo, JERR_UNSUPPORTED_SUSPEND);
  }

Cool, it seems to be related to memory cleanup, just my guess because of the empty_output_buffer line. Now we have to find out where Pillow sets the buffersize for saving an JPEG image.

The file PIL/JpegImagePlugin.py is used for all functions related to a JPEG image, and this includes saving.

The whole save method is a bit large to post here, but the part below determines the buffer size and it’s used to save the image. The buffer size is set to be holding the entire image file.

bufsize = 0
if optimize or progressive:
    # CMYK can be bigger
    if im.mode == 'CMYK':
        bufsize = 4 * im.size[0] * im.size[1]
    # keep sets quality to 0, but the actual value may be high.
    elif quality >= 95 or quality == 0:
        bufsize = 2 * im.size[0] * im.size[1]
    else:
        bufsize = im.size[0] * im.size[1]

# The exif info needs to be written as one block, + APP1, + one spare byte.
# Ensure that our buffer is big enough. Same with the icc_profile block.
bufsize = max(ImageFile.MAXBLOCK, bufsize, len(info.get("exif", b"")) + 5,
            len(extra) + 1)

ImageFile._save(im, fp, [("jpeg", (0, 0)+im.size, 0, rawmode)], bufsize)

I don’t want to change the Pillow source itself cause of potential issues whenever we upgrade Pillow in the future. So the best thing I can do is modify the ImageFile.MAXBLOCK, not that big of deal I think.

I came up with the following solution

new_maxblock = 3 * image.size[0] * image.size[1],  # ...3 bytes per every pixel in the image
old_maxblock = ImageFile.MAXBLOCK
if new_maxblock > ImageFile.MAXBLOCK:
    ImageFile.MAXBLOCK = new_maxblock
requested_size = (int(width), int(height))
image.thumbnail(requested_size, Image.ANTIALIAS)
image.save(thumb_file, "JPEG", progressive=True,)
ImageFile.MAXBLOCK = old_maxblock

We determine a new max block size, as most JPEG files are 24bits color (RGB), we need 3 bytes per pixel. This might be overkill in certain situations but at times I prefer overkill over not having having the thumbnail.

After implementing the above solution the I/O suspension not supported in scan optimization error message has not been seen in the logs.

Replace JPEG libraries with MozJPEG

2018-03-28T09:03:00-04:00

For an image heavy site we were building we needed to squeeze more bytes out of the JPEG files. We use Pillow within our Python project to create thumbnails which in turn uses the JPEG libraries installed on your system, so we had to look for a 1-on-1 replacement of the system jpeg libraries.

For Ubuntu you can use libjpeg-turbo but using MozJPEG by Mozilla makes the thumbnails even smaller. The only problem we ran into was the fact there is no repository you can add in Ubuntu and therefore we had to compile MozJPEG manually.

If you just want to skip the steps go to tl;dr. All the steps need to be ran as root.

Install requirements

To compile MozJPEG you need to install some requirements.

apt -y install build-essential cmake libtool autoconf automake m4 nasm pkg-config

and then configure the dynamic linker run-time bindings

ldconfig /usr/lib

Get MozJPEG source

We’ll be working with version 3.2 of the MozJPEG library.

wget https://github.com/mozilla/mozjpeg/archive/v3.2.tar.gz
tar xf v3.2.tar.gz

Configure and Install

Before we can configure and install we have to create the configuration. Go to the directory you extract the archive in.

cd mozjpeg-3.2
autoreconf -fiv

To keep source and build separate we’ll do the build in it’s own directory.

mkdir build
cd build
sh ../configure --with-jpeg8
make install libdir=/usr/lib/x86_64-linux-gnu prefix=/usr

We have to copy one source file over as it’s not included in the build.

cp ../jpegint.h /usr/include/jpegint.h

That’s it, now almost any program on your server that use the JPEG libraries to create images will be using MozJPEG and making the files much smaller than with the standard or even libjpeg-turbo libraries.

TL;DR

The script below will do all the above steps. Remember to run this as root.

#/bin/sh
apt -y install build-essential cmake libtool autoconf automake m4 nasm pkg-config
ldconfig /usr/lib
rm -rf mozjpeg-3.2
wget https://github.com/mozilla/mozjpeg/archive/v3.2.tar.gz
tar xf v3.2.tar.gz
cd mozjpeg-3.2
autoreconf -fiv
mkdir build
cd build
sh ../configure --with-jpeg8
make install libdir=/usr/lib/x86_64-linux-gnu prefix=/usr
cp ../jpegint.h /usr/include/jpegint.h

Bonus

If you use Pillow in your Python project and it was already installed you need to reinstall it, we ran into issues where after reinstalling it still would not use the MozJPEG libraries. In order to make that work, we had to recompile Pillow. The code below will recompile pillow

pip install --upgrade --no-cache-dir --force-reinstall --no-binary :all: --compile -v Pillow

Create a custom 410 error page in NGINX

2018-03-23T08:03:00-04:00

When converting this blog from WordPress to Pelican I decided I just ditch a whole bunch of articles I had written in WordPress. According to several articles on the net it is best practice to have pages you delete return a 410 page. For a better user experience I wanted used to land on a page that looks like part of the blog.

As I’m using NGINX you can utilize the map function to create a new variable whose value depends on values of one or more of the source variables specified in the first parameter. I created a file called old_request.nginx in the directory /etc/nginx/snippets/

map $request_uri $gone_var {
  /the-avh-amazon-plugin-has-reached-its-end-of-life/ 1;
  /wordpress-plugin-update-avh-first-defense-against-spam-v3-0/ 1;
  /end-of-the-avh-amazon-plugin/ 1;
  /wordpress-plugin-update-avh-extended-categories/ 1;
}

This file just needs to be included in your configuration file, and if you want to have a custom 410 error page you just have to tell NGINX which file to use when it encounters a 410 error.

include snippets/old_request.nginx;

server {
    ....

    error_page 404 /404.html;
    error_page 410 /410.html;

    if ($gone_var) {
        return 410;
    }

    location / {
        ....
    }
}

Easy enough, NOT. The above configuration does not work. If you try to browse one of the URLs mentioned in the the old_request.nginx file you get the default NGINX 410 error page and not the file you said it should show.

To fix this we have to use a named location. A named location has the @ prefix. Such a location is not used for a regular request processing, but instead used for request redirection.

include snippets/old_request.nginx;

server {
    ....

    error_page 404 /404.html;
    error_page 410 @gone;

    if ($gone_var) {
        return 410;
    }

    location @gone {
        rewrite ^(.*)$ /410.html break;
    }

    location / {
        ....
    }
}

And now your custom 410 error page works.

Move from WordPress to Pelican

2018-03-11T22:15:24-04:00

I have been playing with the thought of moving my blog from WordPress to a static website generator for years.

I never really had the energy to start this projects, for several reasons. I know I could never find a theme that is completely to my liking so I would have to change it, possibly altering some code. There were some generator written in PHP, my language of choice for a long time, but they seemed not very mature. The best known static web site generator was Jekyll, written in Ruby and I really couldn’t get the energy to start learning Ruby on the side. The other reason that was keeping me from moving was how to move all my articles from WordPress to the static generator.

I started working for ONeil Interactive in 2017. We build websites for the home building industry and the language of choice is Python. We started looking into building an internal site for documenting our projects. We develop in Python and it was quickly decided the static generator should be written in Python as it would make it easier to extend the generator if needed.

As a result of this project I decided to bite the bullet for my personal site as well. After a quick look at the site StaticGen and some quick research I decided to go with Pelican. Of course I needed a theme, and there is never a theme that completely satisfies my needs but my starter theme is Plumage by Kevin Deldycke. I’ve modified it to work with Bootstrap 4, and used the Slate theme by Bootswatch.

I only moved two articles from my old blog as the rest of the articles were not visited that often. I still have them in the database so if it’s ever needed I can pull them up.

Oh in case you were wondering, for the project at work we decided to go with MkDocs