Closed sebandraos closed 9 years ago
Hi, sorry, I don't really understand the question.
In the RealSenseGrabber header the image widths and heights are hard-coded to 640x480 for both the colour and depth streams but the R200 camera doesn't have a 640x480 depth stream (the closest is actually 628x468) so the validity test in run() fails. With a GUI this is easy to solve because the user could choose the resolution but I don't have the time to knock one up at the moment so I have a few solutions for the default behaviour (open to alternatives). 1. Always pick the default streams, regardless of what they are. 2. Hard-code the frame sizes with a switch based on camera model. 3. Hard-code a desired frame size and pick the closest stream sizes according to the device. Almost all of these require aligned frame grabbing in case the streams differ in size. This may already be working but if it isn't I'll switch the functions over (not very difficult with the RSSDK) so I think I'm going to go with option 1 for the time-being and maybe switch over to something else once/if there's a GUI/command switch involved later.
So I've tweaked the code in my fork to change the behaviour a little. Instead of creating a profile from scratch we now search through the available profiles until we find one that has our requirements i.e. depth + rgb32 and equal frame rates. This is fully functional for the F200 but I've got some strange striation of colours with the R200. Particularly odd because the colours actually being written to the cloud seem right (having manually trawled through a nice big export). Is this something you've come across before(Image Attached)? It could have something to do with image scaling but the F200 works beautifully with identical sized depth and colour streams.
Thanks for taking time to explain the issue. The hard-coded resolution/framerate is a temporary solution. Other grabbers have an enum where all modes that are (potentially) supported are listed. I think this grabber should have such a list as well. Then on runtime the mode closest so the one requested by the user should be selected. Different default based on the sensor type is an interesting feature and could be easily added. I will implement this when I have some time, hopefully this week.
Regarding the weird colors: don't remember having this. I'll check if we have R200 in the lab, and if so, will try it out.
We don't have R200, but I have ordered one. Let's see how long shipping to Austria will take.
Thanks for getting on to this Sergey. An all inclusive option is definitely a possibility. I'm not sure whether it's the same with other devices but with the RS cameras we can query the profiles at initialisation to find the best one rather than creating an exhaustive list of combinations (which for the F200 would be more than 150 options). I think with a small tweak to my latest modifications this would be fairly simple to implement as long as we know what the input parameters are e.g. WIDTH, HEIGHT, FRAMERATE, COLOUR_PROFILE, DEPTH....
P.S. Once they were in stock mine only took a few days to London so it shouldn't be very different.
The delivery was very fast, I got the camera already on Thursday! But surprisingly, the customs fee was just crazy, 50 euros. How much did you pay in Britain?
Now as for the issue at hand, I did quite some progress during the weekend. The grabber can list supported modes and accept requests on which mode the user wants. Please see the documentation comments. The viewer app is updated to support listing and selecting modes.
The code is currently in a separate branch. I'm looking forward to get your feedback before merging it into master.
Haven't had time to look into the colors issue yet. But can confirm that I observe it when color/depth stream resolutions do not match.
Wow, that's really quick. I guess that's the bonus of ordering while in stock rather than preordering. It was something like 40 euros when I got the F200 in Paris but in London I wasn't charged a customs fee.
I really like the mode lists, really powerful feature for us(ers). Just wondering if there could be an advantage to the numbering being continuous and the mode therefore acting as a depth/depth+colour switch in its own right. May be worthwhile, may just add complexity for nothing. Otherwise it seems to work really well. I think this is a good solution.
Shall I open a new issue for the colour striation so we can keep the two separate?
Just wondering if there could be an advantage to the numbering being continuous and the mode therefore acting as a depth/depth+colour switch in its own right.
Good idea, I'll implement it and then merge the branch into master.
Shall I open a new issue for the colour striation so we can keep the two separate?
:+1:
Done
Great, I think that's a really clean solution.
Hey Alexey,
I just got my R200 yesterday (F200 still working fine) and there seems to be an issue with the profile currently being set in the RealSenseGrabber. I'm going to play around and see what I can come up with but the values, although hard-coded, look incredibly neutral and align with available modes on the camera. If you have any ideas please do let me know.
Thanks