Images

Wherever images come from, G'MIC constructs an internal representation with four dimensional attributes. In principle, these dimensions may have any positive integer measure – millions of pixels and billions of channels, but the amount of memory in your machine sets a practical limit.

Three dimensions are discrete quantities measured in pixels. You are probably familiar with width and height, the rectangular dimensions of an image on a surface. To this G'MIC adds depth, perpendicular to the surface.

With depth, G'MIC images represent volumes, a construct that readily supports tomographic imaging (i.e., CATScans). Video footage also constitutes one image on a G'MIC image list, depth a proxy for time.

A one minute NTSC video, 720x480 pixels shot at 29.97 frames per second, becomes a G'MIC image with a depth of 1798 pixels. Increments along the depth axis are often called slices, a frame in the larger context of a video, and a two dimensional section in the larger context of tomographic imaging.

Images are commonly one pixel deep — one slice — but many G'MIC commands will function in the depth direction as well. For example, the blur command will spread a bright pixel in all directions, including neighboring slices. With depth a proxy for time in videos and animation, blur and other depth-aware commands can produce various animation effects.

The fourth G'MIC dimension is spectral, the number of channels an image may have, also a discrete quantity. Commonly, these are the red, green, blue and transparency components of an image, but G'MIC does not impose this or any other interpretation on the spectral dimension. Particular interpretations arise when images with specific color spaces are input, leading to notions of RGB or CMYK colorspaces, or when particular commands harness specialized images. For example, the warp command employs two channel images called 'displacement fields': one channel represents horizontal displacement at a particular pixel, the other vertical displacement, establishing x and y components of a vector which tells G'MIC how much and in which direction to warp the pixel. In this example the two channels have nothing to do with color. G'MIC's display command happens to render these displacement channels in red and green, but this just the default image projection behavior of the command regarding the initial pair of image channels; the coloring conveys nothing fundamental about displacement fields.

Internally, G'MIC calculates with with thirty-two bit floating point data. Newly input images are automatically converted to this format without requiring explicit action. It is an accommodating format which does not incur much loss during internal calculations.

One doesn't care too much about internal numeric formats until one wishes to put an image elsewhere, perhaps in a file on disk that has a particular image format. The output command, which one uses to put images elsewhere, will pass image data to some format-specific file writer, and 'the right thing,' whatever that means, probably won't happen. That is, your image will seem to be black, or white, or posterized or in funny colors and you will wonder, perhaps out loud, perhaps out louder than necessary, what kind of <insert what you care to here> are those G'MIC people anyway? Someone might point out, after the 'Absolutely No Warrantry Whatsoever' language, that G'MIC is a technical image research tool, the implication being that you need to be smart enough to plan your output strategy; it's assumed that you have some idea how to do that. So, following is some idea how to do that.

There are a couple of aspects to this issue: the depth of an image and the rescaling of its data to an apt range for the target file format. The handling the first aspect, image depth, may happen automatically and unobtrusively if the file format accommodates multiple images. Tagged Image File Format (TIFF) has a concept of pages; each slice will go on a separate page. If the output file format does not support pages or similar constructs (i.e., Portable Network Graphics, among others), then you will need to split any image with more than one slice along the z (depth) axis.This will replace the one image with multiple slices a set of single-sliced images. In writing these and other images on the image list, G'MIC will employ a series of numbered files, foo-000000.png, foo-000001.png, …, one for each item on the image list, to ensure that all items on the G'MIC image list have a unique output file name.

But what about data scale? The dynamic range of floating point numerals is wider than most integer file formats and may range to values less than zero, "blacker than black" for unsigned integer file formats. This aspect requires more thought and a certain amount of upfront planning.

One can kick the issue down the road by employing G'MIC's native .cimg format, which will accommodate images of arbitrary depth, width, height, spectral length and number format. It is not a format many other programs can read, but one may read the .cimg file back into G'MIC later when one becomes ready to choose particular formats. Images as Datasets goes into greater detail, including methods to match the data format and numeric range of images on the pipeline with image file formats.

A Full-Featured Open-Source Framework for Image Processing

Latest stable version: 3.4.3 Current pre-release: 3.4.4 (2024/11/20)

Images

Other Topics