|Adam2016: "I also notice that when I open a normal .txt file in a hex editor(wxhexeditor), there is absolutely no metadata, the first byte of the file is just text and again there is no trailers, it's just ASCII text data. So how do text editors such as nano,vim and other text editors open this type of text file when there is no info that even identifies them as one(text file)?"|
Most modern OS's have done a lot of work to kind of hide from the users what file formats really are; most users expect files to act a certain way without wanting to know how it's done.
Much of the work is done trusting in the file extensions themselves. A txt file is expected to have no header and no added tail (which is why you can use Notepad on Windows to write html files and trust that no extra data will be added that will mess up its loading by a browser.
A png file is binary data with a header that describes how to access that data, and the magic number is required to identify the format. All of this is expected to be accessed in binary mode as described by Jonin.
For the most part formatting is an attempt to make the data OS independent/shareable, and to help figure out what the file actually should do because you can trust that somewhere out there is a user who just modified that extension thinking they are actually changing a mp3 file into an mkv (because again, windows and other modern OS's hide what data actually is, and the user doesn't always understand or care about what hides inside).
Vim is not exactly a smart program. It has many ways to extend it and is extremely useful, but if you open a png file with vim it will try to read all available text. It will generally look like garbage because it's binary data rather than text data. But you will see the word PNG near the top, since that's actually what part of the magic number translates to in binary to ascii.
If you want to represent the data in a png as hex using vim, then check out the answer here: https://vi.stackexchange.com/questions/2232/how-can-i-use-vim-as-a-hex-editor
That won't actually be very helpful because a png usually is compressed as well and the extraction method is as described in the aforesaid header for each png. And as Jonin points out, hex isn't quite useful in this instance anyways. Things get even more fun when you try to read a pdf by the way, since chunks of data in a pdf can be under different forms of compression and encryption and the chunks aren't necessarily in the same order as it is displayed on screen.
There is a program available on linux called "file". Try reading the man page for file since it describes how it works, and it sounds like it is just about what you are trying to create...
Here's the official git repo for the "file" program: https://github.com/file/file
This is a good route to study, it's very helpful to be able to ensure that the file you are reading is in fact the format that you are expecting.
Here's someone's example of writing a simple bmp without external libraries https://stackoverflow.com/questions/2654480/writing-bmp-image-in-pure-c-c-without-other-libraries/47785639#47785639
“The good thing about standards is that there are so many to choose from.” ― Andrew S. Tanenbaum