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 want to convert some pages in a PDF to grayscale
I can use the ghostscript option -sPageList to select the desired pages.
But the output contains only the selected pages.
How can I get the whole PDF including the converted pages?
You cannot do this in one pass with Ghostscript and the pdfwrite device.
The colour conversion options are applied to all the selected output pages, so you need to start by using the PagesList to output the pages you want colour converted. You can use the '%d' format specifier to get each page as a separate file. You can then 'split' the pages you didn't colour convert from the original file by doing the 'opposite' PagesList and using %d again to get each page in a separate file.
Now you have each page as a separate PDF file, some colour converted, some not.
Finally you can feed Ghostscript with each of the PDF files, in the desired order, to create a new PDF file which contains all the pages in the order you want.
Thanks to #KenS for the clarification.
Here's a Python script that does all this: https://gist.github.com/michaelosthege/a6cc9556ff4e2b64d5f7d3aaee43be70
→ Determinining which pages to convert
→ Extracting each page in colored/grayscale
→ Merging them all back into one PDF
For some reason I am expecting a strange behaviour.
When I am merging my docx template with opentbs, it works all fine and it looks correct in the generated docx.
But now I need to convert the docx into a pdf where I am using unoconv and libreoffice on mac OS X 10.11.
when I do this, all strings with multiple lines (which are displayed correctly in the docx) will be displayed as single line in the pdf.
Also if I open the generated docx with libreoffice, all multi line strings will be displayed as single line.
I figured out, that I can use ;strconv=no.
This will then do exactly the opposite. All multi line strings in the docx will be displayed as single line, but in libreoffice or converting to pdf with unoconv they are displayed correctly with multi lines.
anyone has a solution for this problem?
I need to convert a PDFPreserveLayout to text file in Mapreduce,I am using PDFBOX to convert a normal pdf file to text file,but it is not working for pdfpreservelayout.
Can any one help in solving this issue?
I'm doing a document scanning project that involves inserting a scanned image into an existing PDF template page that contains form fields. I've used ImageMagick to take process the scan, and then append a raster image of the form template to the bottom, and convert that image into a PDF. However, forms and checkbox fields have to be added manually to the resulting PDF. Below is a sample of my ImageMagick command.
convert inputScan.jpg -resize 975x420 FormTemplate.png -append CombinedFile.pdf
Ideally, I would run a command that would take the JPG scan and the PDF template file containing fields, and output a PDF file with the scan at the top of a page and the field-containing template text below it. The closest thing I could find to a solution was here, but PHP can't be used on the computer in question.
Any help or suggestions are greatly appreciated!