O

oto313

Hi, I've got a setup that involves a ColorCamera and an ImageManip node in a pipeline. The ColorCamera has a 12MP ISP output, which is then sent to the ImageManip node. I've noticed that when I resize the image to approximately FullHD (2:3 aspect ratio) using the .setResize method in the ImageManip node, the resulting image exhibits a pronounced moire effect. I'm curious to know what type of resizing method is being employed. Additionally, is there a filter or technique available in OAK-FFC-3P that can help mitigate this moire effect?

Also I would like to resize crop rotate and then warp the image in a single Image manip node. Help would be appreciated, because I have no more free memory on OAK-FFC-3P

Hi @erik

I already saw the documentation, but i wasnt able to find order of operations in ImageManip.
It yields varying results depending on whether warping or resizing is performed first. I think that information is not in documentation. I already successfuly warped and resized image using 2 ImageManip nodes, but i wanted to do it in single ImageManip node.

But when I create mesh for 4032x3040. and call setResize(4032,2040) on ImageManip node then I get following image

So what is the proper way to resize and warp?

So how does ImageManip node works if it performs multiple operations? It would be nice to have that in documentation. Thanks.

Hello, I am attempting to modify and distort a 12MP image obtained from the ColorCamera ISP output. My current pipeline consists of the following pipeline: ColorCamera.isp -> ImageManip -> H.264 encoder -> XlinkOut.

My objective is to resize the 12MP image to a resolution of 2016x1520 and then apply distortion correction using the setWarpMesh function. As per a Github issue I came across, the ImageManip component should perform the resizing operation before any other operations.

(the resize is done as part of of first step in current updated ImageManip impl)

In the code snippet from the Github gist, I've noticed that it crops the image instead of resizing it, resulting in a loss of image data. Specifically, the ImageManip node seems to take only a 2160x1520 portion of the 12MP image.

Interestingly, when I adjust the ispScale to (1,2), ensuring that the input and output resolutions of the ImageManip node match, the process works as intended.

Do you know where could be a problem? Thanks

I was using older depthai SDK. After I updated it works.

Greetings, I have the subsequent pipeline configuration:

Input: Control queue into -> ColorCamera for still images -> ImageManipulation -> VideoEncoder (MJPEG) -> Output queue

When I initiate the image capture process using the provided code:

dai::CameraControl ctrl;
ctrl.setCaptureStill(true);
control_queue_in->send(ctrl);

Upon the first attempt to retrieve the image from the output queue, I encounter an absence of image data. Consequently, I must execute the capture process once more, after which I successfully obtain an image, albeit with a delay of one frame. Subsequently, each new request made through CameraControl message yields an image from the previous request.

Do you know where could be a problem? Thanks

Thanks for help. I really appreciate it. It would really help us

Hi, @erik
Yes I tried (first photo is with auto whitebalance and second with manual whitebalance - about 6500K, the best result I can get). But I need to set compensation for each color channel individually (RGB). That option can drastically help to improve image quality. I tried that on Basler camera (mentioned above). And simple whitebalance is just not helping. I need to set balance ratio for each channel. Then white is perfect white on image.

I am forwarding the images from camera to H.264 encoder so I need to be able to do some compensations inside OAK device

Ok. So your sales should give warning that you are ordering Luxonis with adapters that are useless. We almost ordered another batch of useless adapters. My luxonis version: DM1090FFC R3M0E2

Any progress? We are just in process of ordering 15 pcs and I do not want to have same problems.

I will try to reproduce it. Normally it does not log any critical message.

Ok thanks for reply. If any help is needed i am happy to do so.

Any progress? Or horizon when you can investigate this?

Thanks

Hi, I tried 2.15 depthai, but same issue happens.
I am retrieving output of queue by following code:

bool hasTimeout = false;
      gst_print("calling get\n");
      auto h264packet = queue_out->get<dai::ImgFrame>(std::chrono::duration_cast<std::chrono::seconds>(1s), hasTimeout);
      gst_print("calling get done\n");
      if(hasTimeout){
         gst_print("Retrieve timeout\n");
         return false;
      }

I also turned on logs by setting environment variable DEPTHAI_LEVEL=trace

Here is output:

[2022-02-24 07:28:17.181] [trace] Log vector decoded, size: 3
[14442C1001DBAACE00] [18187.511] [system] [info] Memory Usage - DDR: 94.51 / 339.99 MiB, CMX: 2.18 / 2.50 MiB, LeonOS Heap: 21.38 / 78.29 MiB, LeonRT Heap: 3.76 / 41.54 MiB
[14442C1001DBAACE00] [18187.511] [system] [info] Temperatures - Average: 47.24 °C, CSS: 48.03 °C, MSS 46.90 °C, UPA: 47.13 °C, DSS: 46.90 °C
[14442C1001DBAACE00] [18187.511] [system] [info] Cpu Usage - LeonOS 0.30%, LeonRT: 0.17%
[2022-02-24 07:28:17.707] [trace] Received message from device (h264) - parsing time: 88µs, data size: 14797, object type: 1 object data:
0000: b9 06 b9 08 18 81 cd 39 81 d0 39 00 01 00 82 00 e1 e8 2f 82 00 e1 e8 2f 00 00 86 58 53 08 00 b9
0020: 02 86 ec db 03 00 86 b7 b0 9a 05 b9 02 85 0c 47 86 c5 a9 47 00
calling get done
calling get
calling get done
Retrieve timeout
calling get
calling get done
Retrieve timeout
calling get
calling get done
Retrieve timeout
calling get
calling get done
Retrieve timeout
calling get
[2022-02-24 07:28:22.182] [trace] Log vector decoded, size: 3
[14442C1001DBAACE00] [18192.512] [system] [info] Memory Usage - DDR: 94.51 / 339.99 MiB, CMX: 2.18 / 2.50 MiB, LeonOS Heap: 21.38 / 78.29 MiB, LeonRT Heap: 3.76 / 41.54 MiB
[14442C1001DBAACE00] [18192.512] [system] [info] Temperatures - Average: 47.35 °C, CSS: 48.47 °C, MSS 46.23 °C, UPA: 47.58 °C, DSS: 47.13 °C
[14442C1001DBAACE00] [18192.512] [system] [info] Cpu Usage - LeonOS 0.44%, LeonRT: 0.18%
[2022-02-24 07:28:22.739] [trace] Received message from device (h264) - parsing time: 89µs, data size: 15647, object type: 1 object data:
0000: b9 06 b9 08 18 81 1f 3d 81 20 3d 00 01 00 82 00 81 b8 2f 82 00 81 b8 2f 00 00 86 ef 53 08 00 b9
0020: 02 86 f1 db 03 00 86 b3 fa 8c 07 b9 02 85 11 47 86 c1 f3 39 02
calling get done
calling get
calling get done
Retrieve timeout
calling get
calling get done
Retrieve timeout
calling get
calling get done
Retrieve timeout
calling get
calling get done
Retrieve timeout
calling get
[2022-02-24 07:28:27.183] [trace] Log vector decoded, size: 3
[14442C1001DBAACE00] [18197.513] [system] [info] Memory Usage - DDR: 94.51 / 339.99 MiB, CMX: 2.18 / 2.50 MiB, LeonOS Heap: 21.38 / 78.29 MiB, LeonRT Heap: 3.76 / 41.54 MiB
[14442C1001DBAACE00] [18197.513] [system] [info] Temperatures - Average: 47.41 °C, CSS: 47.80 °C, MSS 46.45 °C, UPA: 47.80 °C, DSS: 47.58 °C
[14442C1001DBAACE00] [18197.513] [system] [info] Cpu Usage - LeonOS 0.23%, LeonRT: 0.17%
[2022-02-24 07:28:27.772] [trace] Received message from device (h264) - parsing time: 92µs, data size: 15677, object type: 1 object data:
0000: b9 06 b9 08 18 81 3d 3d 81 40 3d 00 01 00 82 00 21 88 2f 82 00 21 88 2f 00 00 86 86 54 08 00 b9
0020: 02 86 f6 db 03 00 86 02 bd 7d 09 b9 02 85 16 47 86 7c 38 2c 04
calling get done
calling get
calling get done
Retrieve timeout
calling get
calling get done
Retrieve timeout