The Toradex IMX676 crops active sensor area

Technical Support
, , ,
1

Hello,

We chose the IMX676 sensor for our project, because it has a square sensor with a resolution of 3552 x 3552 according to its datasheet. However, it seems that Toradex’s driver is hard-coded to vertically crop the active sensor area. I am wondering if this is intentional, and whether it is possible for Toradex to modify the driver to use the entire active sensor area. I am not an experienced driver developer and hesitate to attempt this change myself.

I followed the driver and device tree setup in the documentation. That went well. The camera is working great and I am streaming video to my application.

The issue is that I can see my image is not perfectly square and is clearly cropped on the top and bottom. Digging deeper into the drivers in the imx676-driver folder, I see the following:

// imx676-driver/imx676_regs.h

#define IMX676_DEFAULT_WIDTH            3552
#define IMX676_DEFAULT_HEIGHT           3092

And this:

// imx676-driver/imx676_mipi.c

static struct vvcam_mode_info_s pimx676_mode_info[] = {
	{
		.index          = 0,
		.size           = {
			.bounds_width  = IMX676_DEFAULT_WIDTH,
			.bounds_height = IMX676_DEFAULT_HEIGHT,
			.top           = 12,
			.left          = 8,
			.width         = 3536,
			.height        = 3072,
		},
// ...

I don’t suppose I can simply change those values? It seems like they may have been picked for a particular reason. Let me know what you think.

Thank you,
William

Output of tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.84-7.2.0-g87bfb710b6f1 #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/157a467dd3b97eaebfbf6e17d0c8859fdd0abc1d397c637c6ecd808f79dc0260/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.2.0-build.13
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15601692
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0070 V1.1A
Serial number:            15601692
Processor arch:           aarch64
------------------------------------------------------------
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello William,

Thank you for your detailed explanation and the information from your setup!

About the Sensor Cropping

Based on the details you provided, it appears the default mode defined in your IMX676 driver does not use the full sensor area—specifically, it’s using 3552 x 3092 rather than 3552 x 3552 pixels. This cropping (notably, a reduction in height) is likely intentional for reasons such as providing a format that matches a particular output resolution, accounting for sensor-specific requirements, or ensuring driver stability with the tested range.

Within the driver, these values define the “active” area reported to the system. Adjusting them affects how much of the raw sensor is presented to your video pipeline.

Is It Safe to Change These Values?

You’re correct not to change these values lightly, as they may have been chosen to match:

  • Output image format requirements (e.g., for working with standard video resolutions).
  • Sensor limitations (certain rows/columns may not be valid for readout).
  • Constraints based on interface bandwidth, performance, or electrical characteristics.
  • Requirements for correct MIPI CSI-2 framing or camera controller compatibility.

The areas named top, left, width, height, etc., in the driver specify what subset of the sensor is used. If the hardware and the driver support full-resolution (3552x3552) output, you could try adjusting these values as an experiment, but:

  • Changing only the width/height may not be sufficient. You’ll also need to ensure the sensor registers and any MIPI configuration align with the new image size.
  • Driver, sensor firmware, and ISP (Image Signal Processor) constraints could prevent using the entire sensor area. Some “edge” pixels are not used due to quality or sensor design.
  • Other components (such as GStreamer pipelines or V4L2) may expect typical aspect ratios. Native square might not be broadly supported.

Next Steps (Driver Customization Context)

Since Toradex’s Torizon documentation recommends using device tree overlays for configuration but does not cover deep driver changes, and since you are not experienced in Linux driver development, you should carefully consider the following options:

1. Device Tree Overlays

Overlays are a safe way to enable hardware features or change basic configuration (such as I2C addresses or GPIOs). However, they cannot change sensor cropping or output resolution at the driver level. Device tree customization overview.

2. Driver Modification

If you wish to attempt using the full height:

  • Carefully edit the mode definition in your imx676_mipi.c to set bounds_height and height to 3552.
  • Check if register settings in imx676_regs.h or similar source files for frame/ROI (region of interest) match these dimensions.
  • Rebuild and deploy the updated kernel module or device tree. Monitor kernel logs for errors.

3. Testing

After rebuilding, check video output for errors such as:

  • No image (sensor initialization failure)
  • Artifacts at the image edge (invalid pixel data)
  • MIPI/CSI errors in dmesg or kernel logs

Summary

  • The cropping is likely intentional and may be fundamental to stable operation.
  • If you modify mode dimensions, do so cautiously, and be prepared for possible video subsystem problems.
  • Broad compatibility with image pipelines often favors standard aspect ratios and resolutions.

If you need further details about device tree overlays (which are safer to experiment with), you can refer to the official Toradex guide:
Device tree customization overview

If you would like more specific tips for building and deploying a modified driver, please let me know!

Best regards,
Toradex AI Assistant.

3

Please note that these are Framos Imaging drivers, not developed by Toradex. According to the release notes, the sensor resolution was cropped due to an ‘NXP limitation’. Unfortunately, we do not have details regarding this limitation. However, you may be able to obtain more information by contacting NXP directly via the NXP Community.

4

Ah, my mistake! Thank you @alex.tx

Thanks also for those helpful links. I will take this up with NXP and FRAMOS. We can live with the cropping for now.

Thank you!
William

5

I would like to re-open this post. I hope that is OK.

We have realized that the FRAMOS driver provides a binning mode (“mode 2”). It looks like this will allow us to use the whole sensor at a lower resolution, which is fine for our case.

I’m working with Toradex’s sample isp-imx container image. I see that the patch 0002-Add-support-for-imx6xx-sensors.patch has configurations for mode 0 and mode 3, but not for mode 2.

I would like to do the following, but I’m not sure how to properly generate patches for the isp-imx image. Can Torizon make this change in the public torizon-samples repository? Or can you walk me through how to create the following patch for my image?

  1. Add a mode 2 config to run.sh (I think this requires a new patch)
imx676_binned )
    MODULES_TO_REMOVE=(  "imx676" "${MODULES[@]}")
    MODULES=("imx676" "${MODULES[@]}")
    RUN_OPTION="CAMERA0"
    CAM_NAME="imx676"
    DRV_FILE="imx676.drv"
    MODE_FILE="IMX676_MODES.txt"
    MODE="2"
    write_sensor_cfg_file "Sensor0_Entry.cfg" $CAM_NAME $DRV_FILE $MODE_FILE $MODE
    ;;
  1. Then I would change my docker-compose command to use this config:
command: ["./run.sh", "-c", "imx676_binned", "-lm"]

Thank you,
William

6

I figured out how to generate the patch, and I opened a PR to the torizon-samples repository here:

I applied that patch to my own isp-imx image, and updated my docker-compose.yaml, as I indicated above. It seems to be working well!

Here’s a side-by-side of the image capture (1) without binning, and (2) with binning. You can see that the first image is stretched vertically, while the second image is square with less cropping on each side. This is what we need!

2025-07-22_puttrax-binning-comparison
2025-07-22_puttrax-binning-comparison1200×606 45.5 KB

This issue is resolved.

1 Like
7

Hello! William. It seems that your problem has been solved successfully. I would like to ask you, how is your experience with this IMX676? Looking forward to your reply.

8

It’s been great to work with so far. No complaints. Toradex has very good support documentation and examples to get started using the IMX676 with an NXP-based board.

This sensor cropping issue at full resolution is the only thing that took us by surprise. In our case we don’t need HD images, so the binning mode is adequate for our needs, but be forewarned about this limitation. If you’re hoping to get the full 3552x3552 pixel resolution, it is not possible with the IMX676 and NPX IMX8MP.

9

Thank you very much for your reply. About the IMX676 with an NXP-based board, Can you provide me with this link? I’m a beginner, thanks!

10

HI @heifeng20220601

You can find the first steps instructions here.