Image extension ambiguities in v2.11.1

Doug Tody wrote on Jan 06, 1998

Another discussion of the image naming issue.


---------- Forwarded message ----------
Date: Sun, 4 Jan 1998 23:30:54 -0800
Subject: Image extension ambiguities in v2.11.1

We have recently installed v2.11.1 for solaris 2.6.

There seems to be a significant and debilitating problem relating
to a change in the way that IRAF assigns a default image extension
when it is not specified.

Previously, if files "image.imh" (and "image.pix"), and "image.pl"
both existed, and "imtype=imh", then operations such as
	display image 1
would display "image.imh".  In v2.11.1, it appears as though a new
feature has been added that causes an error and exit if there is 
an ambiguity in the image extension.

I have written a large number of reduction scripts, and am familiar
with scripts written by many other people, which regularly use the
file naming convention of "image.imh" (and "image.pix") for the
science-quality data, and "image.pl" for the associated bad pixel
mask.  Under v2.11.1, the error message of "Ambiguous image name", 
followed by an exit, occurs whenever access to such an image is
attempted.

While I understand that there may be a good reason to have the
file extension ambiguity addressed, I suggest that this may not be
a good solution:

	- many people have piles of data in the "image.imh" and 
		"image.pl" format, forcing them to rename the "image.pl"
		files or always type ".imh" for every operation

	- there appears to be no way to specify a preferred default
		file extension (please tell me if there is!!!)

	- use of alternative, space-saving file formats such as ".pl"
		is discouraged altogether since ambiguities could crop up
		when you least expect them

	- many existing scripts either have to be modified to change either

		* file naming for the ".pl" files to be something else;

			-OR-

		* //".imh" needs to be inserted whenever an ambiguity
			could arise

	  The latter means that well-written scripts which can work with
	  ".imh", ".hhh", or ".fits" files would now be hardwired to work
	  for only one!

I suggest that there are better solutions to the problem of file extension
ambiguities.  Some possible solutions could be:

	- Change the error message on file extension ambiguity to be a
		warning message (without exit), with the filename that is 
		being operated upon being displayed so the user knows what 
		is happening

	- Make the default preferred extension be the imtype parameter (which
		currently appears only to specify the format that data are
		written into, not the format which data are read from).  If
		that extension does not exist, but more than one other extension
		exists, then have an error message + exit.  This would prevent
		the necessity of a global preferred order of extensions.

Please advise me as to whether there is any way to specify the preferred
file extension, or if you anticipate that there will be a modification of
this feature (or a return to its previous state).

Many thanks,
...



---------- Forwarded message ----------
Date: Tue, 6 Jan 1998 14:50:23 -0700 (MST)
From: Doug Tody <tody@tucana.tuc.noao.edu>
Subject: Re: Image extension ambiguities in v2.11.1

Hi Mike,

I see that Mike F. has already gotten back to you and explained about how
dangerous it is for IRAF to silently operate on ambiguously-named images,
e.g. deleting the wrong image, or computing using the wrong image.

> 	- many people have piles of data in the "image.imh" and 
> 		"image.pl" format, forcing them to rename the "image.pl"
> 		files or always type ".imh" for every operation
> 
> 	- there appears to be no way to specify a preferred default
> 		file extension (please tell me if there is!!!)
> 
> 	- use of alternative, space-saving file formats such as ".pl"
> 		is discouraged altogether since ambiguities could crop up
> 		when you least expect them
> 
> 	- many existing scripts either have to be modified to change either
> 
> 		* file naming for the ".pl" files to be something else;
> 
> 			-OR-
> 
> 		* //".imh" needs to be inserted whenever an ambiguity
> 			could arise

I think the best way to solve the problem is to change your image naming
convention.  It is best to not call things that are different by the same
name.  If your image is named "image", don't call your mask "image" as
well: use a naming convention such as "imageXXXX" instead, i.e. the same
root, but not identically the same name.  According to the conventions we
follow here, if one has image.imh and image.pl (or image.fits etc.), they
are the same image object stored in two different formats.  Note that you
can still use "image*" to match all the files so long as they share the
same root name.

> The latter means that well-written scripts which can work with
> ".imh", ".hhh", or ".fits" files would now be hardwired to work
> for only one! 

This is a good point, but if you use an explicit naming convention as
described above then your scripts will still be format-independent, and
you will be able to discriminate between images and associated masks.

We will be happy to think about this some more, but our current thinking is
that different objects should not have the same name (same root prefix yes,
same full name no).  That appears to be the problem, and a naming
convention the answer.   It works, and is explicit, without any built-in
dependence on name resolution semantics.

Regards,  Doug

Doug Tody       National Optical Astronomy Observatories    IRAF project
tody@noao.edu            950 N. Cherry Avenue            http://iraf.noao.edu
(520) 318-8217  P.O. Box 26732, Tucson, Arizona, 85726   FAX: +1 520 760-1709

---

Last post on Jan 06, 1998