For in-memory images, there are several possible formats, basically according to the number of bits per pixel, which in general can range from 1 (black or white) up to 32 (8 for red, 8 for green, 8 for blue and 8 for the alpha). The most common are:
1 bit per pixel - Black or white.
2 bits per pixel - Black, white and 2 shades of gray.
4 bits per pixel - 16 shades of gray.
8 bits per pixel - 256 grayscale.
2 bits per pixel - Black, white, cyan and magenta.
2 bits per pixel - Black, white, green and red.
4 bits per pixel - 16 basic colors chosen according to a color palette. Usually these colors are black, white and two shades of each of these colors: gray; blue; red; green; yellow; cyan and magenta.
8 bits per pixel - 256 colors chosen arbitrarily from a palette/table.
16 bits per pixel - Capable of representing 65536 distinct colors. Of these bits, we have 5 for the red component, 6 for the green component, and 5 for the blue component. Bit order can be RGB (red-green-blue) or BGR (blue-green-red).
24 bits per pixel - capable of representing 16777216 distinct colors. 8 bits are used for each color component. The order of the bits can be RGB or BGR.
32 bits per pixel - Same as the case of the 24 bits per pixel, but adding a byte to represent the transparency, or more precisely the alpha, which is opacity, the opposite of transparency. A alpha zero indicates full transparency, while a alpha of maximum value (255 in this case) indicates a totally opaque color. The concept of transparency/opacity is useful when you want to draw images on each other. Bit order can be ARGB, RGBA, ABGR or BGRA.
File formats such as PNG, GIF, JPG, PCX, BMP, TGA, TIF, PGM, PPM, PBM, etc are often compressed and not all directly represent pixels. They have wide differences between themselves and each one has a unique format and quite different from the others. For example:
Some formats, such as BMP, PGM and PPM, represent pixels directly and sequentially.
PNG uses a compression with some similarities with ZIP.
There are formats (e.g., GIF) where there is a header with a palette/color table and each color is a number from 0 to 255 according to the table. In this case we can have 0=blue, 1=orange phosphorescent, 2=green moss, 3=golden... Depending on how the table is.
Analog TV broadcasts use two components for color (color) and one for brightness (luminance), to be compatible with black-and-white TV formats that only had brightness. This same concept is also used in JPG.
There are formats that use some very complicated mathematical techniques that arise from the need to represent information that represents waves (with frequency, amplitude and phase) in the form of discrete and compact points. From this comes the fast transformation of Fourier and the discrete transformation of cosine. They are frequent in converting analog to digital formats and also to squeeze as much information about the image as possible into the smallest possible area. JPG, for example, uses the cosine discrete transform.
Therefore, treating pixels directly in many of these formats is difficult, and it suits much more you read the files, converting them into bitmaps directly in memory and then manipulating these pixels directly in memory.
In practice, it is not worth worrying too much about the file formats, it is worth using a library ready to read and write images in these formats and then only worry about bitmaps in memory.
As our colleague Luiz Vieira mentioned in comments, Opencv is a very rich and widely disseminated library that already has many of these things ready to use.
Does it have to be in Assembly? The tag doesn’t quite match what you ask for in the text. Also, one thing is manipulating bitmaps in memory, another is saving and reading files - often they are different formats.
– Victor Stafusa
Hello Paul, welcome to SOPT. First of all, know that this site is not a forum. Your question would need to have a more objective question. If you haven’t done it yet, do the [tour] and read [Ask]. When you say " [...] material talking about the functioning of the bytes or pixels of a low-level image." What do you mean by "low-level"? Despite mentioning Assembly, the rest of the question seems to indicate that you want to know what the formats common image storage. If this is the case, I suggest you take a look here: https://en.wikipedia.org/wiki/Image_file_formats
– Luiz Vieira
The bitmap format is reasonably well specified. See here and here, for example. In every way, There’s plenty of stuff ready for what you want to do. You have already tried to study a little Opencv, for example? A link suggestion that can serve as a good introduction: https://www.youtube.com/watch?v=-Hb7ZFSYqnk
– Luiz Vieira
The manipulation of bitmaps in working memory is irrelevant at the moment, since the text inquires about file manipulation. Assembly is a low-level assembly language, because although it is human-readable, it communicates directly with devices, since most architectures have their own version of Assembly, and their respective communication drives. Therefore, the topic not only deals with Assembly, but also drives written about. The point is: what I want it for. If you know ways to do the want at the highest level, I would like you to share it.
– Paulo Sérgio Duff
Paul, I really did not understand your doubt. You now mention "drives for communication". Ask if anyone knows "ways to do what they want" at the highest level... But what do you want?! It’s not clear. Try to edit the question and make it more focused. It would be your wish to simply know how to read/write a bitmap file to Assembly?
– Luiz Vieira
If you want to manipulate image files and images in memory are irrelevant to you, then why Assembly? Assembly will in practice only manipulate images in memory and almost no one will worry about using Assembly directly to read or write files, since this is something that high-level languages can do with excellence.
– Victor Stafusa
This was in response to user Victor Stafusa about contesting the use of the Assembly tag. It is not an explanation of my doubt. But if my doubt is not clear, I will try to speculate what is possibly unclear. If you can advance that part, it will help me edit and improve my question.
– Paulo Sérgio Duff
Paul, the question I’m asking is what to know in Assembly won’t help you. The algorithms for reading and writing images in PNG, GIF, JPG, TIF, PCM, PCX, TGA, BMP or the format you prefer are unrelated to Assembly and any programming languages can be used to manipulate them. In particular, Assembly would be one of the worst possible choices for this because it’s not very portable and compilers are able to write Assembly much better than most humans could. [continues]
– Victor Stafusa
[continuation] Normally these algorithms are implemented in C, but I’ve seen them done in Delphi, Java and Python as well. The Assembly would be useful maybe in the part of drivers, but the drivers do not manipulate files, they only manipulate bitmaps in memory that you made it clear that are not your interest.
– Victor Stafusa
Ah, and if you want to do things like facial recognition, the best thing would be to read the file, put it in memory and do the recognition right in memory. The reason for this is that in various file formats, the pixels are not encoded there directly. For example, JPG uses a very complicated mathematical technique called fast transformation of Fourier to compress and reduce the file size. On the other hand, uncompressed in memory, it will be in an easy manipulation format for what you want.
– Victor Stafusa
No. Facial recognition (in the sense of what I want) is just one of the possible extra advantages (which you explained would not be advantageous in this way).
– Paulo Sérgio Duff
What I want is to recognize pixel patterns in a file, or know how Assembler treats it (to make it easier to recognize these patterns). What can I get out of this.......... I put here the possibilities....! !
– Paulo Sérgio Duff
Let’s go continue this discussion in chat.
– Paulo Sérgio Duff