ABOUT THE PixelSquarer DROP-IN FOR PHOTOSHOP:

The processing module should be placed with your other drop-ins, and will appear in the Filter/Other submenu. The first time it is selected, it displays a dialog that asks for the source and target dimensions. These are integer values. As for the Prism drop-in above, they are used to adjust the horizontal dimension of each line so that the pixels are square. For instance, if you have acquired an image of a test grid or other object that is known to have the same vertical and horizontal dimension, you can measure (in pixels) the height and width in the digitized image. Assume that your particular camera and digitizing board produce values of 411 pixels for the height and 424 pixels for the width. You would enter 424 as the source and 411 as the target. The function of the drop in will be to adjust the horizontal scale of the image so that the distances become equal. Note that it does not matter whether the ratio is greater than or less than 1.0; the program will handle either case. Of course, for accuracy purposes, it is wise to measure a fairly large dimension object to determine the required scaling. The magnitude of the numbers in the fields is not important - only their ratio. On subsequent calls using command-F, PixelSquarer filter will use the same values without displaying the dialog (the same as other Photoshop filters that require a user input). If the image is expanded horizontally in the process of adjustment, some pixels will disappear from the right edge of the original image. If the image is contracted horizontally (as in the example above), a band of white pixels will appear along the right hand edge. PixelSquarer for Photoshop works for 8 bit grey scale images and for 24 bit RGB images. It will work on any region of interest, or by default on the entire image.

ABOUT THE PixelSquarer DROP-IN FOR PRISMVIEW:

The drop-in should be placed in your System folder with the other 'PCMD' files. Use ResEdit to enter the scaling factor into the resource. Open the file with ResEdit, and open the 'scal' resource number 128. This resource has two integer fields - the source (numerator) and target (denominator) values. Assume that you have carefully measured the image of a truly square object, and its height and width are not equal. The vertical height is (for instance) 379 pixels and the horizontal width is (for instance) 371 pixels. Then you would enter 371 as the source and 379 as the target. The function of the drop in will be to adjust the horizontal scale of the image so that the distances become equal. Note that it does not matter whether the ratio is greater than or less than 1.0; the program will handle either case. Of course, for accuracy purposes, it is wise to measure a fairly large dimension object to determine the required scaling. The magnitude of the numbers in the fields is not important - only their ratio. Then save and close the file, and place it at the root level of your system folder with any other Prism PCMDs. It will appear as PixelSquarer in your menu. Select it to adjust the current frontmost image. If the image is expanded horizontally in the process of adjustment (as in the example above), some pixels will disappear from the right edge of the original image. If the image is contracted horizontally, a band of black pixels will appear along the right hand edge. The routine may be applied to a rectangular region of interest or by default to the entire image.

Both drop-ins are Copyright © 1994 Analytical Vision, Inc. All Rights Reserved.
They may be freely used and distributed provided that this information and the copyright notices in the dialogs are included.

----------------------
By way of explanation, here is the e-mail description of the problem and solution:

To: nih-image@soils.umn.edu
From: russ@mat.mte.ncsu.edu
Subject: Re: Pixel Aspect Ratio

Regarding the ongoing thread about non-square pixels, Kurt Scudder writes:
>...
Assume that a camera chip has square pixels. As I understand it, each line of video is generated by clocking a row of pixels into some analog circuitry which generates a voltage analog of the intensities in that row. That line of video is then resampled by the frame grabber. What happens if the number of samples taken by the frame grabber across a line of video is not the same as the number of CCD elements which gave rise to that line? Since each row of CCD elements gives rise to one line of video, there can be no lack of registration in that axis - one row of CCD elements ends up as one row of pixels in the final image. So unless the frame grabber manufacturer knows exactly (and he cant) how many pixels in the CCD, there is no possibility of coming up with an aspect ratio of 1:1, except by accident. Is this right? If not, where's the hole in my logic?
----
In fact, the number of transistors in the CCD array is not a factor, which is revealed by the fact that vidicon and other tube cameras consist of a sensor that is essentially a continuous coating. Many chip cameras have more or fewer than 640 discrete sensors. The width of each scan line, whatever type of sensor the voltage information comes from, is determined by the electronic circuitry in the camera. This in turn is controlled by a clock circuit and defined by one of a series of standards. For instance, in the US the number of lines and the clock frequency is RS170 (also a part of NTSC which is the color tranmission standard). It does not have anything to do with "pixels" of course, since video is an analog signal. It does specify an overall aspect ratio for the image of 4:3 (width:height), which is why many digitizers sample this into a 640:480 grid to get "square" pixels. The digitizers do this by using another high frequency clock circuit to control the sampling rate along each scan line. The aspect ratio of HDTV will be different (16:9).

The problem of "non-square" pixels arises because a) small distortions in the aspect ratio of images are not objectionable to television viewers; hence b) the specs on the camera tranmission signal are not too tight; and c) in any case there are different clocks being used by the camera and the board, and so there will inevitably be some mismatch. The specs allow several percent variation, and there may also be some temperature effect due to the crystals used in the various circuits. Any particular combination of camera and board will produce some variation of the aspect ratio and hence of the "squareness" of the pixels. This is a well-known and old problem - see for instance the Inoue book on video microscopy.

The only practical way to deal with this using consumer-level electronics is to adjust the stored image afterwards. Since the variable is the time base on which the horizontal lines are produced and then digitized, it makes the most sense to treat the vertical dimension as fixed and adjust the horizontal scale. This is also the most efficient way to process the data, considering the way pixel data are stored in memory. This resampling should be done using interpolation, of course. To determine the correct factor, you should acquire a test image of known squareness (depending on the magnification, a piece of graph paper or a stage micrometer can be used). Then measure the vertical and horizontal dimension in pixels in the stored image (not, obviously, how it appears on the video screen, since this can also have arbitrary analog adjustments). The ratio will generally be pretty constant for a given camera and board combination.

Applying this correction is kind of slow in the standard scaling function in Image, and requires entering the value each time. Programs such as Photoshop typically do not offer precise numerical control over stretching functions. I use a drop-in for Prism that is speed-optimized, and takes under 1 second on pretty much any Mac to stretch or contract the image horizontally to make the pixels square. The factor is stored in a resource, and so once you enter it you can just call the drop-in and --zap-- its done. If you have more than one camera and/or board, save several versions of the drop-in with unique names. The Photoshop drop-in is a bit slower because of the Photoshop overhead, but will handle both rgb color and grey scale images. It allows user input of the dimensions to be used.

Two "PixelSquarer" drop-ins, one for Prism and one for Photoshop, are available on my ftp site. They may be used by anyone who has discovered that they have this problem. I hope this settles this line of discussion.

The ftp site is ftp.ncsu.edu, and the directory is pub/ncsu/jruss. You can also download the demo of Prism from there.