From: Peter V. <pet...@ya...> - 2005-04-19 09:24:53
|
> The weak link here is vxl. At first, I thought I would use the > vil_save function to save my modified image to a named pipe, and feed > that into ppmtoy4m. However, when I try to do that the assertion > 'f_.good()' in vil_stream_fstream::seek fails. Unfortunately, in order to implement writing image "views", i.e., subimages, the pnm writer uses fseek()s to skip to the appropriate position in the output file when performing *any* write, also when the output view equals the full image. The best solution would be to rewrite the method vil_pnm_image::put_view() and distinguish the special case (x0=y0=0 && view.ni() == ni_), avoiding fseek()s in that case. B.t.w., this holds for almost every image format (in core/vil/file_formats/), the only exception being png, I believe. So, for the time being, you might try writing png format instead of ppm. -- Peter. |
From: Peter V. <pet...@ya...> - 2005-04-20 07:32:18
|
> I did try saving png's to a fifo, but that crashed on the same > assertion, so I'm guessing even the png saving code relies on > fseek()s. If I'm not mistaken, the only two fseek()s in vil_png are for skipping to the start of the file, and are happening in respectively read_header() and write_header(). I would expect that, when one of these is called, the file pointer is already at beginning of file, so no actual "fseek(0)" is needed. The fseek() for output actually gets executed through a call to vil_stream_fstream::seek(position), which is implemented as std::fstream::f_; // this is the output file if (position != f_.tellp()) f_.seekp(position); hence no seekp() call is performed when the position is already correct. Similarly for input files, where tellg() and seekg() are used. So I'm a bit surprised that this still gives problems with streaming output. Maybe someone more familiar with the vil internals should have a look at this. It could also help to turn on debugging output, by changing the #define xerr on line 34 of vil_stream_fstream.cxx -- Peter. |
From: Peter V. <pet...@ya...> - 2005-04-21 07:33:39
|
> If I have time, I'll try rewriting the put_view method as you > suggested, since using pngs would dramatically increase my framerate. I've had a quick look at the actual use of seeks in both png-read and png-write, at least, as far as vil_stream_fstream is concerned. The remarkable thing is that png-read has 2x seek(0): from byte position 2 and from position 4. This is problematic with non-file input. On the other hand, png-write has no seeks, so it should work with non-file (streaming) output. This is of course without considering libpng, which maybe has some additional seeks. Here is the "xerr" output on reading a png: vcl_fstream: vil_stream_fstream("file.png", "r") = 18 vcl_fstream: seekg from 0 to 0 vcl_fstream: seekg from 0 to 0 vcl_fstream: tellg vcl_fstream: read 2 vcl_fstream: tellg vcl_fstream: seekg from 2 to 0 vcl_fstream: tellg vcl_fstream: read 4 vcl_fstream: tellg vcl_fstream: seekg from 4 to 0 vcl_fstream: tellg vcl_fstream: read 4 ... (no more seeks from here on) And here is the "xerr" output on writing a png: vcl_fstream: vil_stream_fstream("file.png", "w") = 1 vcl_fstream: seekp from 0 to 0 vcl_fstream: tellp vcl_fstream: write 8 vcl_fstream: tellp ... (no more seeks from here on) -- Peter. |
From: Michael G. <hea...@gm...> - 2005-04-19 21:38:12
|
Thanks for the quick response, guys. I'm grabbing from v4l input, so my quick n' dirty answer was to us vil_view to process my frame in memory, then dump it over stdout with a simple for loop that accessed the frame directly. I did try saving png's to a fifo, but that crashed on the same assertion, so I'm guessing even the png saving code relies on fseek()s. If I have time, I'll try rewriting the put_view method as you suggested, since using pngs would dramatically increase my framerate. Thanks again. On 4/19/05, Peter Vanroose <pet...@ya...> wrote: > > The weak link here is vxl. At first, I thought I would use the > > vil_save function to save my modified image to a named pipe, and feed > > that into ppmtoy4m. However, when I try to do that the assertion > > 'f_.good()' in vil_stream_fstream::seek fails. >=20 > Unfortunately, in order to implement writing image "views", i.e., > subimages, the pnm writer uses fseek()s to skip to the appropriate > position in the output file when performing *any* write, also when the > output view equals the full image. >=20 > The best solution would be to rewrite the method > vil_pnm_image::put_view() and distinguish the special case (x0=3Dy0=3D0 &= & > view.ni() =3D=3D ni_), avoiding fseek()s in that case. >=20 > B.t.w., this holds for almost every image format (in > core/vil/file_formats/), the only exception being png, I believe. > So, for the time being, you might try writing png format instead of > ppm. >=20 >=20 > -- Peter. > |