Thread: Another Novice Question - ofstream

Hi again,

I'm asking once again for some enlightenment from you guys, hope you can help me out.

I'm using an SDK which does some image processing, it also makes it easy to capture from a webcam, but the object it returns is of a proprietry image format.

There is a static method along the lines of

Code:

Jpg::save (const Image &img, std::ostream &, int quality=100)

where
parameter 1 is the returned format of the webcam image capture
parameter 2 is an ostream
parameter 3 is the compression level.

There is a similar method

Code:

Jpg::save (const Image &img, const std::string &filename, int quality=100)

that saves directly to a file.

I want, with some frequency, to capture the images from the webcam to display in a Win32 application, however I would prefer not to have to save to the HDD all the time as this is slow. I've been googling alot today on loading jpgs from the HDD to the window using the GDI, if the jpg is in say an ofstream, would loading be similar ? Is this like loading from a HDD without the physical operations ?

I have for example

Code:

std::ofstream ofs("JpgFile.jpg", std::ios::out | std::ios::binary ); 
FRsdk::Jpeg::save(img, ofs, 100);

presuming that since the definition is of ostream, ofstream is what should be used ?

Anyways, your general advice on the matter would be greatly appreciated.

Thanks again

For example, if the jpg is in the ofstream, this technically should contain all the jpg information shouldn't it ? Is there any way to translate this into FILE as from

Code:

FILE* file;
file = fopen(filename, "r");

Though the example I seen relating to FILE only loaded bmps unfortunately. Most GDI examples seem to use the resource file to store the images, which isn't very useful when constantly updating the picture you want to display.

I could just save it to the HDD and load it back, but the IO overhead would be extreme...

Sorry to be posting so much, but I just noticed something in the sdk that made me think of something else.

There is an option to extract the image as an array of bytes representing the grayscale representation (grayscale isn't ideal but a start).

I can't remember exactly, but isn't there a GDI call (blit something...) that allows displaying images by bytes. I vaguely remember seeing an image output to the screen using standard windows calls (i.e. not a library like OGL etc) using some kind of array. Although, from memory I think this was actually to the entire screen even outside the window...

If anyone knows what I'm talking about that'd be great.

Sorry again for the frequent posts.

Streams can send information into files, but they can also be directed toward in-memory buffers. If you wish to avoid using static storage, you could open an in-memory buffer stream, let your SDK write into that, and take it out later on using an istream. This isn't something I've ever done myself, but I'm sure a little stop by MSDN should provide you with all the answers you need concerning non-file streams.

Thanks for the information.
I found this tutorial, maybe it will help me in this regard.
http://spec.winprog.org/streams/

However, before I start researching how to do this, I'm worried about what will happen if I successfully get the jpg into an istream? Do I need a third party library to be able to display it to the screen?

Thanks again.