CBM image file format: what is it? how to read it? - image

I have a collection of images in the CBM file format.
What is this format? How to read it? How to convert it to, say, a BMP bitmap?
Searching the net, I found that it could mean one of those three things:
1) Fuzzy Bitmap, as per Michael Mauldin's library, FBM (1989). The softwares XnView and Graphics Convert Pro 2011 should be able to open it, but they don't. Most likely it means that the file I have is not really a Fuzzy Bitmap.
2) Compiled bitmap, as per XLib (wikipedia)
How to proceed in order to test that my file is such a Compiled Bitmap? Where to download XLib / what should I build?
3) Compressed Bitmap. Do you have more info's on this format?

I found CreateDIBitmap function. If you pass correct parameters, you should be able to save it into some more known file format.
Here you can find something about Bitmap Compression.
If you don't know image details like resolution, bitsperpixel, compression type,... It will be hard to read it.

I believe CBMs are just Zip files renamed. Try renaming and unzipping.

try to open it with konvertor (www.konvertor.net); it does read several CBMs formats

Related

How to convert image to integer array? (do not use any non-standard library)

How to convert image.png or image.bmp to integer array? (do not use any non-standard library)
Please ignore chunks that are not directly related to image data.(IHDR、IEND...etc.)
thank you very much.
SOLVED: I should use binary I/O function in stdio.h to read image file. thanks
If you have to read images into arrays without any image processing libraries you need two things:
You need means to read files in general.
You need to know the internal structure of the file formats you want to read.
So for png refer to https://www.w3.org/TR/2003/REC-PNG-20031110/
This document will tell you where to find the image dimensions, pixel data and other features. It's basically a manual for software developers on how to use this standard format properly.
Some image formats will require additional work like decrompression.

How can I convert a extremly big .dat file to Image files?(Like jpg or something)

I have a folder of image file which have been compressed into .dat file. Since the .dat files are extremly huge(They are the microscopic image of the organ.), I don't really know what kind of tools that I can use to convert it into jpeg file. So the best case would that the whole image is split up into pieces, and I can get all the pieces of the image.
The ".dat" file suffix is used broadly, so you'll need to specify more details on what format/source software created the original data. As a guess, from a quick search of ".dat" format microscopy, these tools looks like they might be applicable to your domain:
http://gwyddion.net/
or
http://www.openmicroscopy.org/site/products/bio-formats
If you can't find a library for the format/languages you are using, then you'll need to find documentation of the file format, and write a converter (at least, the reading portion of the converter - you can use something like libjpeg to handle the writing portion.)

Are there alternatives to CGPDFContext?

I am aiming to combine multiple PDF files each with identical dimensions into one file.
I've seen how it is done with CGPDFContext. I am just curious if there are (better?) alternatives to this method on the Mac.
Let's say I have the option to use PDFs, TIFF, PNG or JPEG files as input. Would using a different input file type mean anything significant for the process, or it would be easier to go with PDF input?
I have use PDFDocument API and it is programmatically easier to use. It may need PDF files as input though.

I need to write a .DDS file cross-platform, can someone point me to example?

I need to create a .DDS file with code that runs on both OSX and Windows. Although the format doesn't look difficult, I'd still like an example of writing the file. Note I don't need to read it, just write it.
C or C++ and RGBA bitmap.
I finally resorted to written a RAW file, and using GraphicConvertor (mac) to read it and write the DDS file. I think Photoshop can do it too. RAW files are simply RGB or RGBA or similar formats written straight to a binary file. Then in the reading application you tell it the dimensions so it can read it in. Then you export to whatever. Not a perfect solution but it worked for what I needed.

Is there a way to infer what image format a file is, without reading the entire file?

Is there a good way to see what format an image is, without having to read the entire file into memory?
Obviously this would vary from format to format (I'm particularly interested in TIFF files) but what sort of procedure would be useful to determine what kind of image format a file is without having to read through the entire file?
BONUS: What if the image is a Base64-encoded string? Any reliable way to infer it before decoding it?
Most image file formats have unique bytes at the start. The unix file command looks at the start of the file to see what type of data it contains. See the Wikipedia article on Magic numbers in files and magicdb.org.
Sure there is. Like the others have mentioned, most images start with some sort of 'Magic', which will always translate to some sort of Base64 data. The following are a couple examples:
A Bitmap will start with Qk3
A Jpeg will start with /9j/
A GIF will start with R0l (That's a zero as the second char).
And so on. It's not hard to take the different image types and figure out what they encode to. Just be careful, as some have more than one piece of magic, so you need to account for them in your B64 'translation code'.
Either file on the *nix command-line or reading the initial bytes of the file. Most files come with a unique header in the first few bytes. For example, TIFF's header looks something like this: 0x00000000: 4949 2a00 0800 0000
For more information on the TIFF file format specifically if you'd like to know what those bytes stand for, go here.
TIFFs will begin with either II or MM (Intel byte ordering or Motorolla).
The TIFF 6 specification can be downloaded here and isn't too hard to follow

Resources