Image to ZX Spec 1.1 Now Freely Available!

edited March 2010 in Announcements
Image to ZX Spec 1.1 Now Freely Available!

ent-preview1.1.zx.pngterm-preview1.1.zx.png

New for Version 1.1
  • Added new Atrribute Favoritism feature to choose the colour set to use (greatly improves default image quality).
  • Added Dither Preview feature which displays previews with different dithering algorithms (and takes advantage of multi core processors).
  • Updated BASIC slideshow program with new warning to stop tape.
  • Minor bug fixes to do with image conversion colour choice.
  • Memory usage increased for larger image conversion (512MB min).
  • Improved UI layout for Linux based systems (tested on Ubuntu)
  • Main frame has splash picture, About box displays system info
Get it or try it online here - WOS link also to be updated shortly!
Post edited by brownb2 on

Comments

  • edited March 2010
    For the technical minded I thought I'd divulge some of the 5 stage image conversion process, "image" can be replaced with "images":
    1. If options have changed, pre process the image using algorithms for brightness, saturation etc.
    2. Detect the algorithm type to use based on chosen options (ordered or error diffusion dither), chose the relevant dither strategy for that type, apply dither to reduce the colours to 15 ZX Spectrum colours (this is per pixel colours at this point).
    3. Apply attribute blocking at 8x8 pixels, choose the two most popular colours in that block and replace other pixels in that block with either colour.
    4. Apply attribute favouritism (new for 1.1). If the chosen ink and paper colours are in different sets (full brightness/half brightness) apply the favouritism mode to ensure they are in the same set and that the colours are not identical within the set.
    5. Export the file, if scr (for example) in 8x8 blocks, the most popular colour is considered the "paper", the least the "ink".
  • edited March 2010
    Great stuff! I'm a big fan of this type of software. Digitised audio, video and still pictures on the Speccy mean a lot to me. Thank you for this new version. Downloading now!
  • edited March 2010
    I played a short while with it.

    I like the option that you can see the result of different methods at the same time and can choose the one I like the best.

    Still getting a good quality conversion is beyond my skills, but I guess it requires practice:)
  • edited March 2010
    Ralf wrote: »
    I played a short while with it.

    I like the option that you can see the result of different methods at the same time and can choose the one I like the best.

    Still getting a good quality conversion is beyond my skills, but I guess it requires practice:)

    Try adjusting the brightness slightly, about +15 to -25 (negative values are usually better) depending on brightness in source image, and increasing the saturation to about +5 to +25. This generally adjusts the source image to use a palette that is closer to the Spectrum palette. The Terminator image above was done by doing just this. (Colour +4, Sat +15, Bright +14). The Popcorn image just has some increased colour.

    I'm currently looking at multi core avi processing or dithvide mode. Working out the RGB values for the latter is the next step and as I don't know ASM/machine code I'm not sure how to write a BASIC program that will display them, although my divide plus can display them straight out so I don't see that as a problem.

    I'm assuming I can just generate a palette of 8 (BRIGHT) ZX colours + 50/50 colour combinations of those, i.e. BLACK+WHITE = NEW GREY, RED+GREEN = NEW YELLOW but I've yet to test this. I can't seem to find documentation for the other image algorithms used :( I'm fully code documenting my Java source so other people can pick up any slack (notably byte manipulation in export can be faster).

    Anyhow if the above thinking is correct using a larger palette then at step 3 (attribute choice) I can divide the fake colour into the two components and put one in the secondary image another in the primary.

    I assume a dithvide is just two SCRs that have been joined (e.g. I could use copy /b in dos to create one from existing two images?)
  • edited March 2010
    I don't know or understand all the technical details but we there's a page with info about the most popular graphic modes:

    http://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes

    There's a link to your utility on that page, and links to more sites with information. :)

    The ula+ isn't there yet but it has its own page:

    http://sites.google.com/site/ulaplus/

    I'm particularly interested in the avi conversion. It will be interesting to see how you're going to handle resizing, multiple codecs, removing audio (or maybe converting it too!*), and monochrome and colour options. A colour full-motion video might be nice (like the Girls Aloud one on YouTube), but I prefer monochrome, like some of the ones found here:

    www.youtube.com/zxspectrum128

    *pm me about this and I'll give you details.
  • edited March 2010
    zxbruno wrote: »
    I'm particularly interested in the avi conversion. It will be interesting to see how you're going to handle resizing, multiple codecs, removing audio (or maybe converting it too!*), and monochrome and colour options. A colour full-motion video might be nice (like the Girls Aloud one on YouTube), but I prefer monochrome, like some of the ones found here:

    www.youtube.com/zxspectrum128

    As I couldn't do the bzither approach today due to lack of docs I added animation at 10 frames per second and have a beta build that can do AVI to SCR video only at the moment. Needless to say the videos look great especially as I've not tuned ANY settings and it was dark in my study! This sort of stuff isn't new but it's probably going to be a bit easier :)

    YouTube video (converted video is a bit slow - it's got a timing bug)
    Here's the actual tap file created after the YouTube video with me changing the colour, dither and pre processing options in real time. Note the FPS is better (10 FPS, using PAUSE 5).
  • edited March 2010
    YouTube clips looking great! I PMed LCD to see if he could help you with some technical details.
  • LCDLCD
    edited March 2010
    Got a PM from zxbruno on skype...
    50:50 color mixing is also my appoarch, but it is wrong. I found out that the brighter colour has much more influence also in laced mode, but for the start, you can use the 50:50 mix to get the right feeling. I do not use Bright for this conversion yet.
    first: convert the picture to 27 colours like Amstrad CPC (Values: R 0-2, G 0-2 and B 0-2), then you can use brute force to compare all possible Spectrum Attribute combinations on both screens until you will get the closest possible match (smallest pythagoras difference) from source colours to the 4 mixed colours of both attr squares in scr 0 and scr 1.
    Finally you can convert all colors (also the closest ones) to corresponding Spectrum pixels and distribute them to the right screen.
  • edited March 2010
    LCD wrote: »
    Got a PM from zxbruno on skype...
    50:50 color mixing is also my appoarch, but it is wrong. I found out that the brighter colour has much more influence also in laced mode, but for the start, you can use the 50:50 mix to get the right feeling. I do not use Bright for this conversion yet.
    I was only going to use the bright set as I believed the image may be too dark but I can easily switch this.

    The image processor I have at the moment does a per pixel comparison of the original to bzither spectrum colours (i.e. all 64 from the bright set) and replaces them. A later pass chooses the most popular two colours based on these for the attribute block. If a colour is not in the regular 8 Spectrum colours it "splits" the colour in two, i.e. uses a hash to find out how the bzither colour was created from two Spectrum colours and puts the original colours in both scrs (respectively).

    This procedure works almost perfectly* for an app preview (*I think there may be a couple of issues with best colour choice).

    The bits I don't understand - how is the bzither scr file format defined (i.e. file layout of bytes), is there a BASIC program that will display bzither scrs, (I know very little of poke so documenting these would also be useful :) ) and is there a PC app to view these while I'm working on it?

    Thanks!

    Unrelated - video conversion performance on a single core Athlon XP "2700" (2600@2175Ghz) seems to be around 4 FPS for monochrome, 2-3 FPS for ordered dither (error diffusion not yet working) using raw formatted 640x480 AVI video. I think Java's G1 garbage collection, future changes to enable GPU hardware acceleration (moving to "VolatileImage"), and enabling multi core multi frame conversion should double this.
  • LCDLCD
    edited March 2010
    brownb2 wrote: »
    I was only going to use the bright set as I believed the image may be too dark but I can easily switch this.
    Bright set is okay too...
    brownb2 wrote: »
    The image processor I have at the moment does a per pixel comparison of the original to bzither spectrum colours (i.e. all 64 from the bright set) and replaces them. A later pass chooses the most popular two colours based on these for the attribute block. If a colour is not in the regular 8 Spectrum colours it "splits" the colour in two, i.e. uses a hash to find out how the bzither colour was created from two Spectrum colours and puts the original colours in both scrs (respectively).
    Thats a bit different from my method. Never tested such a possibility.
    brownb2 wrote: »
    This procedure works almost perfectly* for an app preview (*I think there may be a couple of issues with best colour choice).
    Example?
    brownb2 wrote: »
    The bits I don't understand - how is the bzither scr file format defined (i.e. file layout of bytes), is there a BASIC program that will display bzither scrs, (I know very little of poke so documenting these would also be useful :) ) and is there a PC app to view these while I'm working on it?
    Layout is two screens 6912 bytes one after one. BASIC is too slow to display real bzither images, but you can display them laced in usr0 mode: just copy first image to 49152 in bank 7 (CLEAR 24999:OUT 32765,23:LOAD "img"CODE 42240), copy other image to screen (slow in BASIC): FOR a=0 TO 6911:POKE 16384+a,PEEK(42240+a); NEXT a
    Then you can flip between them:
    10 PAUSE 1: OUT 32765,24:PAUSE 1:OUT 32765,16:IF INKEY$<>" " THEN GOTO 10
    brownb2 wrote: »
    Thanks!

    Unrelated - video conversion performance on a single core Athlon XP "2700" (2600@2175Ghz) seems to be around 4 FPS for monochrome, 2-3 FPS for ordered dither (error diffusion not yet working) using raw formatted 640x480 AVI video. I think Java's G1 garbage collection, future changes to enable GPU hardware acceleration (moving to "VolatileImage"), and enabling multi core multi frame conversion should double this.

    For Bzither conversion? Not bad!
    Edit: Retro-X PC App can display BZither images.
  • edited March 2010
    LCD wrote: »
    Example?

    term.zx.png
    LCD wrote: »
    Layout is two screens 6912 bytes one after....

    I'll use this info as soon as the avi branch is complete (I'm refactoring code atm).
    LCD wrote: »
    For Bzither conversion? Not bad!
    Unfortunately not - this is just regular conversion.
    LCD wrote: »
    Edit: Retro-X PC App can display BZither images.
    Excellent I'll install it again (I did have it at one point...!)
  • LCDLCD
    edited March 2010
    brownb2 wrote: »
    term.zx.png

    I'm somehow disappointed... Please try the same image in Retro-X (Spectrum/Timex->Interlaced->Lace Polychrome->)
    brownb2 wrote: »
    Unfortunately not - this is just regular conversion.

    On my AMD X2 4850e (only single core is used atm) in standard mode I got 40 FPS (Faster than realtime which is 25 FPS) in movie conversion. In Laced-Mode (Bzither) it is 4-5 FPS.
    brownb2 wrote: »
    Excellent I'll install it again (I did have it at one point...!)

    I hope, you like it...
  • edited March 2010
    LCD wrote: »
    I'm somehow disappointed... Please try the same image in Retro-X (Spectrum/Timex->Interlaced->Lace Polychrome->)

    Well I did say it was broken ;)
    LCD wrote: »
    On my AMD X2 4850e (only single core is used atm) in standard mode I got 40 FPS (Faster than realtime which is 25 FPS) in movie conversion. In Laced-Mode (Bzither) it is 4-5 FPS.
    I'm limiting the video throughput to 10 FPS as the BASIC player on the speccy doesn't seem to want to go faster. As far as conversion goes on my much slower single core machine (2.175Ghz Athlon XP) for Ordered 4x4 Bayer dither on the latest build it seems to take about the same time to convert as play the video, and about half speed to a third for error diffusion.
    On my 1.6Ghz Athlon Turion X2 laptop this refactored build (which as of this evening has a multi core work scheduler) manages about x1.5 to x 2.0 faster than the playing speed running on both cores - the quality is now superb, but don't take my word for it - linked is the latest revision's work. I'll add some real benchmarking code in so you can try it out for yourself and post some results if you like as I suspect you might find it a lot faster on your machine ;) I still have to add OpenGL acceleration in at some point.
    LCD wrote: »
    I hope, you like it...
    Is it still in beta btw (haven't installed it yet)?

    [EDIT] Update - info above is for full colour, monochrome is faster as no colour choice is needed - doing some actual tests for mono on the X2:
    Original video is 40 secs long at 30FPS.
    Converter only does 1/3 of those frames (10 FPS converted)
    Actual time taken is 20 seconds which is x2 viewing speed however the actual FPS throughput, as opposed to speed compared to playback is therefore about 6.65 FPS.
    I.e.
    The correct time is 13.3 seconds for the movie (for 10 FPS instead of 30)
    Converter took 20 seconds therefore 20/13.3 is our divisor for number of FPS which is 1.57.
    10FPS/1.57 = 6.65 FPS (rounded)

    Having said all of this it's somewhat pointless as two conversions are actually done at the moment, one for the preview/image saving and one for the SCR which due to legacy reasons (two different scalings may have been needed) I had to do. The above also involved some brightness pre processing.
    Removing the duplicate SCR code and pre processing brought the time to 10 seconds so...
    10FPS/(10/13.3) = 13.3 FPS.
    [/EDIT]

    Benjamin

    Benjamin
  • LCDLCD
    edited March 2010
    brownb2 wrote: »
    I'm limiting the video throughput to 10 FPS as the BASIC player on the speccy doesn't seem to want to go faster. As far as conversion goes on my much slower single core machine (2.175Ghz Athlon XP) for Ordered 4x4 Bayer dither on the latest build it seems to take about the same time to convert as play the video, and about half speed to a third for error diffusion.
    On my 1.6Ghz Athlon Turion X2 laptop this refactored build (which as of this evening has a multi core work scheduler) manages about x1.5 to x 2.0 faster than the playing speed running on both cores - the quality is now superb, but don't take my word for it - linked is the latest revision's work. I'll add some real benchmarking code in so you can try it out for yourself and post some results if you like as I suspect you might find it a lot faster on your machine ;) I still have to add OpenGL acceleration in at some point.
    Yes, the animation looks cool. Retro-X can also leave frames out, so it can be adjusted to DivIDE. With a special Low Level player DivIDE is able to play animations at 25 FPS. I will post the speed after installing java on my comuter.
    brownb2 wrote: »
    Is it still in beta btw (haven't installed it yet)?
    No, you are complety wrong. Retro-X is not in Beta state, but in Alpha state. The next version is planed as Beta, so it will take some time to change some of the parts. In Final state it will be more like TommyGun, a IDE.
    brownb2 wrote: »
    [EDIT] Update - info above is for full colour, monochrome is faster as no colour choice is needed - doing some actual tests for mono on the X2:
    Original video is 40 secs long at 30FPS.
    Converter only does 1/3 of those frames (10 FPS converted)
    Actual time taken is 20 seconds which is x2 viewing speed however the actual FPS throughput, as opposed to speed compared to playback is therefore about 6.65 FPS.
    I.e.
    The correct time is 13.3 seconds for the movie (for 10 FPS instead of 30)
    Converter took 20 seconds therefore 20/13.3 is our divisor for number of FPS which is 1.57.
    10FPS/1.57 = 6.65 FPS (rounded)

    Having said all of this it's somewhat pointless as two conversions are actually done at the moment, one for the preview/image saving and one for the SCR which due to legacy reasons (two different scalings may have been needed) I had to do. The above also involved some brightness pre processing.
    Removing the duplicate SCR code and pre processing brought the time to 10 seconds so...
    10FPS/(10/13.3) = 13.3 FPS.
    [/EDIT]

    Benjamin

    Benjamin
    I do re-use the data of converted screens which are saved, to display them too, so there is no redundant calculation. I will anyway include multithreading to speed up the calculations later. But atm I have no experience in coding threads.
  • edited March 2010
    LCD wrote: »
    Yes, the animation looks cool. Retro-X can also leave frames out, so it can be adjusted to DivIDE. With a special Low Level player DivIDE is able to play animations at 25 FPS.
    Are you prepared to share that code? I'd like to have it as a loader :)
    LCD wrote: »
    I will post the speed after installing java on my comuter.
    No rush - I'm still updating the program - Omega has been testing for me (btw Java Media Framework is absolute rubbish and it's replacement JMC isn't due until Java 7, in short cross platform avi video codec support is very very limited, we're talking Cinepak, some MJPG - not all - and raw here).
    LCD wrote: »
    No, you are complety wrong. Retro-X is not in Beta state, but in Alpha state. The next version is planed as Beta, so it will take some time to change some of the parts. In Final state it will be more like TommyGun, a IDE.
    Image to ZX Spec was designed to be simple to use and provide a more restricted view but with wizard like functionality for bulk conversions rather than an editor. The version numbering I use is 1.x.x for bug fixes/minor features, 1.x is large features/refactors.
    LCD wrote: »
    I do re-use the data of converted screens which are saved, to display them too, so there is no redundant calculation. I will anyway include multithreading to speed up the calculations later. But atm I have no experience in coding threads.
    What language is it written in?
    I've fixed the duplicate calculation in Image to ZX Spec - the problem was that the user could choose not to scale images to 256x192 and have both scr and png output, which means the conversion has to be done twice. I've now added a fix that if the scaling is correct the image conversion is only done once.

    On a related note the tap file video quality I attached earlier converts up to 6.5 FPS (colour+Bayer 4x4 dither), monochrome Bayer 4x4 is up to 20 FPS on the discussed Athlon XP single core machine.
    Omega is testing on a core 2 duo so whenever he gives me results I'll post them.
    The FPS test criteria is the amount of time to convert the image in memory, excluding disk load (Image to ZX Spec pre caches), typically the FPS diagnostic runs I've done only save a completed tap file at the end. The frame rate is even higher if there is no tap saving (as there will be no scr conversion). FPS is a 2 second average taken by a asynchronous thread checking a counter that holds the total number of images converted.
  • LCDLCD
    edited March 2010
    brownb2 wrote: »
    Are you prepared to share that code? I'd like to have it as a loader :)
    I don't have it because it is not my development:
    http://www.zxprojects.com/index.php/movie-player-full-resolution-full-speed-for-the-spectrum/23-a-poc-for-a-full-resoltion-full-speed-25fps-movie-player-for-the-zx-spectrum
    brownb2 wrote: »
    No rush - I'm still updating the program - Omega has been testing for me (btw Java Media Framework is absolute rubbish and it's replacement JMC isn't due until Java 7, in short cross platform avi video codec support is very very limited, we're talking Cinepak, some MJPG - not all - and raw here).
    Not just you, I update RX too, but I want to change too much stuff before releasing "Rubbish", so it takes much more time than expected.
    brownb2 wrote: »
    Image to ZX Spec was designed to be simple to use and provide a more restricted view but with wizard like functionality for bulk conversions rather than an editor. The version numbering I use is 1.x.x for bug fixes/minor features, 1.x is large features/refactors.
    I use a different version system: 080514 means: Released 2008, May, 14th. Some users misttook it for version 0.8.
    brownb2 wrote: »
    What language is it written in?
    PureBasic: http://purebasic.com/
    brownb2 wrote: »
    I've fixed the duplicate calculation in Image to ZX Spec - the problem was that the user could choose not to scale images to 256x192 and have both scr and png output, which means the conversion has to be done twice. I've now added a fix that if the scaling is correct the image conversion is only done once.
    A displayed image exists as bitmap in memory, and bitmaps can be easy saved as PNG, at least in Pure Basic (I do not know Java). Retro-X does allways redraw from a memory image, so redraw speed was the most critical. RX had 3000 Redraws (from spectrum bytes to Windows image) per second on my PC at a screen resolution of 1280x1024, and 1500 redraws at 1920x1200, so the resolution of windows desktop is essential for the speed too.
    There is a Benchmark build in, for any screen mode.
    brownb2 wrote: »
    On a related note the tap file video quality I attached earlier converts up to 6.5 FPS (colour+Bayer 4x4 dither), monochrome Bayer 4x4 is up to 20 FPS on the discussed Athlon XP single core machine.
    Okay, Athlon XP is slow (I have myself a XP 2400+ too), so the results are not that bad, except for colour conversion.
    brownb2 wrote: »
    Omega is testing on a core 2 duo so whenever he gives me results I'll post them.
    The FPS test criteria is the amount of time to convert the image in memory, excluding disk load (Image to ZX Spec pre caches), typically the FPS diagnostic runs I've done only save a completed tap file at the end. The frame rate is even higher if there is no tap saving (as there will be no scr conversion). FPS is a 2 second average taken by a asynchronous thread checking a counter that holds the total number of images converted.
    Excellent. I have no real FPS checking, but there is a calculation of time left until conversion finished, and time used for pure conversion (with screen updating) and time used for loading, conversion and saving, both in ms.
  • edited March 2010
    LCD wrote: »

    Wow, okay I WON'T be doing that! I was hoping to get more out of basic than 10 FPS but I'll just live with it. Other people can modify ImageToZXSpec if they want ;)

    An Athon XP 2600 isn't slow... a ZX Spectrum is slow, you've been blessed with a fast machine ;) I tend to keep my computers until they finally break and this has been running games like Dead Space, Mass Effect , Fallout 3 etc etc quite well (a Geforce 7600GT with 128bit bus 512MB ram probably helps ;) )
  • LCDLCD
    edited March 2010
    brownb2 wrote: »
    Wow, okay I WON'T be doing that! I was hoping to get more out of basic than 10 FPS but I'll just live with it. Other people can modify ImageToZXSpec if they want ;)
    If they can ;-) ...
    brownb2 wrote: »
    An Athon XP 2600 isn't slow... a ZX Spectrum is slow, you've been blessed with a fast machine ;) I tend to keep my computers until they finally break and this has been running games like Dead Space, Mass Effect , Fallout 3 etc etc quite well (a Geforce 7600GT with 128bit bus 512MB ram probably helps ;) )

    Athlon XP is slow in comparsion to modern computers. I have not tried a more modern platform because my 4850e is fast enough at moment, and the processor eats maximum 45 Watt. Together with the Asus 5750 graphics card it is fast enough even to play Left4dead, I also have a Atom CPU PC (2 GB DDR2 Memory) and P III 1000 (1.5 GB memory, GeForce 6200) which are good for data transfer to Spectrum, printing, downloading and such stuff. I prefer to have a slower but energy saving system.
    The P IV (1.7 GHz and 3.2 GHz) systems comsume around 150 Watts, without any speed advantage.
    Now I leaving to go to forever demo party... C U...

    LCD
Sign In or Register to comment.