bmp file, access to data - c++

this is a bmp file header:
unsigned char header[54] = {
0x42, // identity : B
0x4d, // identity : M
0, 0, 0, 0, // file size
0, 0, // reserved1
0, 0, // reserved2
54, 0, 0, 0, // RGB data offset
40, 0, 0, 0, // struct BITMAPINFOHEADER size
0, 0, 0, 0, // bmp width
0, 0, 0, 0, // bmp height
1, 0, // planes
24, 0, // bit per pixel
0, 0, 0, 0, // compression
0, 0, 0, 0, // data size
0, 0, 0, 0, // h resolution
0, 0, 0, 0, // v resolution
0, 0, 0, 0, // used colors
0, 0, 0, 0 // important colors
};
Now, how can i access data in a .bmp file and store them to an array?

The bitmap header is a section in the file that holds information about the image and type of bitmap. If you want to read the individual pixels of a 24-bit bitmap file, you gather information about its size from the header, and then you use that to traverse the file and get your data.
From the header, you can clearly see that the pixel data starts at position 54 in the file. This is a 24-bit bitmap, so each pixel is represented by 3 bytes.
You also need to put padding into account. If the width of a bitmap is not divisible by 4, filler bytes are added to. +Correction: if the width * (bytes-per-pixel) is not divisible by 4.
If you really want to see how a bitmap is structured and to make it easier to visualize when you code this, get a hex editor and create small bitmap files and open them in the hex editor. You can see how the bytes are arranged and where the header begins and ends, among other information.

Related

win32 PIXELFORMATDESCRIPTOR color bit count and color bit shift

So in creating a context for openGL using win32 I have found this generic pixel format descriptor that everyone seems to be referencing. However after looking at the documentation I have found that the documentation for the color bits and color bit shifts does not describe how to actually format the buffer, and I cannot find any more information online.
Is there some place I can get more information on the color bit count and color bit shifts function, or have a description of how they work.
PIXELFORMATDESCRIPTOR pfd =
{
sizeof(PIXELFORMATDESCRIPTOR),
1,
PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER, // Flags
PFD_TYPE_RGBA, // The kind of framebuffer. RGBA or palette.
32, // Colordepth of the framebuffer.
0, 0, 0, 0, 0, 0,
0,
0,
0,
0, 0, 0, 0,
24, // Number of bits for the depthbuffer
8, // Number of bits for the stencilbuffer
0, // Number of Aux buffers in the framebuffer.
PFD_MAIN_PLANE,
0,
0, 0, 0
};

SDL - how to render text from an alpha-only bitmap?

I'm trying to render text using SDL. Obviously SDL does not support rendering text by itself, so I went with this approach:
load font file
raster glyphs in the font to a bitmap
pack all bitmaps in a large texture, forming a spritesheet of glyphs
render text as a sequence of glyph-sprites: copy rectangles from the texture to the target
First steps are handled using FreeType library. It can generate bitmaps for many kinds of fonts and provide a lot of extra info about the glyphs. FreeType-generated bitmaps are (by default) alpha channel only. For every glyph I basically get a 2D array of A values in range 0 - 255. For simplicity reasons the MCVE below needs only SDL, I already embedded FreeType-generated bitmap in the source code.
Now, the question is: how should I manage the texture that consists of such bitmaps?
What blending mode should I use?
What modulation should I use?
What should the texture be filled with? FreeType provides alpha channel only, SDL generally wants a texture of RGBA pixels. What values should I use for RGB?
How do I draw text in specific color? I don't want to make a separate texture for each color.
FreeType documentation says: For optimal rendering on a screen the bitmap should be used as an alpha channel in linear blending with gamma correction. SDL blending mode documentation doesn't list anything named linear blending so I used a custom one but I'm not sure if I got it right.
I'm not sure if I got some of SDL calls right as some of them are poorly documented (I already know that locking with empty rectangles crashes on Direct3D), especially how to copy data using SDL_LockTexture.
#include <string>
#include <stdexcept>
#include <SDL.h>
constexpr unsigned char pixels[] = {
0, 0, 0, 0, 0, 0, 0, 30, 33, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 1, 169, 255, 155, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 83, 255, 255, 229, 1, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 189, 233, 255, 255, 60, 0, 0, 0, 0, 0,
0, 0, 0, 0, 33, 254, 83, 250, 255, 148, 0, 0, 0, 0, 0,
0, 0, 0, 0, 129, 227, 2, 181, 255, 232, 3, 0, 0, 0, 0,
0, 0, 0, 2, 224, 138, 0, 94, 255, 255, 66, 0, 0, 0, 0,
0, 0, 0, 68, 255, 48, 0, 15, 248, 255, 153, 0, 0, 0, 0,
0, 0, 0, 166, 213, 0, 0, 0, 175, 255, 235, 4, 0, 0, 0,
0, 0, 16, 247, 122, 0, 0, 0, 88, 255, 255, 71, 0, 0, 0,
0, 0, 105, 255, 192, 171, 171, 171, 182, 255, 255, 159, 0, 0, 0,
0, 0, 203, 215, 123, 123, 123, 123, 123, 196, 255, 239, 6, 0, 0,
0, 44, 255, 108, 0, 0, 0, 0, 0, 75, 255, 255, 77, 0, 0,
0, 142, 252, 22, 0, 0, 0, 0, 0, 5, 238, 255, 164, 0, 0,
5, 234, 184, 0, 0, 0, 0, 0, 0, 0, 156, 255, 242, 8, 0,
81, 255, 95, 0, 0, 0, 0, 0, 0, 0, 68, 255, 255, 86, 0,
179, 249, 14, 0, 0, 0, 0, 0, 0, 0, 3, 245, 255, 195, 0
};
[[noreturn]] inline void throw_error(const char* desc, const char* sdl_err)
{
throw std::runtime_error(std::string(desc) + sdl_err);
}
void update_pixels(
SDL_Texture& texture,
const SDL_Rect& texture_rect,
const unsigned char* src_alpha,
int src_size_x,
int src_size_y)
{
void* pixels;
int pitch;
if (SDL_LockTexture(&texture, &texture_rect, &pixels, &pitch))
throw_error("could not lock texture: ", SDL_GetError());
auto pixel_buffer = reinterpret_cast<unsigned char*>(pixels);
for (int y = 0; y < src_size_y; ++y) {
for (int x = 0; x < src_size_x; ++x) {
// this assumes SDL_PIXELFORMAT_RGBA8888
unsigned char* const rgba = pixel_buffer + x * 4;
unsigned char& r = rgba[0];
unsigned char& g = rgba[1];
unsigned char& b = rgba[2];
unsigned char& a = rgba[3];
r = 0xff;
g = 0xff;
b = 0xff;
a = src_alpha[x];
}
src_alpha += src_size_y;
pixel_buffer += pitch;
}
SDL_UnlockTexture(&texture);
}
int main(int /* argc */, char* /* argv */[])
{
if (SDL_Init(SDL_INIT_VIDEO) < 0)
throw_error("could not init SDL: ", SDL_GetError());
SDL_Window* window = SDL_CreateWindow("Hello World",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
1024, 768,
SDL_WINDOW_RESIZABLE);
if (!window)
throw_error("could not create window: ", SDL_GetError());
SDL_Renderer* renderer = SDL_CreateRenderer(window, -1, 0);
if (!renderer)
throw_error("could not create renderer: ", SDL_GetError());
SDL_Texture* texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_RGBA8888, SDL_TEXTUREACCESS_STREAMING, 512, 512);
if (!texture)
throw_error("could not create texture: ", SDL_GetError());
SDL_SetTextureColorMod(texture, 255, 0, 0);
SDL_Rect src_rect;
src_rect.x = 0;
src_rect.y = 0;
src_rect.w = 15;
src_rect.h = 17;
update_pixels(*texture, src_rect, pixels, src_rect.w, src_rect.h);
/*
* FreeType documentation: For optimal rendering on a screen the bitmap should be used as
* an alpha channel in linear blending with gamma correction.
*
* The blending used is therefore:
* dstRGB = (srcRGB * srcA) + (dstRGB * (1 - srcA))
* dstA = (srcA * 0) + (dstA * 1) = dstA
*/
SDL_BlendMode blend_mode = SDL_ComposeCustomBlendMode(
SDL_BLENDFACTOR_SRC_ALPHA, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD,
SDL_BLENDFACTOR_ZERO, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_ADD);
if (SDL_SetTextureBlendMode(texture, blend_mode))
throw_error("could not set texture blending: ", SDL_GetError());
while (true) {
SDL_SetRenderDrawColor(renderer, 255, 255, 0, 255);
SDL_RenderClear(renderer);
SDL_Rect dst_rect;
dst_rect.x = 100;
dst_rect.y = 100;
dst_rect.w = src_rect.w;
dst_rect.h = src_rect.h;
SDL_RenderCopy(renderer, texture, &src_rect, &dst_rect);
SDL_RenderPresent(renderer);
SDL_Delay(16);
SDL_Event event;
while (SDL_PollEvent(&event)) {
switch (event.type) {
case SDL_KEYUP:
switch (event.key.keysym.sym) {
case SDLK_ESCAPE:
return 0;
}
break;
case SDL_QUIT:
return 0;
}
}
}
return 0;
}
Expected result: red letter "A" on yellow background.
Actual result: malformed red lines inside black square on yellow background.
I suspect that lines are broken because there is a bug within pointer arithmetics inside update_pixels but I have no idea what's causing the black square.
First of all, part of this stuff is already done in SDL_ttf library. You could use it to rasterise glyphs to surfaces or generate multichar text surface.
Your src_alpha += src_size_y; is incorrect - you copy row by row, but skip by column length, not row length. It should be src_size_x. That results in incorrect offset on each row and only first row of your copied image is correct.
Your colour packing when writing to texture is backwards. See https://wiki.libsdl.org/SDL_PixelFormatEnum#order - Packed component order (high bit -> low bit): SDL_PACKEDORDER_RGBA, meaning R is packed at highest bits while A is at lowest. So, when representing it with unsigned char*, First byte is A and fourth is R:
unsigned char& r = rgba[3];
unsigned char& g = rgba[2];
unsigned char& b = rgba[1];
unsigned char& a = rgba[0];
You don't need custom blending, use SDL_BLENDMODE_BLEND, that is 'standard' "src-alpha, one-minus-src-alpha" formula everyone uses (note that it does not blend dst alpha channel itself, nor uses it to any extent; when blending, we only care about src alpha).
Finally one more approach to this: you could put your glyph luminance value (alpha, whatever it is called, the point is it only have one channel) and put it into every channel. That way you could do additive blending without using alpha at all, don't even need RGBA texture. Glyph colour could still be multiplied with colour mod. SDL_ttf implements just that.

Build a QImage from a buffer

How I can build a QImage from a buffer for example?
In this case I'm using a buffer of 3x3 with vale from 0 (black) to 255 (white).
0 255 0
255 0 255
0 255 0
and it is store into a unsigned char buffer[9] = {0, 255, 0, 255, 0, 255, 0, 255, 0};
At the moment I'm trying this but doesn't work:
QImage image{buffer, 3, 3, QImage::Format_Grayscale8};
The constructor you're using...
QImage(uchar *data, int width, int height, QImage::Format format, QImageCleanupFunction cleanupFunction = nullptr, void *cleanupInfo = nullptr)
has the caveat...
data must be 32-bit aligned, and each scanline of data in the image
must also be 32-bit aligned
Hence the QImage implementation expects the number of bytes in each scanline to be a multiple of 4 -- a condition not satisfied by your data buffer. Instead make use of the constructor that allows you to specify the bytes-per-scanline explicitly...
QImage(uchar *data, int width, int height, int bytesPerLine, QImage::Format format, QImageCleanupFunction cleanupFunction = nullptr, void *cleanupInfo = nullptr)
So your code becomes...
unsigned char buffer[9] = {0, 255, 0, 255, 0, 255, 0, 255, 0};
QImage image{buffer, 3, 3, 3, QImage::Format_Grayscale8};

How to use c++ array at run time and change the values it holds?

Very novice question here.
So I have this int array and using sfml I've used this int array to map textures to the screen in a grid like structure. I was wondering how you would go about knowing what square you're mouse is above in the array at run time.
int mapArr[] = {
0, 0, 0, 0,
0, 0, 0, 0,
0, 0, 0, 0,
0, 0, 0, 0
}
^something like so.
So using something like below will change the top left most square to a different texture.
mapArr[0] = { 1 };
int mapArr[] = {
1, 0, 0, 0,
0, 0, 0, 0,
0, 0, 0, 0,
0, 0, 0, 0
}
So how would I implement this based on if my mouse was above the top left square and want to do something like mapArr[0] = { 1 }; at runtime?
https://gist.github.com/jbax86/94ee0b326a30f4dd80efbb33791f6728
// 25x15 array for 800x600 display are my settings.
int mapArr[];
int MouseToMap(int x, int y, int val)
{
mapArr[25 * y + x] = val;
};
// at a calling location inside main somewhere.
// for sfml I put it in the event listening part of loop.
// 25 is tiles across not 0 indexed,
// 32 is tile width of tile in pixels.
sf::vector2i mVal = sf::Mouse::getPosition(window);
MouseToMap(mVal.x / 32, mVal.y / 32, 3);

confused with bytes, blocks, en-/decoding in c++

I have a 64-byte block and want to append a 64 Bit (8 Byte) Block of data at the end.
typedef unsigned char uint1; // 1 Byte
typedef unsigned int uint4; // 4 Byte
// The 64 Byte-Block:
int BLOCKSIZE=64;
static uint1 padding[BLOCKSIZE] = {
0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
// [[10000000][00000000].........[00000000]]
// The 64 Bit (8 Byte-Block):
uint4 appendix[2] = {};
appendix[1] = 0x000000ff;
// [[00000000000000000000000000000000][00000000000000000000000011111111]]
after memcpy 8 bytes from appendix to the last 8 byte of padding
memcpy(&padding[56], &appendix, 8);
it looks like
static uint1 padding[BLOCKSIZE] = {
0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0, 0
};
but shouldn't it look like this?
static uint1 padding[BLOCKSIZE] = {
0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff
};
I don't know whats wrong here!?!?
Can you help me?
appendix[1] = 0x000000ff;
// [[00000000000000000000000000000000][00000000000000000000000011111111]]
You're making assumptions about the byte order (endianness). You can't make such assumptions. Depending on byte-order of the architechture, appendix could alternatively be represented like this:
// [[00000000000000000000000000000000][11111111000000000000000000000000]]
If you want to set the last byte specifically, then you need to operate on bytes, not multi-byte integers. Like this for example:
uint1 appendix[8] = {};
appendix[7] = 0xff;
If you indeed need the last 8 bytes to represent two 4 byte integers, your code is correct in that regard and only your assumption about what the memory should look like is wrong.
If the integer must be in a particular byte order for sending it over network, then you must convert it appropriately. POSIX provides htonl and it's sister functions for exactly that. The functions are also provided by msvc.
You're also making the assumption that unsigned int is 4 bytes. It's not guaranteed to be. Use int32_t instead if you need a 4 byte integer.
Update:
My Goal is to implement MD5 and I need to append a 64 bit representation of the length of a file.
According to rfc1321:
... a sequence of
bytes can be interpreted as a sequence of 32-bit words, where each
consecutive group of four bytes is interpreted as a word with the
low-order (least significant) byte given first.
MD5 is little endian. Therefore writing a 2*4 array without converting the byte order will work correctly only on a little endian processor.
I recommend using a 8*1 byte-array so that you can control the order of the bytes exactly as the specification requires. Alternatively, if you're on linux or another platform that provides them, you could use htole32 and le32toh functions to convert to the correct byte order. On another platform you may need to implement them yourself.
So, as far as I'm able to understand the RFC1321 I need a 64 Bit Integer representation of the original message (file) size. The file size is 64 Byte. In a 64 Bit Integer the value 64 is in binary either:
0000000000000000000000000000000000000000000000000000000001000000
or:
0000001000000000000000000000000000000000000000000000000000000000
I have decoding funcitons for both, but i don't know which is right for md5 ?
You should look at Endianless. Your option is big-endian here.