Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CAMG
Message-ID: <12426@well.UUCP>
Date: 27 Jun 89 06:56:09 GMT
References: <1405@psueea.UUCP>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 28

+-- bartonr@jove.cs.pdx.edu (Robert Barton) writes:
|  In article <12340@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes:
| > 1.) Many programs write inconsistent ILBM's.  Some even create 640 x 200
| > bitmaps with no CAMG chunk and ask for a pixel aspect ratio of 10/11.
| 
|   Well, 640x200 could be HIRES and LACE, in which case the standard aspect
| ratio is 10/11 (although the actual value is closer to 6/7).  Or it could
| be a lo-res, non-interlaced superbitmap.

You're right, of course.  The particular image in question was a screen
capture of a Workbench resolution (HIRES, no interlace) screen.  The aspect
ratio was really about 2:1, but the header asked for square pixels -- an
example of a broken ILBM writer.

Many simple ILBM viewers, on the other hand, look at the size of the image
and use that to determine how large a screen to open (in lieu of a CAMG
chunk).  Since they ignore the aspect ratio, they are broken readers.

The problem is that there are both broken readers and broken writers.  For
example, files from the broken writer above will display correctly using
the broken reader above.  The conclusion is that if you're trying to develop
code to write files in a standard format, such as ILBM, make sure you test
your files with a fully conforming reader (preferably several).  DPaint II
(I don't know about III) is not a sufficient test since it ignores the aspect
ratio information in favor of the type of screen you declare.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC