Is it possible to create a raw image in Fortran? I was thinking BMP but not really sure what extension would be best.
Basically, I want to be able to have an array or a text file that contains the color values for each pixel, so a 3 pixel wide red image would just be FF0000FF0000FF0000 or something similar to that
You could use the PPM format. http://en.wikipedia.org/wiki/Netpbm_format
Aspect 1: you have to know the format of the image file. Then you write that format. Likely any standard image files (PPM, BPM, TIFF,...) will include some sort of header. This is inherent in writing a standard image file, independent of the language.
Aspect 2: Fortran 2 used to be relentlessly record oriented, even for unformated (binary) files, which didn't "play" nicely with files written by other languages such as C, or file formats specified without the record deliminators expected by Fortran. But the new Stream I/O method produces non-record files. An image file will be unformatted (binary), so in the open statement include:
access='stream', form='unformatted', ....
Yes, you can create a PNG using our gtk-fortran binding (GNU GPL v3) which includes interfaces to the GdkPixbuf library. A pixbuf is a 1D array containing the RGB intensities of each pixel of the image.
Note that it is possible to just use the GdkPixbuf library (~20 lines of code), without building a GTK gui:
https://fortran-lang.discourse.group/t/making-computer-graphics-in-fortran-without-gui-just-creating-a-png/70
https://github.com/vmagnin/gtk-fortran/wiki
You just need a Fortran compiler (Fortran >=2003).
Related
IPA image uses pngcrush to compress PNG image, but I want to uncrush a PNG image on Ubuntu.
Can anyone give me any idea?
The standard PNG utility pngcrush has been modified by Apple, which makes it produce technically invalid PNGs: a new chunk is inserted before the mandatory first chunk IHDR, RGB(A) order of pixel data is inverted, and RGB pixels get premultiplied with their alpha.
Hence, I'd rather call these PNGs "fried", rather than just "crushed".
Try my own pngdefry. The source code is written on a Mac OSX machine but it should be compilable for other OSes as well; it's pretty straightforward C code.
Is there any way to stamp or overlap a tiff image on a existing PDF file and output the result using Ghostscript?
I have two PDF which i want to merge in a result PDF with one over the other using ghostscript. I want to know if this can be done and how, or if it may work with one PDF as tiff image on top of the base PDF.
Can ghostscript make this stamp using layers in the PDF?
Thank you for your answers
The pdfwrite device in Ghostscript doesn't really support layers, so you can't use that. Also its unclear why you think layers would help.
TIFF isn't part of PostScript (or PDF), so you can't directly read a TIFF file into GS. I have elsewhere posted a PostScript program which reads TIFF files and renders them for output. You could use that to read a TIFF file.
However, you would have to mess about with either the PDF interpreter or a custom EndPage procedure in order to read and render the TIFF file. And unless you take specific kinds of action, it will be opaque, which may well not be what you want.
The Ghostscript PDF interpreter doesn't really lend itself to this kind of manipulation, have you considered using pdftk instead ?
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.
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.
What is the preferred way to convert various images, bitmap and vector, for use in a LaTeX and PDFLaTeX document?
There are many ways to do this, some make use of standard inclusions in the various LaTeX packages, others give better results.
You can include a PDF image directly into a LaTeX document if you want to produce your final output using pdflatex, but not if you want to produce a dvi file.
pdflatex can use PDF, PNG, and JPEG
latex/dvips can use PS, EPS
See more details:
Including images in LaTeX files
Watch what you name graphics files in LaTeX
I convert bitmaps into PNG, and vector graphics (e.g. SVG) into PDF. pdflatex understand both PNG and PDF.
If you have an image "as PDF", and you don't want to include it as pdf, you may want to extract the complete image data first with pdfimages. Other conversions may render the image only with reduced resolution.
My current preferred way is using bmeps and epstopdf included in MikTeX. For the generation of pdf and eps versions of a png.
In a file called convertimage.bat,
bmeps -p3 -c -e8f -tpng %1.png > %1.eps
epstopdf %1.eps
Use by including in the path and writing convertimage.bat filenameminusextension
Include in the documents using,
\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.25]{path/to/fileminuxextension}
\caption{My caption here}
\label{somelabelforreference}
\end{center}
\end{figure}
I only use Encapsulated PostScript (.eps) figures (converting bitmaps with NetPBM first), since I always use dvips + ps2pdf anyway, and then I do \includegraphics{file}.
As John D. Cook says, your available image formats depend on whether you are using latex or pdflatex.
I find ImageMagick a useful tool for converting images between formats. Handles bitmap images, plus ps/pdf/eps (with ghostscript) and a zillion others. Available through apt, macports, etc.
I use a mac so I use GraphicConverter to load images and export as PDFs.
When I draw diagrams, I use Omnigraffle which lets me export as PDFs.
On windows I used to use Visio which supported EPSs which I also had no problems embedding.
The basic issues are that a) you want to handle raster and vector images differently and b) this introduces potential pitfalls.
The "right" thing to do depends a bit on your final output.
If your final output is going to be a .pdf file, and you don't need pstricks or anything else that these days you're probably better off just using pdflatex to directly produce the file.
In this case:
store all vector figures as .pdf
store all raster figures as .png (or jpeg if they were originally jpeg)
use graphicx package and \includegraphics{filename-without-suffix}
If you don't do the above, your raster figures will be converted to jpegs and may gain compression artifacts. png is the best bet if you can choose output.
If you are headed for .dvi file you're going to want .eps for everything. (You can gzip these files as long as you generate a bounding box file).
If you're careful you can do both. I store all vector figures as (compressed) .eps because there are a few things .pdf can't do that .eps can. I store all raster figures as .png. Using make, I can have temporary copies of these canonical versions generated on the fly for .dvi or .pdf output as needed.
Someone above pointed out the filename issue. You want to avoid "." in the file names, and avoid suffixes always in your latex file itself.
I always include images in PNG format.
If you compile your code with pdflatex, then you also can use the \includegraphics to include images in pdf (you have to include the package graphix