I have a file with a sequence of NxM unsigned integral values of fixed width - let's even assume they're single bytes - and I would like to "wrap" in some kind of common image file format. Preferably, something usable with popular image viewers; and otherwise with an image editor like GIMP.
What image format would require the minimum amount of conversion work, i.e. be as close as possible to just slapping some small header onto the raw data?
Notes:
This is a grayscale/intensity image - there are no color channels / interleaved values etc.
I don't care if the image format is row-major or column-major, i.e. if the image appears transposed relative to the order I wrote the data originally.
I've just noticed the Portable Pixmap Formats, which include the PGM format. The closest I've seen to a spec is on this page.
PGM files are supported by apps such as: Eye of Gnome (on Linux), IrfanView (on Windows), GIMP and others.
Create the image file programmatically
If I understand correctly, the following C function should convert the raw data OP has into a PGM file:
void write_pgm(FILE* file, size_t width, size_t height, uint8_t* data)
{
const char magic = "P5"; // for binary graymap
fprintf(file, "%2s %zu %zu 255\n", magic, width, height);
fwrite(data, 1, width * height, file);
}
This is a variation on a similar function for a PPM, here.
You can easily adapt this to whatever programming language you like.
Converting a file
So, suppose you've put your output in a file on disk. Apparently, there's a utility for making a PGM of it: rawtopgm. Here's a invocation for your case:
rawtopgm -bpp 1 -maxval 255 N M my_data_file > out.pgm
or, exploiting defaults:
rawtopgm N M my_data_file > out.pgm
pretty simple.
Related
How can I write in a buffer (unsigned char*) with MagickWand?
Currently I generate an image and save it to file, but I need it in memory:
MagickNewImage( wand, 640, 480, p_wand );
MagickWriteImage( wand, "test.jpg" );
According to the documentation there is a function MagickGetImageBlob that returns unsigned char * which is seemingly what you are looking for. Its exact documentation is
MagickGetImageBlob() implements direct to memory image formats. It returns the image as a blob (a formatted "file" in memory) and its length, starting from the current position in the image sequence. Use MagickSetImageFormat() to set the format to write to the blob (GIF, JPEG, PNG, etc.).
Note that this does require you to set the format using MagickSetImageFormat, but on the whole this seems to be the closest thing to what you are looking for.
In file text.txt I have this sentenc:
"Příliš žluťoučký kůň úpěl ďábelské ódy."
(I think Windows uses Windows-1250 code page to represent this text.)
In my program I save it to a buffer
char string[1000]
and render string with ttf to SDL_Surface *surface
surface = TTF_RenderText_Blended(font, string, color);
/*(font is true type and support this text)*/
But it gives me not correct result:
I need some reputation points to post images
so I can only describe that ř,í,š,ž,ť,ů,ň,ď are not displayed correctly.
Is it possible to use ttf for rendering this sentence correctly?
(I tried also TTF_RenderUTF8_Blended, TTF_RenderUNICODE_Solid... with worse result.)
The docs for TTF_RenderText_Blended say that it takes a Latin-1 string (Windows-1252) - this will be why it isn't working.
You'll need to convert your input text to UTF-8 and use RenderUTF8, or to UTF-16 and use RenderUNICODE to ensure it is interpreted correctly.
How you do this depends on what platform your app is targeted to - if it is Windows, then the easiest way would be to use the MultiByteToWideChar Win32 API to convert it to UTF-16 and then use the TTF_RenderUNICODE_Blended to draw it.
My solution will be this:
Three input files. In first file there will be a set of symbols from czech alphabet.
Second file will be sprite bitmap file where graphic symbols will be sorted in the
same order as in first file. In my program symbols from third input file will be compared with symbols from first file and right section of sprite will be copied on sreen one by one.
I will leave out sdl_ttf. It has some advantages and disadvantages but I think it will work for my purposes.
Thanks for all responses
This is format description of Vray's .vrscene file:
http://spot3d.com/vray/help/maya/sdk22/vrscene_format.html
I interested in paragraph about "Compressed hexadecimal lists". There is said that compressed list equals to header ("ZIPB") + uncompressed size + compressed size + zlib compressed string.
For example, in my .vrscene I have such compressed list: "ZIPB2C01000015000000e7X81OT0TG4S5ENN3D8Z8IVAPODONF7EA"
It means that "e7X81OT0TG4S5ENN3D8Z8IVAPODONF7EA" -- zlib compressed string. But I dont know how to decompress it. When I do Base64 decode I receive header 0x7bb5. I dont know such a header. Maybe I shouldnt use Base64 and should do something other instead?
So I know this is old, but the information in here was enough to get me to a solution, the only difference being that I have a different compressed list from a different vrscene file.
As you established, you need to remove the first 20 characters from the string since they are just descriptors used by vray and not part of the compressed data.
import base64, zlib
data = "ZIPCB81900003C000000eAHt0iERAAAMxLDC9694MkYCaqCXVZMHDDDAAAMMMMAAAwwwwAADDDDAAAMMMMAAAwwwwMC7gQMbojNx"
encoded_data = data[20:] #"eAHt0iERAAAMxLDC9694MkYCaqCXVZMHDDDAAAMMMMAAAwwwwAADDDDAAAMMMMAAAwwwwMC7gQMbojNx"
compressed_data = base64.b64decode(encoded_data)
hex_data = zlib.decompress(compressed_data)
# b'\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00...'
Once you are at this point you have the raw hexidecimal list without any compression. If you want to turn that into readable python data types you can use struct to unpack them depending on what data type is stored in the list.
Further reading in the documentation that was linked explains that all such lists are stored as 4 bytes per entry (written as 8 half-bytes in the docs, but as far as python is concerned it's just 4 bytes). With that information we can determine that the number of entries in the list should be the length of the hex_data / 4 and build a struct format string that will unpack the whole list at once.
import struct
#I have a list of ints as my example, but for floats you could use "f" instead
format = "i" * int(len(hex_data)/4)
values = struct.unpack(format, hex_data)
# [8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, ...]
There are also Color lists and Vector lists, but they are just float lists that need to be unflattened.
vectors = []
for i in range(0, int(len(values)), 3):
vectors.append(tuple(values[i:i+3]))
Since this method seems to be working with all of the compressed hex lists I've been encountering up to this point it seems like there is either an issue with the file you were originally trying to parse data from, or the developers were using an encoding method other than base64 at one point but have adopted base64 encoding since then (Perhaps that's the reason for "ZIPC" appearing in my files as opposed to "ZIPB in your example).
The documentation says hexadecimal, but the string you provided has other characters. It is probably not base64, since you don't get a valid zlib header at the start. (By the way, I get 0x7b 0xb5 when I decode it with base64, not what you got. But either way, it's not a zlib header.) Do you have a better source for the description of the format?
The data must have been highly compressible, e.g. all zeros, since it apparently went from 4140 bytes to 21 bytes.
i got a question for reading an bmp image. How can i get the pixel value(R, G, B values) in an bmp image?
Can anyone help me using the C programming language?
Note: you may need to grab an extra byte for the alpha values if your BMP has alpha channel. In that case image would be image[pixelcount][4], and you would add another getc(streamIn) line to hold that fourth index. My BMP turned out to not need that.
// super-simplified BMP read algorithm to pull out RGB data
// read image for coloring scheme
int image[1024][3]; // first number here is 1024 pixels in my image, 3 is for RGB values
FILE *streamIn;
streamIn = fopen("./mybitmap.bmp", "r");
if (streamIn == (FILE *)0){
printf("File opening error ocurred. Exiting program.\n");
exit(0);
}
int byte;
int count = 0;
for(i=0;i<54;i++) byte = getc(streamIn); // strip out BMP header
for(i=0;i<1024;i++){ // foreach pixel
image[i][2] = getc(streamIn); // use BMP 24bit with no alpha channel
image[i][1] = getc(streamIn); // BMP uses BGR but we want RGB, grab byte-by-byte
image[i][0] = getc(streamIn); // reverse-order array indexing fixes RGB issue...
printf("pixel %d : [%d,%d,%d]\n",i+1,image[i][0],image[i][1],image[i][2]);
}
fclose(streamIn);
~Locutus
The easy way would be to find a good image manipulation library for your chosen platform and use that.
Linux ImLib / GDK-Pixbuf (Gnome/GTK) / QT Image (KDE/Qt) should be able to do what you need.
Windows I'm not familiar with the appropriate system library, but an MSDN Search for "Bitmap" is probably a good place to start.
Mac OSX Cocoa has some image manipulation capabilities, see this article.
The hard way would be to open the file and actually interpret the binary data within. To do that you'll need the BMP File Specification. I'd recommend trying the easy way first.
You need to study the BMP file format. It is easier to read uncompressed 24-bit BMP files. They just contain a header at the beginning and RGB values of each pixel.
To start with this, check the example of 2x2 bitmap image at http://en.wikipedia.org/wiki/BMP_file_format. Follow the below steps.
Create the 2x2 BMP image shown on Wikipedia.
Open the file in binary mode using your C program.
Seek to byte position 54.
Read 3 bytes.
The bytes would be 0, 0 and 255 respectively. (Not sure whether the order is RGB. I had done this long back and I think the order is not RGB. Just verify this.)
As simple as that! Study the header of the BMP to understand more about the format.
I'm trying to get the Spot color information from a TIFF file, it normally shows up under 'channels' in Photoshop. Each extra channel would have a name, which is usually a Pantone swatch name, and a CMYK equivalent.
So far, I'm getting the TIFFTAG_PHOTOSHOP with libtiff, and stepping through the blocks within. I'm finding the IRB WORD 0x03EE, which gives me the channel names, and IRB WORD 0x03EF which gives me their color equivalents...
BUT the color equivalents are in CIELab format (Luminance, and two axis of color space data) so I'm trying to use littleCMS to convert just a few TIFF packed Lab color to CMYK.
My question: Is there an easier way? The CMYK is just an approximation of the Pantone, so if there was a quick rough translation from Lab to CMYK, I would use it.
The answer was to use the photoshop docs to parse out the binary photoshop block in the tiff file and grab the fields I needed with bit manipulation.
littleCMS did the job of LAB -> CMYK just right.