I’m trying to use an AR0234 CoE camera through the holoscan bridge on Thor JP7.2. I can reliably get images through both the raw and ISP outputs of nvsipl_camera. As soon as I enable the sensor’s embedded data rows, the ISP output is displaced horizontally — the raw capture appears unaffected, and the embedded content itself decodes correctly.
Looking at the raw buffer, the two line types are stored at different sizes:
The embedded lines carry a 2400-byte RAW10 payload stored on a 2432-byte stride, while image lines occupy 2560 bytes for the same 1920-pixel window. So they are not the same length which I suspect is the initial cause of the issue.
On the sensor side I only have enable/disable (no control over the embedded line length). Is there anything on the API side to declare or correct it? I can see embDataFrontResolution exists but it does not appear to solve my issue.
In the screenshot below, the white band down the left side is misplaced image content — it belongs at the right edge of the frame.
I agree with your analysis, it sounds like the additional embedded content is messing up the calculation for the start address.
This is actually an expectation (that strides are different). The HSB will transmit the data as is for embedded header/footer, but for the RAW10 Bayer, it becomes tightly packed (what we call RAW10TP) in that it should make the RAW section have a stride of 3456B (2560 * 4/3 then round up to nearest 64B = 3456).
So, for the top embedded data lines, that is configured in the vb1940_config.json file via “embeddedTopLines” field. I don’t believe there is further modification controls that are exposed besides that. (Have you tried changing that?)
What were there modifications to the HSL to enable this error?
Yes — embeddedTopLines: 2 is exactly the configuration that produces the image above. embeddedTopLines: 0 also gives a displacement (on the opposite edge) as long as the sensor transmits embedded data; only sensor-embedded-off + embeddedTopLines: 0 is clean.
What were the modifications to the HSL to enable this error?
Only enabling embedded data on the sensor. Note I’m not using a VB1940, but the same scheme should apply to any sensor I guess.
The HSB will transmit the data as is for embedded header/footer, but for the RAW10 Bayer, it becomes tightly packed
That matches what I see, with embeddedTopLines: 2 the image content starts 2 × (2560 − 2432) = 256 bytes early relative to where the ISP reads it. So it looks like the ISP path skips the embedded lines at the image stride rather than at their own.
What do you recommend for me to get a proper image ?
I don’t mind not having control over it, but I suppose this needs at least a fix so the appropriate stride is used for both for the embedded data and the raw section.
