Hi Luxonis Team, We are using an **OAK4-CS** camera to capture images at the sensor’s full resolution of **8000 × 6000**. We noticed a repeating diagonal line pattern across the entire image, when capturing a plain or uniform background with no sample present. I have attached an example image showing the issue. The same diagonal pattern is visible when capturing in both **NV12 and RGB formats**. It is also present in the saved images, so it does not appear to be only a display or preview issue. Our setup: * Camera: OAK4-CS * Camera socket: CAM_A * Resolution: 8000 × 6000 * Connection: USB 3.2 Gen 1, reported as SUPER * Camera FPS: 10 FPS * Exposure: 10 ms * ISO: 100 * Luxonis OS: 1.37.0 * Host OS: Windows * Illumination: Continuous external illumination * Image formats tested: NV12 and RGB * Saved format: BMP/PNG Could you please help us understand the following? 1. Is this diagonal pattern caused by the image sensor, ISP processing, rolling shutter, illumination flicker, or fixed-pattern noise? 2. Is this behaviour expected when using the camera at the full 8000 × 6000 resolution? 3. Are any sensor or ISP correction settings required to remove these lines? 4. Is there a recommended camera configuration for obtaining a clean full-resolution image? 5. Are there any firmware, Luxonis OS, or DepthAI updates that specifically address this issue? 6. Could this indicate a defective camera sensor? The pattern remains visible across different regions of the image and is most noticeable on uniform backgrounds. Please let us know how we can resolve this issue and whether you require any additional images, logs, device information, or test results from our side [upl-image-preview uuid=b00b87f1-1925-4807-9257-01f94dab8f5a url=https://discuss.luxonis.com/assets/files/2026-09-20/1789881984-19764-screenshot-2026-09-20-093904.png alt={TEXT?}]

Hey @"SubashDas"#p34631 - thank you for the detailed report. This pattern is not expected in a clean 48 MP image. At 8000 × 6000, the IMX586 uses its full-resolution Quad Bayer remosaic path, which can make sensor correction or calibration errors visible. The attached image is resized to 2538 × 1396. Resizing can change a fine grid into diagonal lines. Could you please provide: - One original, unmodified 8000 × 6000 PNG or BMP file - A 512 × 512 center crop at 100% scale - The same scene at 4000 × 3000, with the same exposure, ISO, and light - Your exact DepthAI version and capture script - The device serial number If possible, also capture a RAW10 frame with the [camera raw example](https://docs.luxonis.com/software-v3/depthai/examples/camera/camera_raw/). This will show whether the pattern is present before the processed RGB/NV12 output. Please also repeat the test in daylight or with a verified non-PWM light. With manual exposure, anti-banding is not active. I do not see a published OS or DepthAI release note for this exact issue. Therefore, an update can be a useful comparison, but it is not a confirmed fix. The current evidence is not sufficient to identify a defective sensor. Thanks, Oskar

Hi @"oskarlsson"#1269, Thank you for your reply. Please find the requested capture data, script and logs at the link below: [Support Data for Troubleshoot](https://emagegroup-my.sharepoint.com/:u:/p/subash_chandradas/IQAzX_wjJVSwT60FN3LKN-0LAVNuR60etPMucaW3JRnms4M?e=TGnCj7) **Device and Software Details** * Device: OAK-4-CS-IMX586 * Device ID / Serial Number: 4254278901 * Luxonis OS: 1.35.0 * DepthAI: 3.10.0 * Python: 3.11 * Host operating system: Windows * Connection: USB (SUPER) **Capture Settings and Results** * Actual exposure: 5 ms * Actual ISO: 65 * Requested frame rate: 10 FPS * Camera socket: CAM_A The processed 8000 × 6000 and 4000 × 3000 images, along with their native 512 × 512 center crops, were saved successfully. Both processed captures reported the same exposure and ISO. However, RAW10 capture at the explicitly requested 8000 × 6000 resolution timed out without receiving a frame. Using the official example’s default camera setup, we received a 4000 × 3000 RAW10 frame, but encountered a buffer/stride mismatch during conversion to an image. The original RAW binary and relevant logs are included in the shared data. Could you please provide a sample Python script for capturing and correctly saving RAW10 frames on this device, preferably at 8000 × 6000? Please also confirm whether full-resolution RAW10 capture is supported with our current OS and DepthAI versions. Please let us know if you need any additional data or further tests. Best Regards, Subash

Hi @"osamasalah"#1408, Thank you for your guidance. I updated Luxonis OS to **1.44.0**, kept **DepthAI 3.10.0**, and successfully captured an 8000 × 6000 RAW10 frame using your separate RAW-only pipeline. Please find attached the `.dai` file and the screenshot confirming the updated OS version. OS Details: [upl-image-preview uuid=c84f0cce-dddb-4338-9af2-27816a9f9e4d url=https://discuss.luxonis.com/assets/files/2026-10-02/1790959193-749096-image.png alt={TEXT?}] [upl-file uuid=055ac717-aade-44f3-90a6-d9c7d394f39f size=72MB]raw-8000x6000.bin[/upl-file] The console output was: $$ [4254278901] [2.2] [1226140.980] [Camera(0)] [warning] No intrinsics data found for camera on socket 0 Type.RAW10 8000 6000 10000 75001856 0:00:00.005000 65 $$ The reported exposure is **5 ms**, while the reported sensitivity is **65**, although the script requests ISO 100. Could you please review the saved frame, confirm whether the RAW output is correct, and advise on the next steps to investigate the diagonal line pattern? PLEASE LET ME KNOW WHAT TO DO NEXT ? Best regards, Subash

Diagonal line pattern in OAK4-CS full-resolution 8000 × 6000 images

SubashDas

Hi Luxonis Team,

We are using an OAK4-CS camera to capture images at the sensor’s full resolution of 8000 × 6000.

We noticed a repeating diagonal line pattern across the entire image, when capturing a plain or uniform background with no sample present. I have attached an example image showing the issue.

The same diagonal pattern is visible when capturing in both NV12 and RGB formats. It is also present in the saved images, so it does not appear to be only a display or preview issue.

Our setup:

Camera: OAK4-CS
Camera socket: CAM_A
Resolution: 8000 × 6000
Connection: USB 3.2 Gen 1, reported as SUPER
Camera FPS: 10 FPS
Exposure: 10 ms
ISO: 100
Luxonis OS: 1.37.0
Host OS: Windows
Illumination: Continuous external illumination
Image formats tested: NV12 and RGB
Saved format: BMP/PNG

Could you please help us understand the following?

Is this diagonal pattern caused by the image sensor, ISP processing, rolling shutter, illumination flicker, or fixed-pattern noise?
Is this behaviour expected when using the camera at the full 8000 × 6000 resolution?
Are any sensor or ISP correction settings required to remove these lines?
Is there a recommended camera configuration for obtaining a clean full-resolution image?
Are there any firmware, Luxonis OS, or DepthAI updates that specifically address this issue?
Could this indicate a defective camera sensor?

The pattern remains visible across different regions of the image and is most noticeable on uniform backgrounds.

Please let us know how we can resolve this issue and whether you require any additional images, logs, device information, or test results from our side

Oskar-Luxonis

Hey SubashDas - thank you for the detailed report. This pattern is not expected in a clean 48 MP image. At 8000 × 6000, the IMX586 uses its full-resolution Quad Bayer remosaic path, which can make sensor correction or calibration errors visible.

The attached image is resized to 2538 × 1396. Resizing can change a fine grid into diagonal lines. Could you please provide:

One original, unmodified 8000 × 6000 PNG or BMP file
A 512 × 512 center crop at 100% scale
The same scene at 4000 × 3000, with the same exposure, ISO, and light
Your exact DepthAI version and capture script
The device serial number

If possible, also capture a RAW10 frame with the camera raw example. This will show whether the pattern is present before the processed RGB/NV12 output.

Please also repeat the test in daylight or with a verified non-PWM light. With manual exposure, anti-banding is not active.

I do not see a published OS or DepthAI release note for this exact issue. Therefore, an update can be a useful comparison, but it is not a confirmed fix. The current evidence is not sufficient to identify a defective sensor.

Thanks,
Oskar

SubashDas

Hi @oskarlsson,

Thank you for your reply.

Please find the requested capture data, script and logs at the link below:

Support Data for Troubleshoot

Device and Software Details

Device: OAK-4-CS-IMX586
Device ID / Serial Number: 4254278901
Luxonis OS: 1.35.0
DepthAI: 3.10.0
Python: 3.11
Host operating system: Windows
Connection: USB (SUPER)

Capture Settings and Results

Actual exposure: 5 ms
Actual ISO: 65
Requested frame rate: 10 FPS
Camera socket: CAM_A

The processed 8000 × 6000 and 4000 × 3000 images, along with their native 512 × 512 center crops, were saved successfully. Both processed captures reported the same exposure and ISO.

However, RAW10 capture at the explicitly requested 8000 × 6000 resolution timed out without receiving a frame. Using the official example’s default camera setup, we received a 4000 × 3000 RAW10 frame, but encountered a buffer/stride mismatch during conversion to an image. The original RAW binary and relevant logs are included in the shared data.

Could you please provide a sample Python script for capturing and correctly saving RAW10 frames on this device, preferably at 8000 × 6000? Please also confirm whether full-resolution RAW10 capture is supported with our current OS and DepthAI versions.

Please let us know if you need any additional data or further tests.

Best Regards,
Subash

Oskar-Luxonis

SubashDas - please first update Luxonis OS using the data-preserving update instructions. Keep DepthAI 3.10.0 for this test.

Then capture RAW with a separate pipeline. I received 8000 × 6000 RAW10 with DepthAI 3.10.0 on OS 1.41.0.

Please try this:

import time
import depthai as dai

with dai.Device(dai.DeviceInfo("4254278901")) as device:
    with dai.Pipeline(device) as pipeline:
        cam = pipeline.create(dai.node.Camera).build(
            dai.CameraBoardSocket.CAM_A,
            sensorResolution=(8000, 6000),
            sensorFps=10,
        )
        cam.initialControl.setManualExposure(5000, 100)
        queue = cam.raw.createOutputQueue(maxSize=1, blocking=False)

        pipeline.start()
        deadline = time.monotonic() + 30
        frame = None

        while pipeline.isRunning() and time.monotonic() < deadline:
            frame = queue.tryGet()
            if frame is not None:
                break
            time.sleep(0.01)

        if frame is None:
            raise TimeoutError("No RAW frame received")

        frame.save("raw_8000x6000.dai")
        print(frame.getType(), frame.getWidth(), frame.getHeight(),
              frame.getStride(), len(frame.getData()),
              frame.getExposureTime(), frame.getSensitivity())

This saves the complete frame with its metadata. Please share the .dai file, printed output, and updated OS version.

The two supplied .bin files decode exactly to your processed BMP images, so they contain NV12 rather than sensor RAW10. Also, RAW buffers can contain extra trailing bytes, which your current decoder rejects. Saving the complete frame will let us check the correct layout before conversion.

Thanks,
Oskar

SubashDas

Hi @osamasalah,

Thank you for your guidance.

I updated Luxonis OS to 1.44.0, kept DepthAI 3.10.0, and successfully captured an 8000 × 6000 RAW10 frame using your separate RAW-only pipeline.

Please find attached the .dai file and the screenshot confirming the updated OS version.

OS Details:

raw-8000x6000.bin

72MB

The console output was:

$$
[4254278901] [2.2] [1226140.980] [Camera(0)] [warning] No intrinsics data found for camera on socket 0
Type.RAW10 8000 6000 10000 75001856 0:00:00.005000 65
$$

The reported exposure is 5 ms, while the reported sensitivity is 65, although the script requests ISO 100.

Could you please review the saved frame, confirm whether the RAW output is correct, and advise on the next steps to investigate the diagonal line pattern?

PLEASE LET ME KNOW WHAT TO DO NEXT ?

Best regards,
Subash

SubashDas

Hi @Oskar-Luxonis ,

Please disregard the previous attachment, as I noticed that the .dai file was automatically uploaded in .bin format.

Please download the correct .dai file using the link below:

dai file

Best Regards,
Subash

Oskar-Luxonis

SubashDas - thanks for the corrected file. It loads and unpacks as an 8000 × 6000 RAW10 frame. We however could not see the diagonal lines on it.

Could you confirm whether the original diagonal lines are still visible in your RGB/NV12 images on OS 1.44.0?

Thanks,
Oskar

SubashDas

Hi @Oskar-Luxonis,

Thank you for reviewing the RAW10 file.

Yes, the diagonal texture is still visible in processed color images on Luxonis OS 1.44.0 with DepthAI 3.10.0. I captured a new 8000 × 6000 NV12 frame and saved it as PNG and BMP. The texture remains visible in the attached native 512 × 512 center crop, without resizing.

One clarification: the device identifies itself as OAK4-S R9, serial 4254278901, although my earlier posts described it as OAK4-CS.

Both the RAW-only and processed-color pipelines requested 5000 µs exposure and ISO 100, but their reported metadata differs:

Setting RAW10 Processed NV12
Resolution 8000 × 6000 8000 × 6000
Actual exposure 5000 µs 5000 µs
Reported sensitivity ISO 65 ISO 100

I am providing the new NV12 .dai, original PNG, native center crop, JSON metadata, and capture script here:

https://emagegroup-my.sharepoint.com/:f:/p/subash_chandradas/IgC7UN6VkLCJRZsoVUCp6a0_Aa1KjiMymkR1F7lI2Nhuzrw?e=ZtmGQU

Could you please investigate why the texture persists in processed output when you did not observe it in RAW? Also, why do the two pipelines report different sensitivities for the same ISO request, and how should we match their actual gain for a controlled comparison?

Please advise on the recommended configuration or correction for obtaining clean full-resolution color images, and whether you need any further tests to distinguish an ISP/tuning issue from a hardware fault.

Best regards,
Subash

Oskar-Luxonis

Hey SubashDas - thanks for the new captures. A correction to my last reply: after a full-resolution analysis of your RAW10 frame, the diagonal lines are present in the RAW output. They come from the sensor, not from the ISP.

The pattern is aligned to the 4-pixel Quad Bayer grid of the IMX586, which applies only to the 8000 × 6000 mode. It is weak in the centre and stronger towards the corners. There is no setting on your side that removes it. As a workaround, please use 4000 × 3000. In our test with the same sensor, 4000 × 3000 showed no measurable pattern.

About the ISO difference: in a RAW-only pipeline at 8000 × 6000, the requested ISO is not applied. The frame reports 65, but exposure time is applied. With an NV12 output, the requested ISO is applied, so please use the processed outputs for a gain-matched comparison.

I am sharing your RAW frame and our analysis with our firmware team and will follow up here.

Thanks,
Oskar

SubashDas

hi @oskarlsson,

Any updates from your firmware team on the diagonal pattern in the 8000 × 6000 images?

We understand that 4000 × 3000 is the current workaround, but we need the full resolution for our inspection application. Could you please confirm whether a fix is possible and share an estimated timeline for the investigation?

Thanks,
Subash

Oskar-Luxonis

Hey SubashDas - thanks for following up. The analysis is now with our firmware team. The 8000 × 6000 mode uses the sensor's on-chip remosaic, so we are checking whether its configuration can reduce the pattern. I cannot give a timeline yet. I will update you here as soon as I have their answer.

Thanks,
Oskar

SubashDas

Hi @oskarlsson ,

Thanks for the update.

Regards,
Subash