×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

V4L2 subframe error with PHD2

  • Posts: 38
  • Thank you received: 1
Hey guys

I'm tackling a few long lasting issue which started bothering again. One of those is the inability to use subframes with my set-up.
I have a DMK guiding cam that work perfectly fine, except for the fact that I get an error and garbage data when selecting the subframe option in PHD2.

That's what I get, any ideas what's wrong or what I can do?
DEBUG	1956.299460 sec	: Requested CCD Frame is (1222,830) ( 51 x  51)
INFO	1956.299533 sec	: ERROR (setcroprect): crop width/height must be pair

I presume PHD2 figuers that something went wrong and requests a full frame again. At least some times :)
DEBUG	1952.455501 sec	: Requested CCD Frame is (  0,  0) (2592 x 1944)
DEBUG	1952.457582 sec	: V4L2 base setcroprect 2592x1944 at (0, 0)

Thanks in advance
Niko
6 years 1 week ago #24224

Please Log in or Create an account to join the conversation.

Can you subframe it in KStars?
6 years 1 week ago #24236

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
That limitation is located in the V4L2 client of INDI. There may be a historical reason for this that I don't know about, but perhaps a fix can be made.
Clipping rectangles usually results in a lot of if/then blocks, but we could imagine cropping one pixel larger in hardware and cropping a second time in software to the requested size.
While the even/odd issue is relatively easy to tackle, we'll quickly hit the limitations of de V4L2 information API if the device rejects arbitrary crop dimensions.
Of course, the easy solution is to always have the client request even crop dimensions.

-Eric
6 years 1 week ago #24245

Please Log in or Create an account to join the conversation.

I can subframe fine with my Logitech webcam using V4L2 driver, so the same principle should apply unless DKM is a special case.
6 years 1 week ago #24246

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
Well, in any case, v4l2_base.cpp:1703 explicitly rejects non-even crop dimensions.

-Eric
The following user(s) said Thank You: Niko Kivel
6 years 1 week ago #24248

Please Log in or Create an account to join the conversation.

  • Posts: 38
  • Thank you received: 1
I'll try with an even crop window, and report back.

Niko
6 years 1 week ago #24252

Please Log in or Create an account to join the conversation.

  • Posts: 38
  • Thank you received: 1
So it seems as if PHD2 is always requesting an odd crop window.
One can set a 'search region' in pixel which is uses for the crop window, as 2*search_region+1.

When removing 'return -1;' from v4l2_base.cpp:1706 to allow odd crop windows, PHD is working fine.

I guess this feature is important for something, may I ask was the reason not to allow this in the first place?

I'm not familiar with the code, so it's a bit hard to figure out how this soft-croping works. But I presume a valid approach would be to grab one additional pixel in case of odd pixel count and and crop it in software before shipping?

best
Niko
6 years 1 week ago #24262

Please Log in or Create an account to join the conversation.

Yeah, it should be fairly easy to add 1 pixel to odd-requests. Not sure why odd numbers are rejected by V4L2, maybe due to binning issues as well?

@TallFurryMan, what do you think? Any negative consequences of that?
Last edit: 6 years 1 week ago by Jasem Mutlaq.
6 years 1 week ago #24271

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
I don't know the historical reason for this. I just checked there was no provision in the V4L2 API to determine whether a device would be able to crop odd dimensions or would reject it. So there's a chance removing the test will cause regressions out in the field.

To provide support for odd cropping boundaries, on devices that supposedly support only even boundaries, there are several things to do:
1- increase odd cropping dimensions by one pixel. Clipping them to frame boundaries should always be OK, unless we have a device with odd frame dimensions.
2- decrease odd cropping coordinates by one pixel. Clipping them to frame boundaries should always be OK.
3- request cropping to the device.
4- re-crop the cropped frame returned by the device to the requested crop boundaries by removing the first or last row or column of pixels.

Step 4 cannot be bypassed because of the importance of sub-pixel accuracy for guiders. Leaving a 1-pixel shift obviously has dramatic effect.

-Eric
6 years 1 week ago #24276

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
I suggest you keep track of this issue on the INDI github. Perhaps someone can come up with a Pull Request for this? I could eventually, but I'm still struggling with proper build configuration in kstars for the purpose of another activity :)

-Eric
6 years 1 week ago #24301

Please Log in or Create an account to join the conversation.

  • Posts: 38
  • Thank you received: 1
I'm looking into it. But it's rather hard for me to get into the code and understand what is done where.
My solution was to comment out the 'return -1;' :), which is fine for me, but defies the point of the entire exercise :)
best
Niko
Last edit: 6 years 1 week ago by Niko Kivel.
6 years 1 week ago #24303

Please Log in or Create an account to join the conversation.

Time to create page: 0.790 seconds