From: Junaed S. <ju...@ci...> - 2006-04-18 00:28:20
|
Hi again. So I am still working on using vidl2 for image sequences. I can read a sequence successfully, but when I try to convert the next frame (vidl2_frame) to a vil_image_view<vxl_byte>, I get some unexpected results. My images are all RGB color images, with dimensions of 510 pixels by 422 pixels (just an example), 3 bytes per pixel (RGB). I can read them individually using vil_load. I have this code snippet: vil_image_view<vxl_byte> image; vidl2_frame_sptr frame = inputStream.current_frame(); if( !vidl2_convert_to_view( frame, image ) ) { return false; } I hope I'm doing the right thing to convert a vidl2_frame to vil_image_view. If so, then here's the problem: istep (next pixel. row wise) should be at every 3 bytes, and jstep (next row, same column) should be at width*nplanes bytes. But it isn't. With the numbers above, the values of istep should be 3 and jstep should be 1566(3*522) pixels, which is what it is if loaded using vil_load. In the case above with vidl2_convert_to_view, the values are istep=1, jstep=width (522), in the object 'image'. If the above code is wrong, I'd love to know the right way of doing things. Any pointers would be greatly appreciated! Thanks. -J- PS: Debugger shows this when using vil_load: istep_ = 3, jstep_ = 1566, planestep_ = 1. Debugger shows this when using vidl2_convert: istep_ = 1, jstep_ = 522, planestep_ = 214020 |
From: Junaed S. <ju...@ci...> - 2006-04-21 21:49:59
|
Hi Matt, Thanks for looking at the issue. I looked at the cvs via the web viewer, but it says the last time vidl2_convert.h or vidl2_convert.cxx was updated was 6 weeks ago. Has it been checked in yet ? I'm looking at the SourceForge CVS. Regards, Junaed Matt Leotta wrote: > The convert frame to view functions are under development and full of > bugs. I just rewrote the vidl2_convert_to_view function and checked > it into CVS. The API is slightly changed, but this new code may fix > your problem. If it still doesn't work let me know. > > --Matt Leotta > > On 4/17/06, Junaed Sattar <ju...@ci...> wrote: > >> Hi again. >> So I am still working on using vidl2 for image sequences. I can read a >> sequence successfully, but when I try to convert the next frame >> (vidl2_frame) to a vil_image_view<vxl_byte>, I get some unexpected >> results. My images are all RGB color images, with dimensions of 510 >> pixels by 422 pixels (just an example), 3 bytes per pixel (RGB). I can >> read them individually using vil_load. I have this code snippet: >> >> vil_image_view<vxl_byte> image; >> vidl2_frame_sptr frame = inputStream.current_frame(); >> if( !vidl2_convert_to_view( frame, image ) ) >> { >> return false; >> } >> >> I hope I'm doing the right thing to convert a vidl2_frame to >> vil_image_view. If so, then here's the problem: >> istep (next pixel. row wise) should be at every 3 bytes, and jstep (next >> row, same column) should be at width*nplanes bytes. But it isn't. With >> the numbers above, the values of istep should be 3 and jstep should be >> 1566(3*522) pixels, which is what it is if loaded using vil_load. In the >> case above with vidl2_convert_to_view, the values are istep=1, >> jstep=width (522), in the object 'image'. >> >> If the above code is wrong, I'd love to know the right way of doing >> things. Any pointers would be greatly appreciated! Thanks. >> >> -J- >> >> >> PS: Debugger shows this when using vil_load: istep_ = 3, jstep_ = 1566, >> planestep_ = 1. >> Debugger shows this when using vidl2_convert: istep_ = 1, jstep_ = >> 522, planestep_ = 214020 >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting language >> that extends applications into web and mobile media. Attend the live webcast >> and join the prime developer group breaking into this new coding territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> Vxl-users mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-users >> >> |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2006-04-21 22:54:43
|
On 4/21/06, Junaed Sattar <ju...@ci...> wrote: > Hi Matt, > Thanks for looking at the issue. I looked at the cvs via the web viewer, > but it says the last time vidl2_convert.h or vidl2_convert.cxx was > updated was 6 weeks ago. Has it been checked in yet ? I'm looking at the > SourceForge CVS. This is a sourceforge issue... They are actively working on a hardware failure that happened a while ago and, although they fixed some of the services, they still don't have the developer cvs and anonymous cvs in synch. This appears that will be solved soon, probably before the end of April. However, a release of VXL-1.5 is coming up probably next week, if that help= s. --Miguel > > Regards, > Junaed > > Matt Leotta wrote: > > The convert frame to view functions are under development and full of > > bugs. I just rewrote the vidl2_convert_to_view function and checked > > it into CVS. The API is slightly changed, but this new code may fix > > your problem. If it still doesn't work let me know. > > > > --Matt Leotta > > > > On 4/17/06, Junaed Sattar <ju...@ci...> wrote: > > > >> Hi again. > >> So I am still working on using vidl2 for image sequences. I can read a > >> sequence successfully, but when I try to convert the next frame > >> (vidl2_frame) to a vil_image_view<vxl_byte>, I get some unexpected > >> results. My images are all RGB color images, with dimensions of 510 > >> pixels by 422 pixels (just an example), 3 bytes per pixel (RGB). I can > >> read them individually using vil_load. I have this code snippet: > >> > >> vil_image_view<vxl_byte> image; > >> vidl2_frame_sptr frame =3D inputStream.current_frame(); > >> if( !vidl2_convert_to_view( frame, image ) ) > >> { > >> return false; > >> } > >> > >> I hope I'm doing the right thing to convert a vidl2_frame to > >> vil_image_view. If so, then here's the problem: > >> istep (next pixel. row wise) should be at every 3 bytes, and jstep (ne= xt > >> row, same column) should be at width*nplanes bytes. But it isn't. With > >> the numbers above, the values of istep should be 3 and jstep should be > >> 1566(3*522) pixels, which is what it is if loaded using vil_load. In t= he > >> case above with vidl2_convert_to_view, the values are istep=3D1, > >> jstep=3Dwidth (522), in the object 'image'. > >> > >> If the above code is wrong, I'd love to know the right way of doing > >> things. Any pointers would be greatly appreciated! Thanks. > >> > >> -J- > >> > >> > >> PS: Debugger shows this when using vil_load: istep_ =3D 3, jstep_ =3D = 1566, > >> planestep_ =3D 1. > >> Debugger shows this when using vidl2_convert: istep_ =3D 1, jste= p_ =3D > >> 522, planestep_ =3D 214020 > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by xPML, a groundbreaking scripting lan= guage > >> that extends applications into web and mobile media. Attend the live w= ebcast > >> and join the prime developer group breaking into this new coding terri= tory! > >> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&da= t=3D121642 > >> _______________________________________________ > >> Vxl-users mailing list > >> Vxl...@li... > >> https://lists.sourceforge.net/lists/listinfo/vxl-users > >> > >> > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users > -- Miguel A. Figueroa-Villanueva Pattern Recognition and Image Processing Lab (PRIP) Computer Science and Engineering Department Michigan State University |
From: Junaed S. <ju...@ci...> - 2006-04-21 23:26:00
|
Yup that sure sounds great. In the meantime, I'll divert my programming efforts to something else ! Thanks for the great work, guys. Regards, -J- Miguel A. Figueroa-Villanueva wrote: > This is a sourceforge issue... They are actively working on a hardware > failure that happened a while ago and, although they fixed some of the > services, they still don't have the developer cvs and anonymous cvs in > synch. This appears that will be solved soon, probably before the end > of April. > > However, a release of VXL-1.5 is coming up probably next week, if that helps. > > --Miguel > |