Parsing the line count out of a StreamImage from a Linea camera

Programming Questions .Net API
,
21

@Theo told me that the Linea overwrites data pixels with the meta information. So this is normal.

Linear Access does not really work well in this case. Marshal is a bit slow. Pointer access (unsafe) would be faster.

1 Like
22

:heart:

Where do I find the pointer, starting from the Image? Do you mean the Access.BasePtr, or something else?

I think I’ve just had a eureka moment. The data that I’m seeing ‘between’ the pixels (when I access with Marshal) is the data from the other Planes. Is that correct?

23

Basically pointer access on :cvb: images looks like this:

unsafe
{
  var pBase = (byte*)access.BasePtr;
	
  var line = 42;
  var pLine = pBase + line * (long)access.YInc;
}

As the metadata overwrites the actual pixel data, you can “jump” one line below the metadata to access and subtract the metadata size (was it 8 bytes?):

[StructLayout(LayoutKind.Sequential, Pack = 4)]
struct MetaData
{
  public uint FrameCounter;
  public uint CameraID;
	
  public static unsafe MetaData FromLine(LinearAccessData access, int line)
  {
    var pData = (byte*)access.BasePtr + (line + 1) * (long)access.YInc - sizeof(MetaData);
    return *(MetaData*)pData;
  }
}

This is only correct, though, if there is no additional padding. But the data you provided shows that there is none.

1 Like
24

I don’t think I can mark two answers in one topic as an answer, but … this is an answer :slight_smile:

I don’t actually need every line as I’m just looking at FrameCount (at the moment), but this could come in handy later, and in any case for someone else it will probably be exactly what they need. Thanks. Again.

1 Like
25

So far none is marked :wink:. Choose the one you prefer :heart:.

26

There’s a slight bug actually, you need to multiply sizeof(MetaData) by access.IncX to get the right offset, so:

var pData = (byte*)access.BasePtr + (int)access.YInc 
                                     - (sizeof(MetaData) * (int)access.XInc);
27

That would imply either padding or that there is even more data to the right of the desired meta data.

28

You’re right, that’s strange, now I’ve got to work out why that works and the other one doesn’t for me :frowning:

OK, this is weird2, you’re right about the padding:

image

endOfLineMetadataPixelCount says 8 pixels, but as you can see from the image above, even though the camera reserves 8 pixels for the meta data, it actually just offsets 8 pixels (so 8 x 3 bytes) from the end, and then writes the two uints directly into the data, so the FrameCounter and CameraId effectively occupy the first and second pixels, and two bytes of the third pixel.

              px1   px2   px3   px4   px5   px6   px7   px8
              R G B R G B R G B R G B R G B R G B R G B R G B
FrameCounter  x x x x 
CameraId              x x x x

This is confirmed by the fact that the code as above also correctly parses out the CameraId.

So it was just ‘coincidence’ that sizeof(MetaData) and endOfLineMetaDataPixelCount were both 8, but one is 8 bytes and the other is 8 pixels.

1 Like