I'm thinking to build a library to manipulate images(my own image type that I will develop), but first I need to understand the structure of a image
How it is mounted?
About the layer technology...
Where I can find some good resources to understand these things?
Thanks.
That all depends on the image format in question.
Most image formats, however, consist of the following:
A header that contains general file information (how long, what format, dimensions, color space, compression algorithm, etc.)
The pixel data (potentially compressed, in which case some other structure may apply)
Other metadata (EXIF, ...)
Many popular image formats such as JPEG or PNG have freely available specifications of the file format.
If you actually want to work with more complex images, containing layers and such (possibly Photoshop or similar) then things get more difficult. They additionally contain layers, so multiple chunks of pixel data, maybe metadata for the layers, in the case of Photoshop even vector data (for layer masks and other paths), etc.
What's more, most primary file formats used by major proprietary image editing software tend to be not fully specified, at least not publicly. There are resources out there but expect them to be incomplete at best.
Still, starting a project like this without much prior knowledge of image file formats in general might not be a feasible idea.
A good start to everyone that needs to know the basics about digital images is the chapter 2 of the classic book by Gonzalez and Woods, Digital Image Processing.
A short answer, roughly speaking: for manipulation in memory, images are 2D arrays. There are lots of variants, but the 2D array is the classic way.
For C, C++ and Python, take a look on OpenCV. For Python, see PIL. For Java, see JAI. Finally, to a overview about an "image structure", take a close look inside IplImage structure in OpenCV documentation.
Image file formats vary wildly. However, depending on which language/platform you're coding against, you may have generalized means of working with images and translating them into the format you chose. Each platform will have its own means of building and accessing images, however, so there's little I can tell you of substance without a declaration of your programming platform of choice.
Personally, I prefer C#/.NET. So here are some links on image manipulation in that platform:
http://www.aspfree.com/c/a/C-Sharp/Basic-Image-Manipulation-using-GDI-and-C/
http://www.aspfree.com/c/a/Code-Examples/Handling-Animation-and-Bitmaps-Using-GDI-for-Image-Manipulation/
Each image format, has a differant structure and comprresion.
Maybe you should explain in more detail your goals.
A quick amazon search yields a couple of books that could be very useful on the subject. Both are based around openGL, one of the most common graphic libraries. The first is a general introduction to computer graphics sort of text book and the second is a manual for openGL (commonly known as the red book).
Computer Graphics with OpenGL (3rd Edition)
OpenGL Programming Guide (The Red Book)
I can personally attest to the usefulness of both books.
If you're interested in the innards of various image file formats wotsit is a pretty good start. If you prefer hardcopy then go to the Encyclopedia of Graphics file formats. And if you want to look at sample sourcecode check out imagemagick. It can open-, convert to-, and save- most popular image file formats written in C++ with interfaces to most other languages.
Unless you're doing something very unique, I would encourage you to use an existing file format. Look at PNG or TIFF. They are incredibly flexible.
As a veteran in the field, I would say that the last thing the world needs is a new image file format. ;-)
Related
I am new to d3 geo. My task is to make a map of Boston and add some interactive features to it.
So far I've been able to get an outline of Boston. But the base map should be comparable to something you'd see in Google Maps - it should have buildings, roads, street names and city names, rivers, etc. A basic geography that makes the region more familiar.
For now, I don't need to pan, and may have just two or three zoom states.
All the visualizations I've seen that overlay interactive features onto maps like this seem to use images for the underlying maps: windhistory, polymaps, google maps and more. So I guess my questions are:
Why do some maps use images for the "backdrop"? Is it just the easiest way to build on top of existing maps? Is it more performant?
If I go with the images approach, are there any limitations to the features I can add? I'm hoping to do things like windmaps, animations, heatmaps, etc.
What are the copyright implications for using images? I imagine the answer to this is, "depends on which images I use," but are there some standard libraries that have no strings attached? For example I know if I use Google Maps, I have to display their logo, there's an API limit, etc. Are there any standard sources that are completely open?
Are there any examples where geography is added purely through TopoJSON?
Sorry if some of these seem obvious, but I am completely new to maps and just don't know the standard practices. Thanks for any help!
A quick take on your questions. Hopefully someone with more mapping experience can give you more detail:
Why do some maps use images for the "backdrop"?
File size and computation time, mostly. Drawing complete maps with buildings, roads, and topography requires a lot of data and a lot of time for the browser to render it. If your browser DOM gets too complicated, it can slow down all interactions even after the original drawing.
If I go with the images approach, are there any limitations to the features I can add?
There's a reason most interactive maps use multiple layers. The background images are best for the underlying "lay of the land" type imagery, anything you want to be interactive should be on top with SVG.
What are the copyright implications for using images?
If you're using someone's images, you have to follow their licence. You might want to look at the OpenStreetMap project.
Are there any examples where geography is added purely through TopoJSON?
I suppose that depends on what you mean by "geography"; Mike Bostock has generated topoJSON for a variety of features based on US Atlas data.
As for whether it makes sense: TopoJSON encodes paths/boundaries directly, and encodes regions as the area enclosed by a set of boundaries. You could use it to encode streets and rivers and even building outlines, but you're not saving any file size relative regular GeoJSON because those paths generally aren't duplicated the way that region boundaries are. Relative to using image tiles, any improvement in file size would be countered with increased processing time.
I really want to learn how an image is composed (i.e. array of bits, or however, how is the color composed for each pixel, etc). Can you point me in the right direction? I'm not really sure what to search for.
Thanks a lot in advance.
So what I want to do is to be able to modify the picture pragmatically, i.e. change to black and white, scale it, crop it, etc, and for this I would really like to learn how the image is composed instead of just finding these algorithms online.
You don't always need to know low level mathematical details(matrixes,quantisation,fourier transform etc.) of graphic formats to manipulate images.
For all the things you want to do you may use proper libraries.
For example in PHP libraries used freuqently to manipulate images are:
GD - http://php.net/manual/en/book.image.php
ImageMagick - http://php.net/manual/en/book.imagick.php
It depends on the image format that you're interested in manipulating. Each format (more or less) is composed in a different manner, and based on that has a different set of capabilities for manipulating the image.
Different sets of actions on an image favor different image formats, as does the type of image you want to manipulate.
Provide more details about what you want to do with the image and I'm sure someone else will come along and tell you which formats are best and how they are handled.
Does anyone has recommendation of data structures for relative large maps with high resolution, something like 400mile x 400mile with 10-15ft resolution. Using 2D array, that would be roughly 2Mx2M cells.
The map only needs to store the elevation and terrain (earth, water, rock, etc.), and I don't think storing tiles is a good strategy.
Thank you!
It depends on what you need to do with it: view it, store it, analyze it, etc...
One thing I can say, however, is that that file will be HUGE at your stated resolution, and you should consider splitting it up into at least a few tiles, even better at 1x1 mile tiles.
The list of raster formats supported by GDAL could serve as a good starting point for exploring various formats, keeping in mind that many software packages (GRASS, ArcGIS, etc. use GDAL to read and write most raster formats). Note also that some file formats have maximum sizes which may prevent you from using them with your very large file.
For analysis and non-viewable storage, HDF5 format might be of interest.
If you want people to see the data as a map over the web, then creating small image tile overlays will be the fastest approach to sharing such a large dataset.
I need to compare 2 same-size, nearly identical images for exact differences in the RGBs of every pixel.
I would like to find a tool that already does it... seems nowhere to be found on google, strangely.
If I could even find a tool to print out the RGB values of every pixel I could compute it by hand (the images are small enough) or load that input for my tool. Again, couldn't find anything.
Otherwise I look for a simple C library to decode GIFs and access each pixel... recommendations? I see quite a few on google, most look old and have no documentation.
I hope someone with more exposure to image processing can help me solve this this somewhat trivial task in one way or another without spending too many hours!!
If you have ImageMagick installed, it already does it.
What about SDL + SDL_Image (main site)?
You can easily open GIFs and load them on SDL_Surfaces to retrieve the pixel information you need..
If you're not opposed to Python, one option would be to use the Python Imaging Library (PIL), which provides Python bindings for native decoders for many file formats, including PNG and GIF.
This past summer, I wrote a few small apps to do RGB-wise comparisons of PNG images, in C++, pure Python, and Python using PIL. It would be trivial to make the PIL code work with GIF images.
If you want to roll your own, the "standard" C library for simple image manipulation is GD.
Beyond Compare will do image comparisons and highlights differences.
http://www.scootersoftware.com/
In medical imaging, there appears to be two ways of storing huge gigapixel images:
Use lots of JPEG images (either packed into files or individually) and cook up some bizarre index format to describe what goes where. Tack on some metadata in some other format.
Use TIFF's tile and multi-image support to cleanly store the images as a single file, and provide downsampled versions for zooming speed. Then abuse various TIFF tags to store metadata in non-standard ways. Also, store tiles with overlapping boundaries that must be individually translated later.
In both cases, the reader must understand the format well enough to understand how to draw things and read the metadata.
Is there a better way to store these images? Is TIFF (or BigTIFF) still the right format for this? Does XMP solve the problem of metadata?
The main issues are:
Storing images in a way that allows for rapid random access (tiling)
Storing downsampled images for rapid zooming (pyramid)
Handling cases where tiles are overlapping or sparse (scanners often work by moving a camera over a slide in 2D and capturing only where there is something to image)
Storing important metadata, including associated images like a slide's label and thumbnail
Support for lossy storage
What kind of (hopefully non-proprietary) formats do people use to store large aerial photographs or maps? These images have similar properties.
It seems like starting with TIFF or BigTIFF and defining a useful subset of tags + XMP metadata might be the way to go. FITS is no good since it is basically for lossless data and doesn't have a very appropriate metadata mechanism.
The problem with TIFF is that it just allows too much flexibility, but a subset of TIFF should be acceptable.
The solution may very well be http://ome-xml.org/ and http://ome-xml.org/wiki/OmeTiff.
It looks like DICOM now has support:
ftp://medical.nema.org/MEDICAL/Dicom/Final/sup145_ft.pdf
You probably want FITS.
Arbitrary size
1--3 dimensional data
Extensive header
Widely used in astronomy and endorsed by NASA and the IAU
I'm a pathologist (and hobbyist programmer) so virtual slides and digital pathology are a huge interest of mine. You may be interested in the OpenSlide project. They have characterized a number of the proprietary formats from the large vendors (Aperio, BioImagene, etc). Most seem to consist of a pyramidal zoomed (scanned at different microscopic objectives, of course), large tiff files containing multiple tiled tiffs or compressed (JPEG or JPEG2000) images.
The industry standard is DICOM Sup 145; getting vendors to adopt it though has been sluggish, but inventing yet another format would probably not be helpful.
PNG might work for you. It can handle large images, metadata, and the PNG format can have some interlacing, so you can get up to (down to?) an n/8 x n/8 downsampled image pretty easily.
I'm not sure if PNG can do rapid random access. It is chunked, but that might not be enough.
You could represent sparse data with the transparency channel.
JPEG2000 might be worth a look, some interesting efforts from National libraries in this space.