1
\$\begingroup\$

I am currently using an STM32F4xx and extracting an already compressed JPEG from a camera module OV5645 as that particular sensor has an internal JPEG codec. I want to starting using a new sensor, OV8865, that does not come with the internal codec and I wonder if it is feasible to use a STM32 MCU in order to extract the RAW RGB and encode it into a JPEG getting at least 2 frames per second. I can't use the Digital camera interface (DCMI) for STM32 MCUs built into the STM32F4 as the maximum input size is 2048 × 2048 pixels and I'd like to use at least the resolution of 2816 x 1584 pixels the sensor offers (although 3264 x 2448 would be better).

Is there any estimation on how long it would take to a Cortex M4 such as STM32F4xx to encode a 2816 x 1584 or a full 8MP image (3264 x 2448).

I wonder if a MCU is enough for 2 fps.

Do you know any comercial IC that encodes RAW RGB into JPEG? I guess I could design an FPGA but it will be out of the scope of the scale of the project.

\$\endgroup\$
1
  • \$\begingroup\$ I think there is no hope for normal jpeg, since x86 CPU cores often don't do more than 50-100 MP/s. However, you could try stripping jpeg to a minimum (no YCbCr, trivial huffman coding, etc which I believe are technically allowed) and see how fast you can get it if you don't mind very poor compression. \$\endgroup\$ – user1850479 Apr 26 at 4:40
2
\$\begingroup\$

I wonder if a MCU is enough for 2 fps.

STM32F7/H7 has a hardware jpeg compression peripheral that only takes 4 ms to compress a 640x480 image. However converting the image from RGB to the required YCbCr format takes ~60 ms at 400 MHz, equating to a total time of ~900 ms for converting 2816x1584. I expect an STM32F4 with encoding done purely in software would be much slower.

Do you know any comercial IC that encodes RAW RGB into JPEG? I guess I could design an FPGA but it will be out of the scope of the scale of the project.

I couldn't find any chips designed to do your specific format, but I did find several FPGA encoder cores. Here's one that claims 7.3 ms processing time for 640x480 with a 100 MHz clock, which equates to ~100 ms at 2816x1584.

\$\endgroup\$
0
\$\begingroup\$

Some time ago I tested a grayscale jpeg software encoder on a NXP LPC2388 and then on an LPC1778 both running at 48 MHz.

The CMOS camera was Omnivision OV7676 (0.3 Megapixel 640×480).

I used chrominance samples only, that is Y, because as said I tested a gray scale software encoder.

I was able to get a frame rate of 2 fps on LPC2388 an 5 fps on LPC1778.


The main problems I got were:

  1. Shortage of memory

I wasn't able to store in RAM an entire frame because I had 64 kbytes only. So I had to store the whole frame in an external flash memory and then encode it.

  1. I didn't have floating point unit

The algorithm was very slow because JPEG encoding has a lot of multiplications inside.

To speed up operations, I modified the algorithm in order to use integer arithmetic.

It worked well without any appreciable quality loss.

The file size though increased by 10% at least because some internal predefined matrix coefficients were calculated 30 years ago by the JPEG consortium, using floating point multiplications.


Later in the afternoon I will post here the Github repo of that software encoder because I don't have it handy.


I modified the algorithm using Microsoft Visual Studio because it's really fast and then tested it on the 2 embedded platforms.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.