|WikiProject Computing / Amiga||(Rated Start-class, Low-importance)|
Merge with what now?
The description of the control bits is wrong. I believe 01 changes the blue component and 11 changes the green component.
Maximum resolution on A4000 in HAM8
The maximum resolution available in HAM8 mode was 1440x576, it was useable if one had a 24bit source data. In case of a render (i.e. Lightwave) one could render straight into this resolution and convert to 1440x576 (Super Hi Res Overscan) HAM8 in ArtDepartamentPro. Alternatively it was possible to simply upscale image to 1440x576 and then convert to HAM8 to reduce fringing.
Such series of frames could then be displayed in SCALA and recorded frame-by-frame to BetaCam (required RS442 interface to control the video recorder). It was the poor man's frame buffer and at broadcast-quality it was indistinguishable from one.
Animating HAM images
As far as I understand the concept of HAM when changing a section of the screen in the course of an animation at maximum the 3 pixels right of the animated part have to be recalculated: Changing to an arbitrary colour might need changing colour values for red, green and blue separately. But if a pixel retains the original color it had before drawing the animated part all pixels to its right (that depend on its color) schould work again automatically. As I understand it the article currently states that the whole image has to be recalculated once a thing at the left of the screen changes. --Peterpall (talk) 05:21, 5 April 2012 (UTC)
I remember creating some HAM graphics with a Photoshop export plug-in. It seemed HAM used a very wide pixel ratio. What was the screen resolution of HAM images?
- The screen resolution was LoRes or LoRes-Laced. In PAL areas, this was 320x256 or 320x512. In NTSC areas, this was 320x200 or 320x400. HiRes (640 width) didn't support HAM, at least not on OCS/ECS Amigas, I believe that the AGA Amigas could do this though (I never had one, so can't be certain).
- --18.104.22.168 16:46, 26 July 2006 (UTC)
- AGA did allow HAM mode to be used on 70ns (HiRes) and 35ns (SuperHiRes and Productivity) resolutions. --Safalra 16:20, 19 December 2006 (UTC)
- OCS and ECS did not have the bandwidth to support fetching more than 4 bitplanes in Hires mode, hence they could not support HAM in Hires or higher. AGA could display all 8 bitplanes in all modes, thus it could display HAM in any mode. 22.214.171.124 15:57, 16 February 2007 (UTC)
- Isn't all computer graphics quantisation? I think that "lossy compression" is a better term. Val42 19:39, 17 February 2007 (UTC)
- Since it takes 3 pixels to modify one color to another color, HAM effectively reduces the color resolution to 230 horizontal. DVDs also reduce color resolution (350 across) as does NTSC/PAL broadcasting (~160 across). All of these are lossy compression techniques that seek to squeeze the color information into a lower resolution that the original source. - Theaveng 16:58, 2 September 2007 (UTC)
- Well, I suppose whether it is quantisation or compression depends precisely on which pixel you're looking at. HAM may produce a pixel that is exactly the desired color, slightly inaccurate due to quantisation, or one that is significantly inaccurate due to loss associated with data compression. I think that the term 'lossy compression' is best. HAM exists to save bus cycles and RAM, and ultimately everything that HAM is comes down to that, so I'd say it's a really specialised form of hardware compression. - Richard Cavell (talk) 11:24, 14 December 2008 (UTC)
- Since HAM is a hardware format it would be missleading to call it "lossy compression". If you display a 16M colour image on a 256 colour VGA screen you wouldn't call that "lossy compression". // Liftarn (talk) 21:06, 14 December 2008 (UTC)
- I don't see that the fact that it exists in hardware makes any difference to the question of whether it is compression or not. If you create images in HAM format with the intention of displaying them in HAM, then I suppose it is not compression. Since there is nothing to which the image can be decompressed, there is no compression going on. But if you rendered a 3D image into 4,096 colors, you would need to HAMify it in order to display it, and this means removing half the data in the original image while trying to preserve as much fidelity as you can. You could also do some serious programming and planning (and slicing with the copper) to try to do a better job of compressing the data to minimise the loss. I think that your latter example of displaying truecolor on a 256 color screen represents quantisation, not compression. - Richard Cavell (talk) 23:13, 14 December 2008 (UTC)
- I personally am fine with the word "lossy compression": You save a certain amount of bandwidth and loose a bit of information. Besides that HAL works a little bit similar to runlength- or delta coding. But I have to admit it is no typical compression scheme. "Quantisation" isn't a bad word, either, but normally implies that some colour values cannot be reached at all (as opposed to HALs limitation that every colour can be reached within the range of 3 pixels). --Peterpall (talk) 05:29, 5 April 2012 (UTC)
Sliced HAM (SHAM or SHM)
No discussion about Sliced HAM? This was a technique used on the original Amigas to use all 4096 colors without the "blur" of HAM. It required the full attention of the CPU (i.e. minimal multitasking), but the pictures were beautiful and crystal-clear. I stopped using HAM after I discovered Sliced HAM mode. - Theaveng 17:02, 2 September 2007 (UTC)
- We need external references to add this information to the article. If you can find such references, go ahead and add it. — Val42 16:07, 3 September 2007 (UTC)
- The CPU wasn't the chip that did the slicing, it was the copper. The CPU set up the copperlist but otherwise did no work to enable slicing. A very clever programmer could create dynamic sliced HAM images by using the CPU to intelligently recompile the copperlist every frame, but I'm not aware of anyone having done that. There are no real applications for it. An AGA Amiga could be programmed to produce output as good as modern 24-bit colour chunky graphics card, but you'd be caning the CPU. You'd be caning the copper as well, but the copper can't be used for general purposes so you might as well use the bus cycles. - Richard Cavell (talk) 11:13, 14 December 2008 (UTC)
Rename this article
picture showing clearly the artifacts that might happen with this format?
I think it would be good to have image(s) showing clearly the potential issues with this format, the animation linked in the bottom, at least for me, make it seem that the format is capable of relatively high quality results with animation. --TiagoTiago (talk) 11:54, 3 May 2009 (UTC)