enables ROI useage

[apzerafa]

This should make the ROI functions work

[apzerafa]

For what it's worth, I am using this for a personal project that I thought would need ROI. Either I was using it incorrectly or it didn't work. After I made these changes I was able to manipulate the ROI. Still didn't work for what I needed. This may or may not be correct, but it did work for me.

[ladyada]

hiya please fix the CI :)

[FoamyGuy]

@apzerafa Hi, thanks for working on this. I ran added a commit with the code formatting get the actions to pass.

I'm not quite sure that I follow how this change could have a functional effect. The changed code seems to always be writing and reading 1 byte, so I'm not understanding how the endeian-ness could factor in since a single byte doesn't really have an "order" since there is only one of them. As an example I ran this in the REPL and it shows that encoding an int into a single byte will always result in the same byte value no matter if "big" or "little" is specified for byte order:

>>> i = 0x12
>>> i.to_bytes(1)
b'\x12'
>>> i.to_bytes(1, "big")
b'\x12'
>>> i.to_bytes(1, "little")
b'\x12'

Are you certain that this change had any functional effect? Can you clarify what you meant by "After I made these changes I was able to manipulate the ROI. " a little? Like what specific behavior where you seeing before you made these changes? And then if the behavior changed after making this change what specifically about it changed?

[FoamyGuy]

Further I just noticed that #21 is proposing essentially the opposite, using "little" endian byte order, and seems to be saying that it is meant to solve the same problem with roi center and xy.

I will need to get my hands on one of these sensors and try to figure out the current behavior and test these fixes. I am a bit perplexed at how either of them would make any functional difference.

[FoamyGuy]

Okay, after puzzling over this a few more minutes and looking closer at the changes I think I understand what is going on.

The code originally didn't pass any arguments at all it was just to_bytes() with no arguments, which indeed raises an exception

>>> i.to_bytes()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function missing 1 required positional arguments

Both PRs are essentially fixing the same thing which is that the length positional argument is required and not given. Both PRs also added the optional byte_order as well, though set to opposite values. And my understanding about it being a single byte and thus the order not mattering seems to be validated somewhat by the fact that opposite values used have led to same behavior in the code.

[FoamyGuy]

I added another commit with some additional info in the docstring for roi_center to try to clarify how it is used a little bit, including a helpful table of values from #21.

It turns out that I did already have one of these devices and I was able to successfully test this change with it.