Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with frame width and frame height #43

Closed
tobymcclean opened this issue Jul 31, 2020 · 2 comments
Closed

Issue with frame width and frame height #43

tobymcclean opened this issue Jul 31, 2020 · 2 comments
Labels
bug Something isn't working FixInGen2 For Gen1 bugs which make more sense to address in in Gen2 PipelineBuilder

Comments

@tobymcclean
Copy link

When running with the option -s left metaout

for _, nnet_packet in enumerate(nnet_packets):
    print(f'{nnet_packet.getMetadata().getFrameWidth()}, {nnet_packet.getMetadata().getFrameHeight()})

Is returning

  • 19, 302056116 for category 32768
  • 2597050688, 2597050816 for category 65536
  • 4294967279, 4294895615 for category -526338
  • 4286578687, 2147483647 for category -1

The code for FrameMetadata suggests that the height and width should be pixels, but the actual numbers don't make sense to me.

@Luxonis-Brandon
Copy link
Contributor

Luxonis-Brandon commented Oct 26, 2020

So @tobymcclean thanks for the report. And sorry I didn't circle back earlier. We discussed this offline (and came to a good resolution) which is to respect the actual dimensions of the metadata when getting frame width and height so that these metrics give you directly the dimensions of the metadata. Which, if I summarized correctly, is another way to describe what we decided internally:

We didn't intended these to be used on NNetPacket, but agree we'll need to provide initialized values. Currently only getFrameWidth() will return correct data, and that's the NN packet size. For this case we could make both getFrameHeight() and getFrameBytesPP() return 1, so it they are all multiplied to get the total size, the output value is correct as well.

We will be implementing this in the Gen2 version, here.

And on that, our first demonstration of the very-initial prototype of Gen2 pipeline builder is here: https://github.com/luxonis/depthai-experiments/blob/master/gaze-estimation/README.md

Thoughts?

@Luxonis-Brandon Luxonis-Brandon added bug Something isn't working FixInGen2 For Gen1 bugs which make more sense to address in in Gen2 PipelineBuilder labels Oct 26, 2020
@alex-luxonis
Copy link
Collaborator

This should be already fixed by:
luxonis/depthai#240 -> #58 -> luxonis/depthai-core#16

For an NNet packet, the metadata fields should look like (copied from the description of luxonis/depthai#240):

[hostTimestamp streamName] devTstamp seq camSrc width height Bpp
[0.772088 NNet           ] 3.836959 1 rgb 3604 1 1

(width represents the size of the output tensor, while height and Bpp are both set to 1)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working FixInGen2 For Gen1 bugs which make more sense to address in in Gen2 PipelineBuilder
Projects
None yet
Development

No branches or pull requests

3 participants