Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!csd4.milw.wisc.edu!leah!rpi!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: CAMG Message-ID: Date: 12 Jun 89 17:11:22 GMT References: <1373@psueea.UUCP> <122@snll-arpagw.UUCP> <123@snll-arpagw.UUCP> Sender: usenet@rpi.edu Organization: Pi-Rho House, Troy, NY Lines: 64 In-reply-to: paolucci@snll-arpagw.UUCP's message of 12 Jun 89 01:37:27 GMT In article <123@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >It is my understanding that optional means that a file that does not make >use of any Amiga specific ViewModes does not need to contain it, but if >it does, then it should. You cannot assume that anything larger that >640x400 is HIRES and LACE, since when higher resolutions will start >appearing on the Amiga, this procedure will fail. I just don't like >the idea of decisions based on hardwired current numbers. What I meant was that the CAMG chunk is "nonstandard" -- defined AFTER the FORM, thus optional *by definition*. The fact is, any viewer program *must* understand the hardware to use it... new hardware will obsolete the old software, whether by making the IFF-writing files obsolete by not taking it into account, or the viewers for he same. If a viewer program knows about a new 1024x800 screen mode available, it can deduce that from the image size, without the CAMG chunk. A viewer which does NOT know how to deal with the new screen mode will ignore it even if it is specified in a CAMG chunk. No matter what you do, you're still stuck with the position of hardwiring current hardware capabilities, at least to some extent. Inclusion (or not) of a CAMG chunk does not affect that. >There are reasons to use interlace even when noninterlace is available, >particularly if you are trying to use the video capability of the Amiga. Then include the CAMG chunk to specify that, if interlace is specifically desired. >I maintain that they are poorly written since there is more than one >way to interpret the file just by looking at the size of the picture >and number of bitplanes. So? Let the program do its best to find the "best" interpretation of the file, where ambiguities lie. >There is also nothing wrong in using your own color table as opposed as >what's contained in a file. What you do with the picture is nobody's >business. All I'm asking is that complete and correct information >should be contained in the file so that if somebody wants to use it, >it's there. The more complete and more correct the information, the better. But that still doesn't make the CAMG chunk required, even for a HIRES & LACE screen. >I never claimed that all programs must supply one. All I said that only >when Amiga specific ViewModes are used, than a CAMG chunk should be >written in the file. If this information is superfluous , as you seem >to claim, than perhaps we should obsolete this chunk :^). My claim is >that it is not superfluous, and it will become more and more essential >as more resolutions are available on the Amiga and as more IFF ILBM files >are generated on other computers. I did not claim it was superfluous. It is often redundant. There is a difference. It can contain useful *hints* but the chunk cannot be thought of as required even when Amiga-specific viewmodes are used. Even HAM mode. Highly recommended, to be sure, but NOT required. Deven -- shadow@[128.113.10.2] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.