This command is a specialization of the -blur command, one that convolves images only in the depth dimension. As such, it is not especially useful for single-slice images.This command is a specialization of the -blur command, one that convolves images only in the depth dimension. As such, it is not especially useful for single-slice images.
For multiple-slice images, -blur_z convolves an image along the z axis, preserving details along the other two axes. The -display of a small star field, depicted on the left, illustrates the effect. Stars are sharp in the X-Y plane, situated in the upper left quadrant. In contrast, both the Y-Z and X-Z elevations, upper right and lower left quadrants, illustrates how stars smear through the volume's depth. Scrub through this image with the -display command (CTRL-P) and observe how the stars twinkle ( gmic 100,100,100,1 -noise 0.2,2 -blur_z 8,0,0 -display ).
The format of the command is:
-blur_z amplitude[%]>=0,_boundary={ 0=dirichlet | 1=neumann }
There are those here who cannot look at a single pixel without thinking "impulse!", a species of signal which causes convolution kernels to take snapshots of themselves. We noted this effect in the -convolve article; see its 'Application' section.
For us, it means that winking star fields like the one in the introduction can pre-image all kinds of winking things, possibly to horrific effect. However, these stars are nothing if not impulses and convolution can change these into whatever kernel we may harness. So we start with a happy face.
Here is the general plan. Run the -convolve command over a volume of stars that are blurred only along the z-axis, giving the command a happy face kernel (hface.png). Wherever -convolve finds an impulse among the various slices, it will replace that with a happy face. The happy face will reflect the intensity of the inpulse, which waxes and wanes along the z axis, courtesy of the blur_z command. A waxing and waning star then becomes a waxing and waning happy face. Here are the particulars:
gmic -input hface.cimg 360,240,300,1 -noise[-1] 0.02,2 -blur_z[-1] 10,0 \
-to_rgb[-1] -convolve[-1] [0],0,0 -remove[0] -normalize[-1] 0,255 \
-split[-1] z -output /path/to/your/animation.mov
-input hface.cimg 360,240,300,1 -noise[-1] 0.02,2... |
1We establish an image stack with a happy-face kernel in position zero and a black volume with three hundred slices in position one. The latter image consists of monochrome slices, each with just one intensity channel. Into this space, we spread sparse salt-and-pepper noise. |
...-blur_z[-1] 10,0 -to_rgb[-1]... |
2The blur_z command spreads each other-than-black pixel through the depth of the volume, leaving the other axes alone. Viewed along the z axis, this volume would still seem to to consist of pin-point stars, but viewed along the y or x axes, the side-view of stars reveal them to be long strings, waxing from black to white, then waning from white to black. Should we scrub through this volume now, the stars would twinkle, going from black to white and then back to black. Refer to the illustration at the start of this article for a visualization. The -to_rgb command entails a bit of channel matching. Our volume consists of single channels, the kernel is a three channel color image. This command expands the number of channels within each slice of the volume to three. Why didn't we do this at the outset? Had we started with a volume with three channel slices, -noise would have spread red, green and blue pixels, that is, random noise in each channel. We wished to work with white stars, however. That said, you are always free to experiment however you want. Do conjure an image volume with three channels (...360,240,300,3...) and omit -to_rgb, as it would be unnessary in this new scheme. Observe how the faces render out. |
...-convolve[-1] [0],0,0 -remove[0]... |
3The -convolve command takes the kernel, an image of a happy face on the stack at position zero and convolves it with each slice of the of the volume in position one. That is, from left to right, top to bottom, for each slice, the -convolve command moves the kernel image pixel-by-pixel, and, at each, tabulates a pixel-wise multiplication of the kernel and the neighborhood around the pixel. It then sums these pixel-wise products to establish the value of the corresponding output pixel. Truth be told, this command could run for some minutes. Relax, take a potty break, play with the cat. In its travels over slices, the kernel will encounter off-edge pixels; we choose to regard these as zero-valued, indicated by a second parameter flag of zero (Dirichlet policy). We also opt out of a per-slice normalization, third parameter flag zero, as we will be instigating a volume-wide normalization later in the pipeline. Some minutes later, after the potty break and the cat now sick of our company, the -convolve command finishes on the last slice. We remove the kernel image at position zero as we are about to turn the image stack into a series of animation frames and do not wish to incorporate the kernel itself into the series. |
...-normalize[-1] 0,255-split[-1] z -output ... |
4These three commands constitute animation set-up housekeeping. Convolutions will generally leave images with out-of-bound values for eight bit unsigned formats; we scale the image volume to an eight-bit, unsigned range. See "Images as Datasets" for a more detailed explanation. Splitting a three hundred slice volumetric image along the depth axis gives rise to three humdred single-slice images, preparation for the -output command, which, for the video media formats, require frames arrayed as single slice images. Those planning more precise control over the video stream should save the image stack as a numbered sequence of PNG files, to wit: -output /path/to/my/animation.png |