I don't want the error texture of my game engine to rely on an external file, because that file might be deleted, which defeats the purpose of having an error texture. How can I convert an image file into a C-sytle char array that I can read using glTexImage2D?
First, convert your source image file to the 'raw' format (while "remembering" the dimensions of your image in a pair of variables). For this you can use the ImageMagick's convert tool.
The sample for greyscale images conversion is given by this answer. For RGB images either write your own image-to-binary-file converter (since you probably know how to load RGB images for other textures, or use the STB or similar library to load it and then save the image data to a binary file), or (if no automation of this conversion step is needed) just use some GUI tool to save the RAW image.
Then use a tool named bin2h (binary file to C header) which takes a file as an input (your 'raw' file) and outputs a C header with a byte array.
One of such tools can be found at Bin2H#github
Then use the declared array (and a pair of variables with texture dimensions) as an argument to glTexImage2D.
If you have no aversions against 'gimp', gimp has a .h or .c exporter. In that way you have direct access to the dimensions and buffer of your image. Although it is not compressed, so be aware if you want to use a large Image.
Is it possible to trace back an image say a png image to a jpg? For example an image x.jpg that was converted to x.png. Is there a way of telling that x.png is essentially x.jpg, with the difference being formats?
If l convert img.jpg to img.png is it posssible for me to get back img.jpg?
I intend to check this in C.
As to your first question, the meta-information stored in PNG can tell what the original format or file was. But there is no requirement to store this meta-information in the file.
As to your second question: PNG is a lossless format. So if you decompress a Jpeg image into a bitmap and then encode that bitmap as PNG, you can at least get back from th PNG to the bitmap of the jpeg.
Getting back to the jpeg essentially means re-encoding (compressing) the bitmap, but to arrive at the bitwise identical Jpeg file means using the same compressor settings that were used to create the original Jpeg. As you probably don't know those settings (and it may depend on the compressor code too), I would say "No, you can't get back to the original Jpeg."
I lack a clear understanding of the concepts of file, file encoding and file format. Google helped up to a point.
From what I understand so far, all the files are binary, i.e., each byte in such a file can contain any of the 256 possible strings of bits. ASCII files (and here's where we get to the encoding part) are a subset of binary files, where each byte uses only 7 bits.
And here's where things get mixed up. A file format seems to be a way to interpret the bytes in a file, and file extensions seem to be one of the most used ways of identifying a file format.
Does this mean there are formats defined for binary files and formats defined for ASCII files? Are formats like xml, pdf, doc, rtf, html, xls, sql, tex, java, cs "referring" to ASCII files? Whereas formats like jpg, mp3, avi, eps, obj, out, dll are a clue that we're talking about binary files?
I don't think you can talk about ASCII and BINARY files, but TEXT and BINARY files.
In that sense, these are text files: XML, HTML, RTF, SQL, TEXT, JAVA, CSS, EPS.
And these are binary files: PDF, DOC, XLS, JPG, MP3, AVI, OBJ, DLL.
ASCII is just a table of characters used in the beginning of computing to represent text, but its is nowadays somewhat discouraged since it can't represent text in languages such as Chinese, Arabic, Spanish (word with ñ, Ñ, tildes), French and others. Nowadays other CHARACTER REPRESENTATIONS are encouraged instead of ASCII. The most well known is probably UTF-8. But there are others like ISO-8859-1, ISO-8859-3 and such. Take a look at this article by Joel Spolsky talking about UNICODE. It's very enlightening.
File formats are just another very different issue. File formats are protocols which programs agree on, to represent information. In that sense, a JPG file is an image that has a certain (well know) internal format that allows programs (Browsers, Spreadsheets, Word Processors) to use them as images.
Text files also have formats (I.E., there are specifications for text files like XML and HTML). Its format, as in JPG and other binary files permits applications to use them in a coherent and specific way to achieve something: I.E., render a WEB PAGE (HTML and XHTML file format).
The actual way the file is stored on the hard-drive is defined by the OS. The actual content of the file can be described as array of bytes - each one has up to a byte size possible values.
Text files - will use either the 256 char (ASCII) set - and then you can read them easily or a wider char set - in that case - only suitable apps can read it.
The rest - what you might call binary (and any other formats which is "unreadable" by "text" viewers) - are formats that designed to be read by a certain other apps or the OS.
if it's executable - the OS can read them and execute, others - like jpg - designed to be "understand" by photo viewers ect....
This is an old question but still very relevant. I was confused by this as well, and asked around for clarification. Here's the summary (hope it helps someone):
Format: File/record format is the way data is represented. You might use CSV, TSV, JSON, Apache Log format, Thrift format, Protobuf format etc to represent your data. Format is responsible for ensuring the data is structured properly and correctly represented. Ex: when you read a json file, you should have nested key-value pairs; that's the guarantee always present.
{
"story": {
"title": "beauty and the beast"
}
}
Encoding: Encoding basically transforms your data (in any format or plain text) to a specific scheme. Now, what is this scheme? Scheme is specific to the purpose of encoding. Example, while transferring data over wire (internet), we would want to make sure the above example json reach the other side correctly, should not be corrupted. To ensure this, we would add some meta info like checksum that can be used to verify data's correctness. Other usage of encoding involve shortening data, exchanging secret etc.
Base64 encoding of above JSON example:
ew0KICAgICAgICAic3RvcnkiOiB7DQogICAgICAgICAgICAidGl0bGUiOiAiYmVhdXR5IGFuZCB0aGUgYmVhc3QiDQogICAgICAgIH0NCn0=
I think it is worth noting that with media files, mpeg and others are a form of media codecs. They explain how digital data can express visual and audio. They are generally housed in a media file container such as an avi file which is really a riff file type that is for media.
I have some images (.bmp, .png, .jpg) in my directory. I want to convert this image to WORD array in order to display this image in LCD in 565 formats (16 bit pixel). How to convert an image to WORD array? Please help. Is is there any utility to just convert the image to binary? or Please provide some code in Windows C/CPP to convert it to binary?
This will depend a whole lot on the exact format of the input image.
Just converting "to words" isn't really expressing what you want to do, which is probably more like "convert bitmap images to an array of RGB565 pixels in row-major format".
You should look at image-processing libraries that allow you to load bitmap images, and read out the value of each pixel.
You can probably just convert directly to RGB565, shouldn't be too hard from any other bitmap format.
Note that there are both indexed and "true color" bitmap formats, and you sound like you need to handle both. If you'er lucky, the library for each format will abstract this away and have e.g. auint32 read_pixel_as_rgb888() function.
Also note that many bitmap image formats focus a lot on compression, which is why just reading in the bits of the file is not nearly enough, you need to de-compress the data according to the format. This is quite complex, which is why pre-written libraries are the only sane choice.
For PNG, look at libpng, for JPEG look for libjpeg. On second thought, these libraries might be a bit too low-level, and maybe you should look at something like SDL_Image instead.
You could try to use CImg to open image files - http://cimg.sourceforge.net/
So what I need is simple: I have IplImage* I want to encode it into JPEG and wrap it with some additional JPEG data if needed (JPEG files contain noty only encoded pixels) and put tha file (not saved onto hard drive) into char* buffer. How to do such thing?
JPEG is a complex format. You can use the IJG jpeg library as a base to work with. However, be warned, it is a mess in itself and has a slight learning curve. It is open source, and you'll typically need to configure its build according to your compiler using a provided makefile (which may not be found with the library code itself)