View Single Post
Old 01 May 2015, 21:13   #84
Registered User
Join Date: Jun 2010
Location: PL
Posts: 1,630
Originally Posted by jsr View Post
My converter could do this. There's two approach to quantize an image to a copperlisted ILBM.

One is to quantize the image per N line pieces. This would result in a [(height / N) * no_colours] coloured image, which can be even more than 256, for example a 200 pixel tall picture quantized to 32 colours per 16 line would result in a 400 coloured picture. However, this can result in a slightly "striped" image, as the colours can differ in each N line tall stripe.

Second is to specify the limit of colours (N), then begin to count colours from the top left corner. Whenever in a line, this colour limit is surpassed by X number of colours, then a copperlist entry would be made, with X palette entries changed to the new colours. This method would produce a result identical to the original image, however this method assumes, that the relevant lines don't contain more colours than N-X, which is highly unlikely to happen in a picture, which have very much colours. The picture can be quantized first (for example to 256 colours), but then the other method can result in higher colour numbers. But this method will still won't produce stripes.

However, any method requires a copperlist chunk in the ILBM and a viewer, which can use it. Is this special chunk defined in any ILBM standard? I know about PCHG, but is that used in viewers?
Well, there are at least 3 types of "dynamic" formats, PCHG is one of them and some viewers support it fully, some "dynamic" formats are supported also on PC.

PCHG assume that color change need to be done during H Blank period and as such it is limited to maximum 10 - 12 but usually to 7 - 9 CLUT changes.
I assume that converter should be Copper/CPU wise - cycles available cycles counted and adopted also some changes may be done in overlapping fashion (i.e. CLUT not used in near 8 pixels) may be changed by Copper during normal video line.
Side to this there possibility to build special structure (pattern in BPLxDAT) and use more CLUT entries - if you look at Atari ST examples they look impressive and usually better than in Amiga approach (which should be not case). Clever color reduction for line (in interlace maybe 2 lines) with correct dithering should be sufficient to provide quasi true (12 bit) color (dreaming on hires).
pandy71 is offline  
Page generated in 0.07670 seconds with 10 queries