bartonr@psu-cs.cs.pdx.edu (=> robart <=) (06/10/89)
In article <12085@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: > The only bits you should really look at (and save!) in the CAMG word are >the HAM and HALFBRIGHT bits. The way to decide if the image should be >displayed as interlace or not is to look at the aspect ratio and image size in >the BMHD property. The BMHD is always provided -- if not, the ILBM is broken. I think a better way to decide if the image is LACE or HIRES is to look at the information in the CAMG chunk. After all, if you're going to write it out anyway what is the point in leaving out important information? The less there is for the reader program to have to figure out, the better. Besides, using the aspect ratio can be unreliable. Some programs don't set it correctly, and even if they do the ratios are different for NTSC and PAL machines, and you have no information in the file to tell you which type it was created on.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (06/11/89)
In article <12085@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >As I understand it, ILBM.CAMG is an optional property chunk. This means that >files do not have to have it. The only bits you should really look at (and >save!) in the CAMG word are the HAM and HALFBRIGHT bits. The way to decide >if the image should be displayed as interlace or not is to look at the >aspect ratio and image size in the BMHD property. The BMHD is always >provided -- if not, the ILBM is broken. > >What screen size and combination of HIRES and LACE to use for a given set >of aspect ratio and image size information is left as an exersize for the >reader. IFF is meant to be a standard that is applicable to files other than those created on the Amiga. And even files created on the Amiga should be able to be read and used on other computers. As such, any Amiga specific information should be included in the CAMG chunk. That is the purpose of this chunk. Thus any information about HAM, HALFBRITE, as well as DUAL_PLAYFIELD, LACE, and HIRES should all be in the CAMG chunk when applicable. When you use any Amiga specific viewmodes than the CAMG chunk is NOT optional any more. The w and h in the BitMapHeader can only (and should only) tell you the image dimension in pixels. The variables pageWidth and pageHeight should be the size in raster units that the image is meant to be displayed. Note that these interpretations are non-Amiga specific, as they should be, and have nothing to do with LACE or HIRES. Thus if an image is to be displayed in interlace, this property should be contained in the CAMG chunk, as other computers don't understand what interlace is. All that is important on the other computer is the size of the image that is to be displayed. That it is to be displayed in interlace is only relevant to the Amiga. Any other interpretations or deductions about Amiga ViewModes from sizes of the image are pure hacks that may only be necessary because of poorly written ILBM files by some well known applications. I have even seen some that are meant to use HALFBRITE that don't say so in the CAMG chunk. By using these types of hacks, it only perpetuates badly written ILBM files. When reading an ILBM file you should not have to guess what ViewModes to use. You should only use what is specifically contained in the file. -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
shadow@pawl.rpi.edu (Deven T. Corzine) (06/11/89)
In article <122@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >In article <12085@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >>As I understand it, ILBM.CAMG is an optional property chunk. This means that >>files do not have to have it. The only bits you should really look at (and >>save!) in the CAMG word are the HAM and HALFBRIGHT bits. The way to decide >>if the image should be displayed as interlace or not is to look at the >>aspect ratio and image size in the BMHD property. The BMHD is always >>provided -- if not, the ILBM is broken. This is correct. (But if the CAMG chunk DOES specify LACE or HIRES, use it.) >>What screen size and combination of HIRES and LACE to use for a given set >>of aspect ratio and image size information is left as an exersize for the >>reader. >IFF is meant to be a standard that is applicable to files other than >those created on the Amiga. And even files created on the Amiga >should be able to be read and used on other computers. As such, any >Amiga specific information should be included in the CAMG chunk. That >is the purpose of this chunk. Thus any information about HAM, >HALFBRITE, as well as DUAL_PLAYFIELD, LACE, and HIRES should all be in >the CAMG chunk when applicable. When you use any Amiga specific >viewmodes than the CAMG chunk is NOT optional any more. The w and h >in the BitMapHeader can only (and should only) tell you the image >dimension in pixels. The variables pageWidth and pageHeight should be >the size in raster units that the image is meant to be displayed. >Note that these interpretations are non-Amiga specific, as they should >be, and have nothing to do with LACE or HIRES. And what makes you suddenly decide that just because a picture is HIRES and LACE that suddenly ILBM.CAMG is *required*?? Quite apart from the fact that _by definition_ ILBM.CAMG can NOT be required (as it is an optional chunk added after the standard was released) you don't NEED that chunk to tell you the 640x400 picture you're trying to display is HIRES and LACE. Yes, they are Amiga-specific. No, they are not an integral part of the picture. Nor are they necessary to deduce the proper viewmode. On an Amiga, a 640x400 screen must be HIRES and LACE. It's not so difficult for a viewer program to figure out. >Thus if an image is to be displayed in interlace, this property should >be contained in the CAMG chunk, as other computers don't understand >what interlace is. All that is important on the other computer is the >size of the image that is to be displayed. That it is to be displayed >in interlace is only relevant to the Amiga. Yes, it *should* be contained in a CAMG chunk, but ONLY because it provides one more piece of information about the whole, NOT because it is necessary in any shape or fashion. That it is to be displayed in interlace is a function of the screensize, generally. You will not commonly find pictures you would *prefer* interlaced, if you had 640x400 noninterlaced available as well. If interlace is the only way to get the resolution for display, use interlace. But it's not important to specify, and can never be required. >Any other interpretations or deductions about Amiga ViewModes from sizes >of the image are pure hacks that may only be necessary because of >poorly written ILBM files by some well known applications. I have even >seen some that are meant to use HALFBRITE that don't say so in the >CAMG chunk. By using these types of hacks, it only perpetuates badly >written ILBM files. When reading an ILBM file you should not have to >guess what ViewModes to use. You should only use what is specifically >contained in the file. They are not "pure hacks." They are a perfectly valid method of determining the viewmodes when unspecified. An ILBM file which does not specify a proper aspect ratio is poorly written. One without ILBM.BMHD is broken. One without ILBM.CAMG is neither poorly written nor invalid; it is merely less than ideal. (and perhaps out of date) "You should only use what is specifically contained in the file." Why? If you want your program to show a high resolution, interlaced picture in low resolution, non-interlaced mode, what's wrong with that? Are the ViewModes sacred? Amiga pictures save in IFF ILBM files should have CAMG chunks only so as to include more information, but to claim that all programs MUST supply one is stretching things a bit. Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (06/12/89)
In article <SHADOW.89Jun11123615@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: ->In article <122@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: -> ->>In article <12085@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: ->>>As I understand it, ILBM.CAMG is an optional property chunk. This means that ->>>files do not have to have it. The only bits you should really look at (and ->>>save!) in the CAMG word are the HAM and HALFBRIGHT bits. The way to decide ->>>if the image should be displayed as interlace or not is to look at the ->>>aspect ratio and image size in the BMHD property. The BMHD is always ->>>provided -- if not, the ILBM is broken. -> ->This is correct. (But if the CAMG chunk DOES specify LACE or HIRES, ->use it.) -> ->>>What screen size and combination of HIRES and LACE to use for a given set ->>>of aspect ratio and image size information is left as an exersize for the ->>>reader. -> ->>IFF is meant to be a standard that is applicable to files other than ->>those created on the Amiga. And even files created on the Amiga ->>should be able to be read and used on other computers. As such, any ->>Amiga specific information should be included in the CAMG chunk. That ->>is the purpose of this chunk. Thus any information about HAM, ->>HALFBRITE, as well as DUAL_PLAYFIELD, LACE, and HIRES should all be in ->>the CAMG chunk when applicable. When you use any Amiga specific ->>viewmodes than the CAMG chunk is NOT optional any more. The w and h ->>in the BitMapHeader can only (and should only) tell you the image ->>dimension in pixels. The variables pageWidth and pageHeight should be ->>the size in raster units that the image is meant to be displayed. ->>Note that these interpretations are non-Amiga specific, as they should ->>be, and have nothing to do with LACE or HIRES. -> ->And what makes you suddenly decide that just because a picture is ->HIRES and LACE that suddenly ILBM.CAMG is *required*?? Quite apart ->from the fact that _by definition_ ILBM.CAMG can NOT be required (as ->it is an optional chunk added after the standard was released) you ->don't NEED that chunk to tell you the 640x400 picture you're trying to ->display is HIRES and LACE. Yes, they are Amiga-specific. No, they ->are not an integral part of the picture. Nor are they necessary to ->deduce the proper viewmode. On an Amiga, a 640x400 screen must be ->HIRES and LACE. It's not so difficult for a viewer program to figure ->out. 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. ->>Thus if an image is to be displayed in interlace, this property should ->>be contained in the CAMG chunk, as other computers don't understand ->>what interlace is. All that is important on the other computer is the ->>size of the image that is to be displayed. That it is to be displayed ->>in interlace is only relevant to the Amiga. -> ->Yes, it *should* be contained in a CAMG chunk, but ONLY because it ->provides one more piece of information about the whole, NOT because it ->is necessary in any shape or fashion. That it is to be displayed in ->interlace is a function of the screensize, generally. You will not ->commonly find pictures you would *prefer* interlaced, if you had ->640x400 noninterlaced available as well. If interlace is the only way ->to get the resolution for display, use interlace. But it's not ->important to specify, and can never be required. There are reasons to use interlace even when noninterlace is available, particularly if you are trying to use the video capability of the Amiga. ->>Any other interpretations or deductions about Amiga ViewModes from sizes ->>of the image are pure hacks that may only be necessary because of ->>poorly written ILBM files by some well known applications. I have even ->>seen some that are meant to use HALFBRITE that don't say so in the ->>CAMG chunk. By using these types of hacks, it only perpetuates badly ->>written ILBM files. When reading an ILBM file you should not have to ->>guess what ViewModes to use. You should only use what is specifically ->>contained in the file. -> ->They are not "pure hacks." They are a perfectly valid method of ->determining the viewmodes when unspecified. An ILBM file which does ->not specify a proper aspect ratio is poorly written. One without ->ILBM.BMHD is broken. One without ILBM.CAMG is neither poorly written ->nor invalid; it is merely less than ideal. (and perhaps out of date) 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. ->"You should only use what is specifically contained in the file." ->Why? If you want your program to show a high resolution, interlaced ->picture in low resolution, non-interlaced mode, what's wrong with ->that? Are the ViewModes sacred? 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. ->Amiga pictures save in IFF ILBM files should have CAMG chunks only so ->as to include more information, but to claim that all programs MUST ->supply one is stretching things a bit. 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. -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
shadow@pawl.rpi.edu (Deven T. Corzine) (06/13/89)
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] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
jms@tardis.Tymnet.COM (Joe Smith) (06/13/89)
Let me add my 2 cents:
If an IFF picture is EXTRA_HALFBRITE or HAM, then the CAMG chunk is mandatory.
If the only bits set in the CAMG chunk are just LACE and/or HIRES, then
the chunk need not be included.
With respect to the ECS: The LACE bit does not necessarily mean to use
intelace mode. It can mean "switch to interlace (flicker) mode" or it can
mean "do what ever is required to switch the display mode so that 400 or
more lines are visable". If the picture has 4 colors or less, I'd say the
latter. But a 640x400 16 color picture requires interlace. (Unless the ECS
can do more than what I've been told.)
Before we follow this particular thread, I wouldn't say anything more until
after reading the offical specs on the ECS. It is really only 4 colors out
of a palette of 64 in the 640x400 non-interlaced mode?
--
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com
McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"stephan@cup.portal.com (Stephen Derek Schaem) (06/13/89)
The way to do it, use CAMG when it's there and q/ guess when it's not. What is the problem? if you dont have a CAMG you you guess the closly possible as how it should be.And if there IS a CAMG, and I would say that alot of time program dont include one, use it! But you still have to set overscan yourself... Couldnt ILBM include the hot top left of the picture?and also ntsc or pal?~r
paolucci@snll-arpagw.UUCP (Sam Paolucci) (06/14/89)
In article <253@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes:
->Let me add my 2 cents:
->
->If an IFF picture is EXTRA_HALFBRITE or HAM, then the CAMG chunk is mandatory.
->
->If the only bits set in the CAMG chunk are just LACE and/or HIRES, then
->the chunk need not be included.
->
->With respect to the ECS: The LACE bit does not necessarily mean to use
->intelace mode. It can mean "switch to interlace (flicker) mode" or it can
->mean "do what ever is required to switch the display mode so that 400 or
->more lines are visable". If the picture has 4 colors or less, I'd say the
->latter. But a 640x400 16 color picture requires interlace. (Unless the ECS
->can do more than what I've been told.)
But interlace may not be required with future Viewmodes associated with
future hardware. Hopefully IFF files will still be around then.
My only point is that all the parameters in use when the IFF file was
created should be written out. If a reader wants to ignore half of
them, then so be it. But all the info should be there to recreate it
as intended if one wants to. The way the file is interpreted should
not have to depend on future changes to the Amiga resolution and
bitplanes. This can only happen if all the info is there.
--
-+= SAM =+-
"the best things in life are free"
ARPA: paolucci@snll-arpagw.llnl.govshadow@pawl.rpi.edu (Deven T. Corzine) (06/14/89)
In article <253@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >If an IFF picture is EXTRA_HALFBRITE or HAM, then the CAMG chunk is >mandatory. Still not mandatory, but certainly foolish to omit. Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
jms@tardis.Tymnet.COM (Joe Smith) (06/15/89)
I write: >>If an IFF picture is EXTRA_HALFBRITE or HAM, then the CAMG chunk is >>mandatory. In article <SHADOW.89Jun13210417@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >Still not mandatory, but certainly foolish to omit. Agreed. If a picture has 6 bit planes but only 16 colors are defined, then it can be assumed that the picture is uses Amiga's HAM mode. And one can assume that 6 bit planes and 32 colors implies extra-halfbrite. But I hate having to make assumptions. We all know the joke about what "assume" means. To be really complete, an IFF file of an extra-halfbrite picture should have entries for 64 color registers. That is so that non-Amiga IFF readers can treat it like a normal 6 bit plane image. With the half-brite colors defined, the CAMG chunk is not really mandatory. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
jms@doctor.Tymnet.COM (Joe Smith) (06/20/89)
I write: ->With respect to the ECS: The LACE bit does not necessarily mean to use ->intelace mode. It can mean "switch to interlace (flicker) mode" or it can ->mean "do what ever is required to switch the display mode so that 400 or ->more lines are visable". If the picture has 4 colors or less, I'd say the ->latter. But a 640x400 16 color picture requires interlace. (Unless the ECS ->can do more than what I've been told.) In article <124@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >But interlace may not be required with future Viewmodes associated with >future hardware. Hopefully IFF files will still be around then. The future is sooner than many think. It used to be there was only two types of display hardware: PAL versus NTSC. Then came the distinction of halfbrite versus no halfbrite. The 1meg Agnus chips and the A2024 monitor are available today, and the new Denise chip (for 640x480 x 4 colors) will be coming soon. > .... But all the info should be there to recreate it >as intended if one wants to. The way the file is interpreted should >not have to depend on future changes to the Amiga resolution and bitplanes. I agree with Sam, any program that writes an IFF file should put in as much information as possible so that the IFF reader program (or the graphics.library) can make the best decision on how to display the file. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
shf@well.UUCP (Stuart H. Ferguson) (06/23/89)
+-- bartonr@psu-cs.cs.pdx.edu (=> robart <=) writes: | In article <12085@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: | > The only bits you should really look at (and save!) in the CAMG word are | >the HAM and HALFBRIGHT bits. The way to decide if the image should be | >displayed as interlace or not is to look at the aspect ratio and image size | >in the BMHD property. The BMHD is always provided -- if not, the ILBM | >is broken. | I think a better way to decide if the image is LACE or HIRES is to look at | the information in the CAMG chunk. After all, if you're going to write it out | anyway what is the point in leaving out important information? The less there | is for the reader program to have to figure out, the better. Besides, using | the aspect ratio can be unreliable. Some programs don't set it correctly, and | even if they do the ratios are different for NTSC and PAL machines, and you | have no information in the file to tell you which type it was created on. Ok, I agree. You should look at the CAMG and if you can make sense of what's there, you use it. Several things to note, however: 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. (You want square pixels? I'll give you square pixels... ;-) 2.) Many ILBM's are not created on Amigas. For them, the CAMG chunk is much less meaningful and may be missing. Here the pixel aspect ratio is much more important to observe. 3.) Many ILBM's are not displayed on Amigas. Same caveats as above. (We're talking device-independent here, folks...) 4.) Many bits in the viewmodes word as used in the graphics library are very dangerous to just jam into a new viewport. Bits such as VP_HIDE and the GENLOCK bits. Always be sure to mask these out when writing and especially when reading (kids, you don't know where these files have been...) 5.) The ECS viewmodes, support for multisync monitors, and the way the system people plan to address this in the future will make this CAMG issue -- let's just say -- VERY interesting. (You think it's hard to understand NOW...) -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
doug@xdos.UUCP (Doug Merritt) (06/23/89)
In article <12340@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >5.) The ECS viewmodes, support for multisync monitors, and the way the >system people plan to address this in the future will make this CAMG issue -- >let's just say -- VERY interesting. (You think it's hard to understand >NOW...) No, as a matter of fact, I don't see anything particularly difficult about examining CAMG bits now. In fact it seems quite straightforward. Since any and all 1.4 proposals may change at any time, and since we therefore shouldn't really talk about them, all I can say about your implication is that the 1.4 CAMG extensions also make perfect sense, and I don't really think that your viewing them with alarm is at all fair. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
bartonr@jove.cs.pdx.edu (Robert Barton) (06/25/89)
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. > 2.) Many ILBM's are not created on Amigas. For them, the CAMG chunk is > much less meaningful and may be missing. Here the pixel aspect ratio is > much more important to observe. > 3.) Many ILBM's are not displayed on Amigas. Same caveats as above. (We're > talking device-independent here, folks...) I don't think I have seen any so far that weren't created on an Amiga, but the standard is certainly designed to make that possible. Other machines should not write CAMG chunks, and just skip them when reading. Amiga programs that read these "foreign" files will have to try and match the aspect ratio in the BMHD with one of the Amiga's 3 possible ratios, recognizing that one of these ratios covers both lo-res non-interlace and hi-res interlace. > 4.) Many bits in the viewmodes word as used in the graphics library are > very dangerous to just jam into a new viewport. Bits such as VP_HIDE and > the GENLOCK bits. Always be sure to mask these out when writing and > especially when reading (kids, you don't know where these files have been...) Good point. There is additional information along these lines in the IFF section of the new Includes & Autodocs, including some defines you can use to mask off the inappropriate ViewModes bits. > 5.) The ECS viewmodes, support for multisync monitors, and the way the > system people plan to address this in the future will make this CAMG issue -- > let's just say -- VERY interesting. (You think it's hard to understand NOW...) If there are going to be some new ViewModes bits with ECS, it would be nice if their definitions could be released as soon as possible so programs can be designed to work with the new modes.
shf@well.UUCP (Stuart H. Ferguson) (06/27/89)
+-- 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
shf@well.UUCP (Stuart H. Ferguson) (06/27/89)
+-- doug@xdos.UUCP (Doug Merritt) writes: | In article <12340@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: | >5.) The ECS viewmodes, support for multisync monitors, and the way the | >system people plan to address this in the future will make this CAMG issue -- | >let's just say -- VERY interesting. (You think it's hard to understand | >NOW...) | [...] all I can say about your | implication is that the 1.4 CAMG extensions also make perfect sense, | and I don't really think that your viewing them with alarm is at all fair. | Doug I didn't mean to sound caustic, Doug. The systems folks actually have a very hard problem in dealing with existing ILBMs and at the same time extending the system for the future. Given those difficulties I think the possible solutions they were considering smacked of real genius. But while I have great respect for the Amiga software architects, I still have trouble accepting the CAMG concept itself. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
bartonr@jove.cs.pdx.edu (Robert Barton) (07/01/89)
shf@well.UUCP (Stuart H. Ferguson) writes: > 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. DPaint II also ignores the CAMG chunk. I did some searches through it with an editor able to handle binary files and 'CAMG' was nowhere to be found. I did see CAT and LIST, but it doesn't seem to handle either one properly. It doesn't like my 16x1x1 picture either. It loads it, but the bottoms of the menus are cut off and it eventually crashes. Some other viewer programs I tried this file on crash while trying to load the picture. One other interesting thing I saw: along with the familiar directory names like "lo-res", "interlace", etc., was one for "hold-mod". I wonder when they'll get around to implementing this? (* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *) P-Link := PDX*BOB bix := robart