| home / infca / raw (navigation links) | Foix : es quan dormo que hi veig clar. |
| Picss | URLs | End |
Vector graphics tools are critical to press-oriented publications. Unlike bitmap (or "raster") images, vector graphics are built for the precision print media tend to demand. Line art, extraneous design graphics, and body text for print copy all benefit from the scalability and accuracy vector graphics introduce to design work.
From "CorelDraw 9 for Linux: A vector graphics tool with punch. url
List of Linux Tools
Tinc 2 fotos de 262.144 bytes en Blanc i Negre. Jo els dic "RAW", cru, sense format : tenen 512 linies de 512 punts, cadascun de 1 byte, donant 256 nivells de gris.
Son :
La pregunta, ara, es : quin format te un fitxer JPG ? BMP ?
On diu el tamany ? (ample x alt)
Feina : eina per passar JPG a RAW (512x512), passant segurament per BMP.
Eina : el SuperJPG por "Guardar" en format JPG, GIF, TIF, PNG i BMP.
|
|
|
|
|
A .BMP file contains of the following data structures:
BITMAPFILEHEADER bmfh ; // File header (14 bytes) BITMAPINFOHEADER bmih ; // Info header (40 bytes) RGBQUAD aColors [] ; // called COLOR TABLE (not PALETTE). BYTE aBitmapBits [] ; |
BITMAPFILEHEADER structure is like
this :
typedef struct tagBITMAPFILEHEADER { // 14 bytes :
WORD bfType ; // 2 bytes : "BM"
DWORD bfSize ; // 4 bytes : file size in bytes
WORD bfReserved1 ; // 2
WORD bfReserved2 ; // 2
DWORD bfOffBits ; // 4 : file offset to raster data
} BITMAPFILEHEADER, * PBITMAPFILEHEADER ;
|
|
BITMAPINFOHEADER structure is like
this :
InfoHeader might be : 12 bytes (OS/2 1.x), 40 bytes (Windows) or 64 bytes (OS/2 2.x) : URL or URL
typedef struct tagBITMAPINFOHEADER { // 40 bytes :
DWORD biSize ; // 4 - size of InfoHeader = 40
LONG biWidth ; // 4 - bitmap width
LONG biHeight ; // 4 - bitmap height
WORD biPlanes ; // 2 - number of planes (=1)
WORD biBitCount ; // 2 - bits per pixel
// 1 = monochrome => NumColors = 1
// 4 = 4bit palletized => NumColors = 16
// 8 = 8bit palletized => NumColors = 256
// 16 = 16bit RGB => NumColors = 65536
// 24 = 24bit RGB => NumColors = 16M
DWORD biCompression ; // 4 - type of compression
// 0 = BI_RBG, no compression
// 1 = BI_RLE8, 8bit RLE (run length) encoding
// 2 = BI_RLE4, 4bit RLE encoding
// 3 = RGB bitmap with mask
DWORD biSizeImage ; // 4 - compressed size of image
// can be set to 0 if Compression = 0
LONG biXPelsPerMeter ; // 4 - horizontal resolution : pixels/meter
LONG biYPelsPerMeter ; // 4 - vertical resolution : pixels/meter
DWORD biClrUsed ; // 4 - number of actually used colors
DWORD biClrImportant ; // 4 - number of important colors (0 = all)
} BITMAPINFOHEADER, * PBITMAPINFOHEADER ;
|
RGBQUAD structure is like
this :
typedef struct tagRGBQUAD {
BYTE rgbBlue ; { 1 - specifies the blue part of the color }
BYTE rgbGreen ; { 1 - specifies the green part of the color }
BYTE rgbRed ; { 1 - specifies the red part of the color }
BYTE rgbReserved ; { 1 - must always be set to zero }
} RGBQUAD;
Present only if Info.BitsPerPixel <= 8.
Colors should be ordered by importance.
|
|
Writing a bitmap to a BMP file is fairly simple
if we have a handle to device-independent bitmap.
We simply write BITMAPINFOHEADER information
followed by the contents of the bitmap.
The three fields that we have to set in the BITMAPINFOHEADER
are the bfType which should always be "BM",
the bfSize which is the size of the bitmap
including the infoheader and the bfOffBits which is
the offset to the bitmap bits from the start of the file.
// WriteDIB - Writes a DIB to file
// in :
// szFile- Name of file to write to
// hDIB- Handle of the DIB
// out :
// Returns- TRUE on success
BOOL WriteDIB ( LPTSTR szFile, HANDLE hDIB ) {
BITMAPFILEHEADER hdr ;
LPBITMAPINFOHEADER lpbi ;
if ( ! hDIB )
return FALSE ;
CFile file ;
if( ! file.Open ( szFile, CFile::modeWrite | CFile::modeCreate ) )
return FALSE ;
lpbi = (LPBITMAPINFOHEADER) hDIB ;
int nColors = 1 << lpbi -> biBitCount ;
// Fill in the fields of the file header
hdr.bfType = ((WORD) ('M' << 8) | 'B') ; // is always "BM"
hdr.bfSize = GlobalSize ( hDIB ) + sizeof( hdr ) ;
hdr.bfReserved1 = 0 ;
hdr.bfReserved2 = 0 ;
hdr.bfOffBits = (DWORD) ( sizeof( hdr ) + lpbi -> biSize + nColors * sizeof( RGBQUAD ) ) ;
// Write the file header
file.Write ( & hdr, sizeof ( hdr ) ) ;
// Write the DIB header and the bits
file.Write ( lpbi, GlobalSize ( hDIB ) ) ;
return TRUE ;
}
|
|
What made the BMP format successful was its support for indexing through 4 and 8-bit palettes. Rather than storing each of the necessary RGB values for each pixel, Microsoft instead added first a fixed and then a customisable palette to its BMP format. Each pixel's colour could then be defined by storing its associated index number rather than the much longer RGB value. This look-up table approach is inherently more efficient for handling images with up to 256 colours as each pixel can be stored in eight bits of information rather than twenty four. Microsoft was able to further optimise the BMP format by tying it even more closely to Windows' API, adding features such as control over which colours to dither when images are viewed on limited colour displays. From here |
See here or here or here (BITMAP.H, BITMAP.C, BMPVIEW.C)
Another important thing is that the number of bytes in one row must always be adjusted to fit into the border of a multiple of four. You simply append zero bytes until the number of bytes in a row reaches a multiple of four.
Pixels are stored bottom-up, left-to-right !
{Juny 2011} Canon, EOS 1100D.
Fotos B/N ?
Links |
|---|
|
|
|
Site under construction. |
|
Updated 20130115.
|
|