I've seen something similar on the Atari Lynx, which also has a 4 bit frame buffer, the only difference being that I think that used a tight loop of something like (i) load next palette index, next colour and next delay length; (ii) push colour to palette index; (iii) perform a busy loop of the desired length; (iv) repeat. The loop was synchronised once with vertical retrace and timings were such that a degenerate case was to change the entire palette once after every scan line but you could instead, say, change a single palette index several times over the course of a single scan line, or anything in between.
A better adaption for the Sam might be to allow palette and mode changes, and for simplicity to add a delay length that just means to wait until the next vertical retrace? If you have portions of the image with only four colours (especially once the colour aliasing forced by the 128-colour palette is accounted for) then switching to mode 3 for a portion of a line could be the smarter thing to do, and would presumably cost basically nothing to implement? In terms of image conversion, I guess a heuristic would be the thing. It feels like, even at Sam size, an exhaustive search could take forever. Of course, I didn't disassemble Simon's fantastic work so it's possible he's way ahead of me on this one. On 1 April 2012 18:05, Aleš Keprt <[email protected]> wrote: > Oh yes, this is nice. I saw similar things in the past, AFAIR this was > published on some disk magazine back in 90's. But it will be hard to find it > now. > > So how many colours are possible per line in this format? Or what is > possible in this picture format? > > Also, I think that the converter could possibly de-noise the picture before > or after the conversion. Or something like that. Because there are too many > dots visible in places where there should be no dots. This is good in high > resolution graphics like when printing on printer in 600 DPI, but doesn't > look too well on Sam. Especially in emulator with crisp LCD display. ;-) I > think the whole de-noising process is extremely important when converting to > low resolution and low bitdepth. And each single picture needs a different > values for the algorithm, so maybe there should be some kind of WYSIWYG > editor or something where users could change some settings and see the > result immediately in order to find the best settings for each file. ;-) > Maybe a genetic algorithm could help to find at least some local optimum. > > /--- > Aley > > -----Původní zpráva----- From: Simon Owen > Sent: Saturday, March 24, 2012 3:10 AM > To: sam-users > Subject: SAM HAM viewer > > > Hi all, > > I've been experimenting with HAM-style tricks on SAM, to try to improve > the quality of converted images. I've aimed to modify as many colours > as possible between lines, rather than using the traditional compromise > static palette. Are there any viewers using that technique already? > > I've written a Python script to convert regular images to a new .sham > format, and a SAM viewer program to display them. > > Demo: http://simonowen.com/sam/shamview/shamview.dsk > Source code: https://github.com/simonowen/shamview > > You might recognise some of them as SAM or image processing favourites! > > It still needs work on the dynamic palette selection, which just uses > the most-frequent colours, rather than doing proper quantisation. I > left the crayons image as an example of this breaking down. > > Si > > ----------------------------------------- > Mgr. Aleš Keprt, Ph.D. > private: [email protected], www.keprt.cz > office: Moravian College / Moravská vysoká škola Olomouc, [email protected]
