Odd colors from SC101IOT

[dehne]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

I've been trying (unsuccessfully) to get the SC101IOT to take a useful photo using an ESP32S3 with PSRAM with ESP32-Cam. The basic "take picture example" works flawlessly, returning a frame buffer of the correct size (1843200 = 1280 * 720 * 2). That leads me to believe I've got much of the basics set up correctly.

I then modified the example to convert the contents of the frame buffer to a jpeg and store it on an SD card. This, too, works without error. But the captured photo is very strange. The scene is recognizable, but both the colors and the brightness are completely wrong. Here's an example. It's an image of the ceiling in my lab. The ceiling is made of white-painted boards with grooves between them:

Since getting this result, I've done quite a bit of investigation into what might be happening. For example, with the help of the datasheet for the SC101AP sensor module that's used in the SC101IOT, I added support for raw Bayer RGB mode to eliminate the whole RGB to YUV to RGB transform series. When I put the sensor in RAW mode, the pixel data in the frame buffer is definitely Bayer RGB, but the images look essentially the same as in YUV422 mode. Here's a photo of my ceiling taken in RAW mode (in dimmer light), converted to jpeg and stored on an SD card:

I've done a bunch of other tests, all of which point to the sensor actually sending odd data, but that seems really unlikely. I just can't figure out what I must be doing wrong. Has anyone seen similar behavior when using the SC101IOT?

[jksemple]

This may be another consequence of the bug reported in #676. If your camera is returning rgb565 the conversion to jpg assumes the 16bit pixel value is ordered as high byte low byte. Try swapping the byte order of your image and it should fix the problem.

[dehne]

Thanks for responding. Yes, I'm probably missing something like that!

But I'm pretty sure it's not an endian problem in this case because, according to the sensor datasheet, in the two PIXELFORMATs it supports -- YUV422 and RAW -- pixel components are all 8-bit values. In YUV422, they are laid out as YUYV order. In RAW format, the image is basically a straight dump of the image sensor with its Bayer filter. So, the even numbered lines are laid out G R G while the odd lines are B G B. Again, the components are only 8-bits long.

Again, thanks for taking the time to respond.

[jksemple]

You said your frame buffer is 1280 x 720 x 2 which implies you expect 2 bytes per pixel so I assumed you had converted to Rgb565.

[dehne]

Sorry for the confusion. Yes, like RGB565, YUV422 and (for this sensor, at least) RAW formats are 2 bytes per pixel. Though, unlike RGB565, the pixel components for these formats aren't contiguous.