On 2 Apr 2012, at 02:05, Aleš Keprt wrote: > So how many colours are possible per line in this format? Or what is possible > in this picture format?
The number of colour changes per line depends on the image width, as CLUT changes are only made outside the image. That gives 6 dynamic and 10 static for full 256-pixel width, but up to 11 dynamic and 4 static for 96-pixel narrow images. > Also, I think that the converter could possibly de-noise the picture before > or after the conversion. Most of the conversion is using traditional methods — Heckbert's median cut to reduce to the full SAM palette, then Floyd-Steinberg dithering to apply it. The result of that will be close to what you'd get converting it in a typical desktop image-editing package. Of course, there's a second step conversion to reduce to the CLUT size, but it aims to keep the image as close to the original converted image as possible. Reducing the dithering ('noise') would mean compromising on pure colours, which is something that should probably be done interactively on a per-picture basis. > The viewer is quite straighforward, all the colour magic lies in the > converter. The core viewer code is short, but there's more to it than meets the eye! The start alignment and dynamic colour count depends on the width of the image being viewed. There are 6 self-modifying points used to inline counters and pointers, since there's little time to make decisions at runtime. The converter is still very important, of course, and my proof-of-concept script has certain deficiencies. I'm hoping that having a released native viewer will mean it can be included as an output format in existing SAM image conversion utilities, where the conversion will get the extra attention it needs, and by someone that knows more what they're doing! Si