I am working on TIFF images for image compression.
I want to know how is the actual raw image data i.e. R,G,B components organised/stored in the TIFF file.
Is it stored as G0B0R0G1B1R1... (1 byte each for each color component, all components intereleaved)
or is it some other way viz. planar format or something else?
Thank you.
-AD.
TIFF specifies:
How attributes are associated with a page
How multiple pages (and their attributes) are packed into a single file
Page attributes include properties such as:
Dimensions
Encoding scheme
In other words, a TIFF file may contain data that's encoding using any of many different encoding schemes.
The TIFF file can store various image types:
Bilevel (B/W)
Grayscale
Palette-color
RGB full-color
The storing of actual image data is done differently for each image type.
The specification is not the scariest I have seen, but it is definitely not trivial!
The TIFF specification can be found here: http://partners.adobe.com/public/developer/tiff/index.html
I have been doing the same, with tiff files looking at multi resoution tiffs.
Adobe have TIFF 6 documentation on their website.
You should be able to use P/Invoke on LibTiff with c# or vb.net.
Their are many types of compression, some of them proprietary.
Looking at the doc supplied by tomassao, I see that uncompressed RGB is just one of the possible tiff encodings.
It looks like the data is not interleaved. In fact, you can specify more than 3 samples per pixels (but RGB is 3), and you can specify different numbers of bits per sample (but 8,8,8 is common).
I assume you already know about how the headers work. The document covers it if you don't.
Related
I have a PDF file which is made of photographs of a book connected in a single PDF file. I'm trying to convert it back to single images in PNG format, every tool I tried asks me to set DPI which alters the size of resulting images, is there a way to get images of the exact same pixel size the original images were?
Most PDFs of books contain a single image per page and depending on the scanner these images can basically be in three different formats: JPEG, JPEG2000 or TIFF. JPEG2000 is rarely used, so your PDF probably contains JPEG and/or TIFF images.
The good thing about JPEG (and JPEG2000) images is that they can be embedded as-is into a PDF! So you can extract the images as they are stored in the PDF. With TIFF this is also sometimes possible (but I don't think always...).
As mentioned by Tim Roberts you should try using pdfimages or hexapdf images to view and extract the images stored in the PDF. This will give you the best result.
If a Image file is of format .png then it will contain ‰PNG, at the beginning of the file. (when read in Text mode)
If a Image file is of format .bmp then it will contain BM, at the beginning of the file. (when read in Text mode)
I know that Image formats contain text (data) of certain size (bytes) in the beginning of the file, which is used as metadata of the Image file?
My Questions are:-
Is this behavior same in all image file formats (or formats in general)?
Could a image file (of no extension) be recognized just using this data?
Is there information available on how this metadata is broken down? By that I mean, data at which position in the metadata has what meaning?
Is this behavior same in all image file formats (or formats in
general)?
For most of them, yes. There are some proprietary formats (e.g. for games) that might have very short or no metadata. Also, metadata might be in another file (e.g. animations together with XML metadata).
Could a image file (of no extension) be recognized just using this
data?
Yes. In fact, most image viewers will warn you if an image file has an incorrect extension and ask you if they should fix it.
On Unix systems, there's a file command that identifies files based on their metadata. There is a better tool specific for images called identify (part of ImageMagick) that returns more detailed information on resolution, bitdepth, etc.
Is there information available on how this metadata is broken down? By
that I mean, data at which position in the metadata has what meaning?
There are books about (image) file formats and for most formats, this information is available in official specifications (e.g. RFC 2083 for PNG). They list all of the (optional) file contents, describe the compressions and what a viewer/decoder/encoder can/must/should do with the data. A good starting point might be the Wikipedia list of image file formats.
Note that based on the examples you gave I suppose you opened files with a text editor which is not the ideal tool for that task. It's better to use a hex-editor for this. Text editors won't show most bytes (e.g. 255) by default and interprete others (e.g. tab or line feed). They might be good enough to see magic text strings like "BM" and "PNG", but with a hex editor, you can see both these text parts and their numerical representation - e.g. allowing you to extract image width and height. For this, some tool to convert hexademical values to decimal is useful, most calculators can do this.
As an example, let's look at the beginning of a PNG file with a resolution of 6146 x 14293 in both a text editor and a hex editor:
You can see that the file is a PNG image in both of them, that's correct. But the marked part in the hex editor view will show the width and height of the image (matching the PNG chunk specification of the "IHDR" part) - 0x00001802 is 6146 in decimal, 0x000037D5 is 14293. There's no way to do this in the text editor.
Also note that even if you don't know an image format, you might be lucky with just guessing it's uncompressed data (this often works for some game image file formats, most notable Unity's "assets"). E.g. if you rename files to ".raw", the image viewer IrfanView will give you a dialog (see the screenshot below) where you can guess width, height and bit depth of the image and see if the result looks good. This requires some experience in interpreting the outcome though, if width and bitdepth don't match, images will look like noise, warped, or have wrong colors.
This "image geometry guessing" can be improved/automated by trying different widths and computing the correlation coefficent between two lines. The tool raw2tiff can do this. Quote from the site:
There is no magic, it is just a mathematical statistics, so it can be
wrong in some cases. But for most ordinary images guessing method will
work fine.
Using Imagemagick, you can get that information (if available) for formats that Imagemagick can read from its "magick" data in the header file as follows:
convert image -format "%m\n" info:
For example:
convert lena.png -format "%m\n" info:
PNG
convert lena.jpg -format "%m\n" info:
JPEG
convert lena.pnm -format "%m\n" info:
PPM
Even if the suffix is removed, this still works:
convert lena_copy -format "%m\n" info:
PNG
I've a file input like this (only numbers but multi font types). So If I want to use Tesseract for trainning data. I should make a set of one font type in one tiff file or multi font type in one tiff file?
What is better, please show me some tips. Thanks all your helps.
One font style in each training image. Tesseract Training Wiki states the following:
The training data should be grouped by font. Ideally, all samples of
a single font should go in a single tiff file, but this may be
multi-page tiff (if you have libtiff or leptonica installed), so the
total training data in a single font may be many pages and many 10s
of thousands of characters, allowing training for large-character-set
languages.
DO NOT MIX FONTS IN AN IMAGE FILE (In a single .tr file to be
precise.) This will cause features to be dropped at clustering, which
leads to recognition errors.
Using the Quartz 2D PDF routines, can the CGPDFDataFormat format of a CGPDFStreamRef PDF stream be equal to CGPDFDataFormatJPEG2000 in any case other than for an XObject image with a filter of /JPXDecode?
In other words, is the CGPDFDataFormatJPEG2000 format ever used for anything other than JPEG2000 image streams? The reasonable answer would be no, but there can always be a difference between common usage and what's theoretically possible.
JPXDecode filter expects a JPEG2000 image file to be stored in the image XObject, not just compressed raw data. I can say 100% it is always used for image XObjects. But theoretically nothing stops you to wrap your raw content stream data as a JPEG2000 image and then use the JPXDecode filter with a regular content stream. It is just not practical.
I have some raw data in a file that I would like to store in an image file (bmp, jpg, png, or even gif (eegad)). I would like this to be a two way process: I need to be able to reliably convert the image file back later and get a file that is identical to the original file.
I am not looking for a how-to on steganography; the image file will probably be one pixel wide and millions of pixels high and look like garbage. That is fine.
I looked into the Imagemagick utility convert, but am intimidated by the large number of options and terse man page. I am guessing I could just use this to convert from a 'raw' black channel to png, but would have to specify a bunch of other stuff. Any hints? I would prefer to work within Imagemagick or using Linux utilities.
If you are wondering, there's nothing black hat or cloak and dagger about my request. I simply want to automatically backup some important data to a photo-sharing site.
I'd plow into ImageMagick if that's what you'd prefer anyway.
Specific image formats support storing text data to different degrees, and ImageMagick supports all of the formats you mentioned. I'd choose the one that lets you store what you need.