piense
Posts: 27
Joined: Thu Jun 09, 2016 4:11 am

OpenVG & vgWritePixels

Wed Sep 13, 2017 11:15 pm

I'm trying to use OpenVG on a Pi3 to display some images. I get the image in a buffer in RAM and am using vgWritePixels to push that data to a window that's rendered to the screen. I'm using the hello_font example in raspberrypi/firmware as a starting point which defaults to using the VG_sARGB_8888 image format. That seems to work ok, but when I changed the image format to VG_sRGBA_8888 to better fit the format I have coming in, bad things happen. It's hard to describe but best as I can figure the image is a somewhat transparent version of the Red channel but certain rectangular areas of the image look normal. All I'm changing is the image format to the vgWritePixels call, and the corresponding mapping of the input channels in the source array. It's all very strange. Need be I can supply all the details and code but maybe those symptoms ring a bell for someone and can point me in the right direction to understanding what might be going on.

User avatar
Paeryn
Posts: 1943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG & vgWritePixels

Thu Sep 14, 2017 2:02 am

How are you mapping the channels? Assuming the data is an array of uint8_t then the first pixel is :-

for VG_sARGB, data[0] = blue, data[1] = green, data[2] = red, data[3] = alpha
for VG_sRGBA, data[0] = alpha, data[1] = blue, data[2] = green, data[3] = red

OpenVG defines the order as highest bits on the left when read as a word but the RPi is little-endian so the lowest byte is stored at the lowest address in memory (a 32-bit value of 0x01020304 is stored as 0x04, 0x03, 0x02, 0x01).
She who travels light — forgot something.

piense
Posts: 27
Joined: Thu Jun 09, 2016 4:11 am

Re: OpenVG & vgWritePixels

Fri Sep 15, 2017 5:14 am

I figured that much out, admittedly more by trial and error than an intelligent understanding of the problem. But the problem I'm seeing isn't a simple channel mapping problem. I rendered the primary colors to the screen and there's just blocks of picture missing in certain channels.

User avatar
Paeryn
Posts: 1943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG & vgWritePixels

Fri Sep 15, 2017 8:56 am

There shouldn't be bits missing in just some channels, the only thing which affects whether pixels are copied or not is scissoring. Any pixels that are updated get the values you pass in (unless you use the _pre formats which clamp a pixel's colour channels to its alpha value).

Can you give a short example of what you are doing?
She who travels light — forgot something.

blackshard83
Posts: 72
Joined: Fri Jan 10, 2014 8:31 am

Re: OpenVG & vgWritePixels

Tue Sep 26, 2017 11:38 am

It looks weird to me too, you should "just" see the colors altered if you fail to match the channels from the source image to the OpenVG format. Nonetheless it could be tricky because if you map a color channel to the alpha channel you may actually miss some parts of the image because the color channel may express very low values in a region of the image and, as long as it is mismatched as alpha channel, OpenVG renders an almost fully transparent pixel there.

Have you considered to use the ABGR/BGRA formats? You should be able to render the source data without swapping the channels as it should be free of costs.

PS: maybe a couple of screenshots may be useful ;)

User avatar
Gavinmc42
Posts: 1929
Joined: Wed Aug 28, 2013 3:31 am

Re: OpenVG & vgWritePixels

Wed Sep 27, 2017 1:44 am

You might want to check how Ultibo does it.
https://ultibo.org/forum/viewtopic.php?f=15&t=659
But it might not be of any use for you as it use the VC4 libraries.

Try Peter Lemon's VG stuff?
https://github.com/PeterLemon/Raspberry ... nate_Array
Or AJ's
https://github.com/ajstarks/openvg
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

piense
Posts: 27
Joined: Thu Jun 09, 2016 4:11 am

Re: OpenVG & vgWritePixels

Tue Jan 23, 2018 7:24 pm

Got around to poking at this project some more. The ordering really isn't a bit issue but I'd be curious what's going on. Here's some pics of what's happening, ignore the moire effect, that's just the camera and LCD being weird.
https://imgur.com/a/OMGxC

I'm using graphics_userblt to copy the image to the screen. In that example the only thing I changed was line 787 in graphics.c from VG_sARGB_8888 to VG_sRGBA_8888. I'd expect the channels to be swapped of course but I don't understand the blocking on the right half of the screen.

User avatar
Paeryn
Posts: 1943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG & vgWritePixels

Wed Jan 24, 2018 2:20 am

The imagery showing through looks like 7 columns of 9 rows of rectangles which are getting progressively smaller going right pretty much on the right half of the screen. It looks like there might be something drawn on the screen (desktop?) underneath the OpenVG window that could be showing through now that you have non-opaque alpha values on the OpenVG window perhaps?

vgWritePixels() should just be copying the source pixel data straight onto the destination with the only alteration being the format conversion, the difference between sARGB and sRGBA should just be a byte swizzle (not taking into account sRGB is non-linear and A is always linear - I don't think it matters here as you are copying data not blending it), not something that should have such an effect anyway.
She who travels light — forgot something.

piense
Posts: 27
Joined: Thu Jun 09, 2016 4:11 am

Re: OpenVG & vgWritePixels

Wed Jan 24, 2018 2:26 am

The screen behind that window is just black. It's a custom buildroot distro with all the splash screens and login prompts disabled.

User avatar
Paeryn
Posts: 1943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG & vgWritePixels

Wed Jan 24, 2018 2:37 am

If you draw the image at an offset (say 100 pixels to the right) do the rectangles move with the image or are they in the same place on the screen? Similarly if you use a different image do you see the exact same artefact?
She who travels light — forgot something.

piense
Posts: 27
Joined: Thu Jun 09, 2016 4:11 am

Re: OpenVG & vgWritePixels

Wed Jan 24, 2018 5:09 am

Different images have the exact same artifact. If I move the image over at all with vgWritePixels dx the effect goes away entirely and it looks like what I'd expect with the channels out of order.

LdB
Posts: 751
Joined: Wed Dec 07, 2016 2:29 pm

Re: OpenVG & vgWritePixels

Thu Jan 25, 2018 4:49 am

It looks like line to line pitch is out .. which you will be using for datastride in vgWritePixels.
The worst is 1366x768 the Pi screen line to line pitch is 1376 so there is 10 whole pixel offset it you expect it to be 1366 * 4 bytes wide it isn't its 1376*4 bytes wide. Yours looks like 1 pixel or 1.5 pixels and so it's rolling in and out of synch.

It all revolves around wanting to keep neat alignment on the VC4 stride from line to line.

From memory ask it "bytesForImageScanline" in the vg utils for the surface you have.

piense
Posts: 27
Joined: Thu Jun 09, 2016 4:11 am

Re: OpenVG & vgWritePixels

Thu Jan 25, 2018 5:20 am

The parameters work fine for a different color format though, that mostly eliminates things being wonky in the rest of the input parameters. It really should just be a difference in how it interprets the given channel data.

User avatar
Paeryn
Posts: 1943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: OpenVG & vgWritePixels

Thu Jan 25, 2018 9:22 am

LdB wrote:
Thu Jan 25, 2018 4:49 am
It looks like line to line pitch is out .. which you will be using for datastride in vgWritePixels.
The worst is 1366x768 the Pi screen line to line pitch is 1376 so there is 10 whole pixel offset it you expect it to be 1366 * 4 bytes wide it isn't its 1376*4 bytes wide. Yours looks like 1 pixel or 1.5 pixels and so it's rolling in and out of synch.

It all revolves around wanting to keep neat alignment on the VC4 stride from line to line.

From memory ask it "bytesForImageScanline" in the vg utils for the surface you have.
The datastride parameter refers to the stride in the source data, if you get that wrong the whole image will be off, not just some channels on the right hand side, and the OP says the image is fine with the the different ordering of pixel data. The stride of the screen is of no concern as OpenVG knows what stride the screen is and doesn't give you any option to pass your own value.

The datastride only has to make sure that pixels are correctly aligned so for a 32bit pixel format data must be 4 byte aligned and datastride must be a multiple of 4, other than that there is no limitation. If you break the alignment then the call will not write to the screen and will return an error.
She who travels light — forgot something.

Return to “Graphics programming”

Who is online

Users browsing this forum: No registered users and 3 guests