Opening an image file

[Muckle ewe]

I realize there are libraries I can download that would make life easier when it comes to dealing with image files but I'd like to know what's going on first before I resort to that.

So let's say I have an image saved on my desktop and I do the following...

#include <iostream>
#include <fstream>

int main()
{
    ifstream image;
    image.open("C:\\Documents and Settings\\B\\Desktop\\picture.png");

    return 0;
}

What is image? What can I do with it?

cout << image returns a reference, but a reference to what? What information about picture.png can I get from this?

[Cubbi]

What is image?

It is an input file stream

What can I do with it?

Nothing useful besides closing it, because you've opened a binary file in text mode.

If you use ios::binary when opening, you will be able to read individual bytes from that file using unformatted input functions such as image.get() and image.read().

To do something to the image stored in the file, you will need to use a library: either boost or something third-party.

[andywestken]

Have you checked out the Wikipedia entry yet?
http://en.wikipedia.org/wiki/Portable_Network_Graphics

The references include the png spec.

[Muckle ewe]

Right thanks guys, wasn't aware of the ios::binary thing. Will look into that. Was experimenting around and wanted to see if I could recreate an image in the console.

[Duthomhas]

1) "but I'd like to know what's going on first before I resort to that"

It is not a 'last resort' kind of thing to use a library to handle stuff like this. Dealing with image file formats is not simple. If you want to know how a specific file format works, google it: "bmp file format", "png file format", "gif file format", etc. Very few formats are so simple that you can justify the time to write all your own image handlers -- especially as you could easily make a mistake and write files that don't properly conform.

If it is a matter of learning how it works, that is one thing. Go for it.

If it is a matter of just writing software that uses different image formats, use libraries. The PNG file format uses the zlib compression library, which you would have to also rewrite (and probably fail to do correctly). Why not avoid the grief and just link to the proper libraries?


2) "cout << image returns a reference, but a reference to what?"
"Was experimenting around and wanted to see if I could recreate an image in the console."

The console is for text, not images. Your "image" object is an ifstream, meaning that the pointer you get when you 'cout << it' is the address of the ifstream object itself. Probably.

That said, it is possible to draw directly on the Windows Console window -- just don't expect Windows to make any effort to preserve the image. Over at Daniweb, member vegaseat has done similar things to your efforts.

Here he cheats by creating a new window and drawing the image to it:
http://www.daniweb.com/software-development/c/code/216431
(I don't necessarily agree with his techniques for finding the console...)

Here he draws directly on the console window itself:
http://www.daniweb.com/software-development/cpp/code/216474

Anyway, hope this helps.

[Muckle ewe]

Ok thanks for that. I think the library way might be the way to go now. I've switched to bmps since they are supposedly the easiest formats to work with. I thought it would be as simple as opening the file, scanning through it and retrieving rgb information but it's not quite that easy...

By, 'recreate an image in the console', I meant I would find the colour of each pixel in my inout image (which is in 16 colour for simplicity), then use the text colour editor provided by windows.h and the console representation of the character -127 (which is just a 'block' of one colour) to approximate the image in the console.

It was just something I started doing one day to see how easy or difficult it would be.

[Duthomhas]

I like Truevision TGA files better - BMP files have some oddities that make handling them a little more difficult than TGAs. They appear to be very flexible, but in actuality they all (are required to) conform to a specific subset of their potential capabilities -- which makes them fairly simple to handle.

The TGA 2.0 is a little weird; you don't need to worry about it. Try to write a TGA 1.0 decoder. Here are a couple of links to get you started. (Make sure to take a look through the "External Links" from the Wikipedia article.)
http://en.wikipedia.org/wiki/Truevision_TGA
http://paulbourke.net/dataformats/tga/

Good luck!