ARToolKit bug in arLabeling.c in debug mode

> >Hi Philip,
> >I think I found a bug  in arLabeling.c
> 
> >The size of the texture will be 512 * 512 which is being allocate 
> >but then you try to access 640*480 the size of the image
> >
> >I think  the following code should be remove:
> >	    int texXsize = 1;
> >             int texYsize = 1;
> >             while( texXsize < arImXsize ) texXsize *= 2;
> >             if( texXsize > 512 ) texXsize = 512;
> >             while( texYsize < arImYsize ) texYsize *= 2;
> >             arMalloc( arImageL, ARUint8, texXsize*texYsize*AR_PIX_SIZE );
> >
> >and replace by:
> >	    arMalloc( arImageL, ARUint8, arImXsize*arImYsize*AR_PIX_SIZE );

On Thu, 2004-11-04 at 16:36 +1300, Philip Lamb wrote:
> Yes, this is most certainly a bug.. one of the many in the toolkit 
> related to fixed-size assumptions about the video stream.
> 
> One thing that bothers me about this is why correct code is in the 
> source but commented out... obviously for some reason, someone 
> decided it was better to allocate a power-of-two size buffer. Perhaps 
> this was for performance reasons. I've had a fairly thorough look and 
> I can't see any side-effects from the changes you propose, so I've 
> implemented them in our CVS source. You'll see them in the 2.69 
> release (out any day now).
> 
> I've cc'd this to the list. If anyone else can shed some light on 
> this or can see why Alex's changes wouldn't work, please speak up.

I imaginge the arImageL would be used as a texture. For textures it is
common to be a power of two. I don't believe older versions of OpenGL
can handle non-power-of-two textures, nor can probably many older
videocards. If the videocard can't handle it you can put the code
between an ifdef.

#ifdef NVEXT
	arMalloc( arImageL, ARUint8, arImXsize*arImYsize*AR_PIX_SIZE );
#else
	int texXsize = 1;
	int texYsize = 1;
	while( texXsize < arImXsize ) texXsize *= 2;
	if( texXsize > 512 ) texXsize = 512;
	while( texYsize < arImYsize ) texYsize *= 2;
	arMalloc( arImageL, ARUint8, texXsize*texYsize*AR_PIX_SIZE );
#endif

NVEXT is defined in the configure script ("Build gsub libraries with
texture rectangle support?"). It allows the use of
GL_NV_texture_rectangle [1] support in the videocard.

I haven't tested this yet...

[1]
http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_rectangle.txt

From:	Peter Oost <h.b.oost@s .................>	Received:	Nov 4, 2004
To	Philip Lamb <phil@e ..........>
Subject:	Re: ARToolKit bug in arLabeling.c in debug mode
> >Hi Philip, > >I think I found a bug in arLabeling.c > > >The size of the texture will be 512 * 512 which is being allocate > >but then you try to access 640480 the size of the image > > > >I think the following code should be remove: > > int texXsize = 1; > > int texYsize = 1; > > while( texXsize < arImXsize ) texXsize = 2; > > if( texXsize > 512 ) texXsize = 512; > > while( texYsize < arImYsize ) texYsize = 2; > > arMalloc( arImageL, ARUint8, texXsizetexYsizeAR_PIX_SIZE ); > > > >and replace by: > > arMalloc( arImageL, ARUint8, arImXsizearImYsizeAR_PIX_SIZE ); On Thu, 2004-11-04 at 16:36 +1300, Philip Lamb wrote: > Yes, this is most certainly a bug.. one of the many in the toolkit > related to fixed-size assumptions about the video stream. > > One thing that bothers me about this is why correct code is in the > source but commented out... obviously for some reason, someone > decided it was better to allocate a power-of-two size buffer. Perhaps > this was for performance reasons. I've had a fairly thorough look and > I can't see any side-effects from the changes you propose, so I've > implemented them in our CVS source. You'll see them in the 2.69 > release (out any day now). > > I've cc'd this to the list. If anyone else can shed some light on > this or can see why Alex's changes wouldn't work, please speak up. I imaginge the arImageL would be used as a texture. For textures it is common to be a power of two. I don't believe older versions of OpenGL can handle non-power-of-two textures, nor can probably many older videocards. If the videocard can't handle it you can put the code between an ifdef. #ifdef NVEXT arMalloc( arImageL, ARUint8, arImXsizearImYsizeAR_PIX_SIZE ); #else int texXsize = 1; int texYsize = 1; while( texXsize < arImXsize ) texXsize = 2; if( texXsize > 512 ) texXsize = 512; while( texYsize < arImYsize ) texYsize = 2; arMalloc( arImageL, ARUint8, texXsizetexYsize*AR_PIX_SIZE ); #endif NVEXT is defined in the configure script ("Build gsub libraries with texture rectangle support?"). It allows the use of GL_NV_texture_rectangle [1] support in the videocard. I haven't tested this yet... [1] http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_rectangle.txt

From:	Philip Lamb <phil@e ..........>	Received:	Nov 4, 2004
To	Alexandre Gillet <gillet@s ..........>
Subject:	Re: ARToolKit bug in arLabeling.c in debug mode
Hi Alexandre, Yes, this is most certainly a bug.. one of the many in the toolkit related to fixed-size assumptions about the video stream. One thing that bothers me about this is why correct code is in the source but commented out... obviously for some reason, someone decided it was better to allocate a power-of-two size buffer. Perhaps this was for performance reasons. I've had a fairly thorough look and I can't see any side-effects from the changes you propose, so I've implemented them in our CVS source. You'll see them in the 2.69 release (out any day now). I've cc'd this to the list. If anyone else can shed some light on this or can see why Alex's changes wouldn't work, please speak up. Regards, Phil. >Hi Philip, >I think I found a bug in arLabeling.c > >In the case: > arDebug =1 > arImageProcMode =0 # use the full image to process and not > # half of it > the video image is 640480 or video image bigger than 512512 > >you get a segmentation fault cause of the following code: >( the code just create allocate the debug image arImage) > >line 506 to 515 > if( arImageL == NULL ) { > int texXsize = 1; > int texYsize = 1; > while( texXsize < arImXsize ) texXsize = 2; > if( texXsize > 512 ) texXsize = 512; > while( texYsize < arImYsize ) texYsize = 2; > arMalloc( arImageL, ARUint8, texXsizetexYsizeAR_PIX_SIZE ); > /* arMalloc( arImageL, ARUint8, >arImXsizearImYsizeAR_PIX_SIZE ); / > put_zero( arImageL, lxsizelysizeAR_PIX_SIZE ); > arImage = arImageL; > >The size of the texture will be 512 512 which is being allocate >but then you try to access 640480 the size of the image > >I think the following code should be remove: > int texXsize = 1; > int texYsize = 1; > while( texXsize < arImXsize ) texXsize = 2; > if( texXsize > 512 ) texXsize = 512; > while( texYsize < arImYsize ) texYsize = 2; > arMalloc( arImageL, ARUint8, texXsizetexYsizeAR_PIX_SIZE ); > >and replace by: > arMalloc( arImageL, ARUint8, arImXsizearImYsize*AR_PIX_SIZE ); > > >Am I right? >Thanks >Alex > >-- > o Alexandre Gillet email: gillet@s .......... > / The Scripps Research Institute, >o Dept. Molecular Biology, MB-5, > \ 10550 North Torrey Pines Road, > o La Jolla, CA 92037-1000, USA. > / tel: (858) 784-2053 >o fax: (858) 784-2860 -- Philip Lamb Research Student, Human Interface Technology Laboratory New Zealand, University of Canterbury, Christchurch, NZ. +64 3 3642987 x3070