We are doing some handheld AR on Nokia N95s.  We've got the  
ARToolkitPlus working, and a simple app (using EdgeLib for graphics)  
going.  But, getting video from the camera, into a format that can be  
used by ARToolkitPlus and as data to put into texture memory, is very  
expensive.  We're currently having to resort to calling the Nokia  
access routines to get the pixels out of the returned camera image  
one-by-one and store them in a buffer;  very inefficient.

Has anyone else worked with video on Symbian phones and gotten video  
efficiently out of the buffer format returned from the camera?  If we  
could get some help, it would be greatly appreciated!

thanks!
_______________________________________________
ARToolKit mailing list
ARToolKit@l .................
http://www.hitlabnz.org/mailman/listinfo.cgi/artoolkit

I have very little experience with Symbian, but lots with Phones in general.
Send me the raw pixel buffer you get from the camera and I'll have a
look at it...

Daniel


Blair MacIntyre wrote:
> We are doing some handheld AR on Nokia N95s.  We've got the  
> ARToolkitPlus working, and a simple app (using EdgeLib for graphics)  
> going.  But, getting video from the camera, into a format that can be  
> used by ARToolkitPlus and as data to put into texture memory, is very  
> expensive.  We're currently having to resort to calling the Nokia  
> access routines to get the pixels out of the returned camera image  
> one-by-one and store them in a buffer;  very inefficient.
>
> Has anyone else worked with video on Symbian phones and gotten video  
> efficiently out of the buffer format returned from the camera?  If we  
> could get some help, it would be greatly appreciated!
>
> thanks!
> _______________________________________________
> ARToolKit mailing list
> ARToolKit@l .................
> http://www.hitlabnz.org/mailman/listinfo.cgi/artoolkit
>   

_______________________________________________
ARToolKit mailing list
ARToolKit@l .................
http://www.hitlabnz.org/mailman/listinfo.cgi/artoolkit

Blair MacIntyre wrote:
> We are doing some handheld AR on Nokia N95s.  We've got the  
> ARToolkitPlus working, and a simple app (using EdgeLib for graphics)  
> going.  But, getting video from the camera, into a format that can be  
> used by ARToolkitPlus and as data to put into texture memory, is very  
> expensive.  We're currently having to resort to calling the Nokia  
> access routines to get the pixels out of the returned camera image  
> one-by-one and store them in a buffer;  very inefficient.
> 

I have camera capture on symbian 7.0s (nokia 6600) and it is quite fast. 
I'm using ViewFinderFrameReady from CVideoRecorder, which return 16 bits 
RGB buffer (5,6,5), which is trivial to convert to greyscale:
void CVideoRecorder::ViewFinderFrameReady(CFbsBitmap& aFrame)

How are you getting buffer on the N95 ?


_______________________________________________
ARToolKit mailing list
ARToolKit@l .................
http://www.hitlabnz.org/mailman/listinfo.cgi/artoolkit

Karthik Raveendran wrote:
> Hi,
> I'm using ViewFinderFrameReady from CCamera and I'm forced to do a pixel 
> by pixel copy from CFbsBitmap into a unsigned char* buffer (to be passed 
> into ARToolkitPlus). Is there a faster way to get this data from 
> CFbsBitmap? I tried using the DataAddress pointer but the image appeared 
> to be corrupted - I could not find much information about the way 
> CFbsBitmap stored its data.
> 

You are getting CFbsBitmap* aImage and can get it's format with 
aImage->DisplayMode()
There are several display modes ranging from EGray2 to EColor16M

After that you can extract data into destination buffer
aImage->LockHeap();
Mem::Copy(aDestinationPtr, aImage->DataAddress(),
(aWidth+aPadding)*aHeight*aSizeOfPixel);
aImage->UnlockHeap();	

or extract each scanline data

TInt y;
for( y=0; y<aHeight; y++ )
{
aImage->GetScanLine( aScanlineDestinationPtr, TPoint( 0, y ), aWidth, 
aDisplayMode);
}

Scanline is more reliable, because you don't have to guess padding, but 
copying is faster. You have padding if width is not dividable by 4 I think.

After that process buffer/scanline to extract r,g,b colors.
Each format is a string of bits packed to bytes -
for example EColor64K is 5,6,5 for rgb, packed into two bytes, EColor16M 
is 8,8,8 and EColor16MU/A is 8,8,8,8
Extracting color is trivial for EColor16M or EColor16MU - just take 
corresponding byte. For EColor64K (2 bytes) it require some bits 
shuffling, like
	r = aColor>>(2*MIN_COLOR_DEPTH + ODD_SHIFT);
	g = (aColor - (r<<(2*MIN_COLOR_DEPTH + 
ODD_SHIFT)))>>(MIN_COLOR_DEPTH+ODD_SHIFT);
	b = aColor&MAX_COLORR;

You can also ask Symbian specific questions, not related to AR at 
symbian forums at newlc.com and discussion.forum.nokia.com . Also it's 
useful to read Symbian documentation, though not easy.




BTW, for your information - if you asking something on the public 
mailing list, you shouldn't ask for answer in the private mail if not 
specifically invited. Everyone should see both question and answer, so 
that everyone could benefit from it - that is what mailing lists for. No 
offense intended - just explanation how those things work.
_______________________________________________
ARToolKit mailing list
ARToolKit@l .................
http://www.hitlabnz.org/mailman/listinfo.cgi/artoolkit