[Yars-users] Camera Pixel shift issue resolved.

[Robert M. <rob...@gm...>]

Hello List,

OpenGL appears to store images in memory in a row-wise fashion. If the  
byte length of a row (image width * 3) is not a multiple of 4, the row  
is padded by the missing nr of bytes. In Rendertexture.cpp, line 708  
this has to be taken into account when running through the image byte- 
wise, otherwise there will be pixel/color shifts.
I replaced the for-loop at line 708 by this piece of code:

int k=0;
int n=0;
int padding = 0;
if (!((_iWidth*3)%4 == 0))
{
   padding = 4 - (_iWidth*3)%4; // #Bytes used to pad each image row.
}
for(int rows=0; rows<_iHeight; rows++)
{
   for(int cols=0; cols<(_iWidth*3)+padding; cols++)
   {
     if (cols < _iWidth*3)
	{
	  _texels[k] = (double)pBuf[n];
	  k++;
	}
	n++;
   }
}


Now the images coming out of Yars look fine in RGB and single-channel  
mode. I don't know about the luinance mode. The problem shouldn't  
occur there, as RGBA uses 4 bytes per pixel by default. But I'll have  
to check that.

In summary: The RGB / single channel camera now works for "low"  
numbers of sensors & effectors.
Beyond 2^14 sensors/effectors i either get segfaults or"-1" output.  
The former seems to be a yars problem, the latter a client problem.  
I'll look into that.

Best
Robert

- - - - - - - - - - - - -
Robert Märtin
University of Osnabrück,
Institute of Cognitive Science,
Neurobiopsychology
Room 31/247
Albrechtstr. 28
49069 Osnabrück
Germany

Work: 0541 969 3403
Mobile: 0176 51550153
www.cogsci.uni-osnabrueck.de/~NBP