Undocumented restriction on camera width values

[jrutgeer]

Environment

• Ubuntu 22.04
• gz-rendering8 build from source

Description

A camera sensor allows only specific <width> values.
On first sight it seems that the horizontal resolution must be a multiple of 4.

E.g. in the camera_sensor example world, changing <width>1280</width> into <width>1281</width> yields a garbled image.

There does not seem to be a similar restriction for the <height> value.

I don't think this is an issue in real life, as upon quick look I did not find any cameras with horizontal resolution undivisible by four. (I did find some with vertical resolution undivisible by four, but that is supported).

Nevertheless, if this is a requirement, it might be valuable to add an error message upon specification of an incompatible horizontal resolution.

[mjcarroll]

Interesting, I suppose this is something that doesn't come up often. I imagine it's a requirement from the underlying rendering engine. Are you using ogre2?

@darksylinc are ogre-next render targets restricted to some set of resolutions?

[jrutgeer]

It apears on both Ogre and Ogre2.

Camera sensor example world with width of 321:

<camera>
    <horizontal_fov>1.047</horizontal_fov>
    <image>
      <width>321</width>
      <height>240</height>
    </image>
    <clip>
      <near>0.1</near>
      <far>100</far>
    </clip>
</camera>

This is Ogre:

This is Ogre2:

Close up looks like this:

I haven't been able to reproduce this for a width value that is divisible by four.

[darksylinc]

are ogre-next render targets restricted to some set of resolutions?

No, they are not.
10 years ago you could hit some obscure GL driver bug with some weird resolutions but I haven't heard of such thing in the last 10 years (unless you tell me this is WSL, which is an odd one).

This sounds like some silly bug when Gazebo is downloading from GPU to CPU. Usually mistaken pitch with width.

e.g.

pixels[y * width + x];
// vs
pixels[y * texBox.bytesPerRow + x];

OgreNext enforces an alignment of 4 bytes for texture data, so if this if an R8 or R16 greyscale texture, it could be easily explained by that. TextureBox::bytesPerRow accounts for that alignment.

e.g. a 3x2 R8_UNORM texture will have the following layout in memory:

R R R P
R R R P

Where P is padding so that y = 1 starts at an address multiple of 4 bytes.

More examples:

//  4x2  R8_UNORM texture will  not need such padding:
R R R R
R R R R

// 5x2 R8_UNORM needs a lot of padding:
R R R R R P P P
R R R R R P P P

RGBA8_UNORM will never exhibit this issue because each pixel being 4 bytes in size means that all pixels are naturally aligned to 4 bytes regardless of resolution.

Note that the opposite may be happening: Gazebo makes a lot of (redundant) copies, and it no longer requires pitch (because Gazebo tightly packed them together), but it is now using an old pitch to read it.

[iche033]

fixed by gazebosim/gz-gui#602