Investigate using ARM NEON instructions to speed up image processing about scan2drive

[stapelberg]

https://github.com/libjpeg-turbo/libjpeg-turbo uses NEON on ARM, so that part seems to be feasible.

I’ll need to profile the g3 compression to see how to make it faster.

[stapelberg]

Commit 2f7d475 brings down the rotation + g3 compression to 5s on the Raspberry Pi 3. The longest step now definitely is the JPEG encoding.

[stapelberg]

I got a proof-of-concept which uses a port of libjpeg-turbo’s NEON assembler functions. It completes JPEG encoding within 2.5s of wall-clock time.

I’ll look into whether we can run the processing in parallel to reading data from the scanner. That way, we might be able to pull off scanning in almost real-time, i.e. with minimal wait after each page :).

[stapelberg]

Next steps for cleaning up the optimized JPEG encoder (scan2drive/internal/neonjpeg):

• create separate git repository (for the cleanup only)
• remove magic numbers
• add assertions about image/buffer size
• remove comments
• clean up assembler files (indentation, attribution)

[stapelberg]

This is the current processing time for each piece of paper after scanning finished:

• 1s JPEG encoding (most of the processing happens in parallel with scanning)
• 3s G3 encoding
• 12s thumbnail PNG encoding

I looked into encoding the G3-encoded image data into a TIFF file (which works), but it turns out that neither Chrome nor Firefox support TIFF. All javascript-based TIFF/PDF viewers and extensions are super slow.

[stapelberg]

Created issue #15 for speeding up the thumbnail creation. Closing this issue as we’re now using NEON code for jpeg compression.