VBXE Image conversion

[simonl]

I've been tinkering with some image conversion routines as part of another Atari-related project and I thought I'd hack them out into a standalone program in case it's any use to anyone.

 

Picture Import 1.0.zip

 

Some of the features it supports are:

 

• Error diffusion
  
• Variable size of the target image (width in bytes, height in scanlines)
  
• Standard .ACT format palettes
  
• Adaptive palettes (256 color and 16 color)
  
• Normal, low res and hi res modes
  
• Exporting as raw binary or compressed (details forthcoming, there's no viewer for the compressed images yet!)
  

 

The system requirements are:

 

• Windows XP or later
  
• .NET Framework 2.0
  

 

Just unzip the file with path names (the palettes need to go in a subfolder) and you should be good to go. If anyone wants to try it, let me know how you get on. I'll link to some blog postings with tips/explanation of the options when I get time, but each property of the converters has a line of description so that should give you enough to go on for now.

 

Here's some sample conversions:

 

(Standard resolution, Laoo palette)

 

(Standard resolution, adaptive palette)

 

(High resolution)

 

(Low resolution, adaptive palette)

 

(High resolution, generated palette with a bit of manual tweaking - you can do this through the application)

 

(Standard resolution, adaptive palette)

[Heaven/TQA]

cool... any chance of a OS X version???

[simonl]

cool... any chance of a OS X version???

 

Possibly, depends how bored I get . There's probably more chance of a cross-platform Java version, as the code would convert over quite easily from C# - perhaps as a plug-in for Eclipse. You could install Parallels or VMWare Fusion to save troublesome rebooting though, that's what I did while writing it as my main computer is a Mac.

 

Edit: If anyone's interested in the .XEF format stuff in the program, see here for details.

Edited September 15, 2009 by simonl

[atariksi]

cool... any chance of a OS X version???

 

Possibly, depends how bored I get . There's probably more chance of a cross-platform Java version, as the code would convert over quite easily from C# - perhaps as a plug-in for Eclipse. You could install Parallels or VMWare Fusion to save troublesome rebooting though, that's what I did while writing it as my main computer is a Mac.

 

Edit: If anyone's interested in the .XEF format stuff in the program, see here for details.

 

How come there's so many palettes floating around? Shouldn't there be a fixed palette for A8?

[simonl]

How come there's so many palettes floating around? Shouldn't there be a fixed palette for A8?

 

If you could get back to me when you've got everyone to agree what it is, that would be great . If you want to remove or add other palettes, see the PictureImport.exe.config file, the palettes section is currently:

 

  <palettes type="AnticDesigner.Atari.PaletteConfigurationSection">
   <availablePalettes>
     <palette name="Laoo" path="Palette\laoo.act" default="true"/>
     <palette name="Atari800Win Default" path="Palette\Default.act" />
     <palette name="Gray" path="Palette\Gray.act"/>
     <palette name="Green" path="Palette\Green.act"/>
     <palette name="Jakub" path="Palette\Jakub.act"/>
     <palette name="Real" path="Palette\Real.act"/>
     <palette name="Xformer" path="Palette\Xformer.act"/>
     <palette name="PAL" path="Palette\OlivierP.act"/>
     <palette name="NTSC" path="Palette\OlivierN.act"/>
     <palette name="MSX2 (VBXE)" path="Palette\MSX2.act" whiteIndex="255"/>
     <palette name="Grey Scale (VBXE)" path="Palette\GreyScaleVBXE.act" whiteIndex="255" />
   </availablePalettes>
 </palettes>

 

If a path is not rooted, it is assumed to be relative to the application folder. The base library of code that the application draws from also does TIP, HIP, Technicolour Dream etc. importing which is why I had all the different emulator palettes in there. I think laoo.act is the default PAL palette for VBXE. The Grey Scale and MSX 2 palettes are specific to VBXE and give you 256 grey levels (you may want to set the saturation to 0% on the image before conversion) or the linear MSX 2 palette respectively. Similarly, if you've come up with a specific VBXE palette for a game or demo then you can add this to the config and convert all images to use that. When you export a raw image with an adaptive palette, it will prompt you to optionally export the palette as a .act so you can use it in your code.

Edited September 15, 2009 by simonl

[danwinslow]

A linux version should be easily done via Mono and MonoDevelop. I may take a crack at it once i get my linux box back up.

[simonl]

A linux version should be easily done via Mono and MonoDevelop. I may take a crack at it once i get my linux box back up.

 

I tried its "parent application" under Mono and it didn't go too well as the UI is based round a .NET PropertyGrid and things like the UITypeEditor attributes didn't have any effect - I'll give it a go under the latest version though as that was a year or so ago.

[simonl]

A linux version should be easily done via Mono and MonoDevelop. I may take a crack at it once i get my linux box back up.

 

I tried its "parent application" under Mono and it didn't go too well as the UI is based round a .NET PropertyGrid and things like the UITypeEditor attributes didn't have any effect - I'll give it a go under the latest version though as that was a year or so ago.

 

 

Well, that was surprisingly painless - the caveats are that the hi-res converters don't work at all under Mono on the Mac (they do work under Mono on Windows, although the UITypeEditor problem is evident on the 16 color one), the standard and low res converters seem fine. If you want to run it under Mono on Mac, replace the application config file in the zip with something like this one and it should run. The text rendering in the application itself looks like crap, but that's Mono for you - possibly installing the Tahoma font might improve matters. There are a few problems with it logging exceptions to the terminal window when you quit, but if you're quitting it anyway it's not really a problem. I haven't tried Linux but imagine it would run as well as the Mac one does.

 

PictureImport.exe.config.zip

[simonl]

cool... any chance of a OS X version???

 

Here you go, you'll need to install Mono if you don't already have it (available here).

 

PictureImport 1.0 Mac OS X.zip

 

Now, how's that for service? No hi-res importers, but I'm sure you can live with that for now, the problem's in the non-square pixel aspect ratio, but as GDI+ ignores that anyway I can just comment those lines out and rebuild sometime.

[Tezz]

With regard to the differing palettes, it has been an issue for a while which a standard seemingly has not been agreed on. Different users have preference to different palettes that they perceive as being the closest to the real thing. For me Laoo's palette is the closest and that's the one I stick to. The palette was created (so I understand) by working from an output of an XE to a pc capture card.

Edited September 15, 2009 by Tezz

[atariksi]

With regard to the differing palettes, it has been an issue for a while which a standard seemingly has not been agreed on. Different users have preference to different palettes that they perceive as being the closest to the real thing. For me Laoo's palette is the closest and that's the one I stick to. The palette was created (so I understand) by working from an output of an XE to a pc capture card.

 

Can you post a picture of that palette? I want to compare my NTSC A8 output to it -- I guess you are using PAL.

[Tezz]

With regard to the differing palettes, it has been an issue for a while which a standard seemingly has not been agreed on. Different users have preference to different palettes that they perceive as being the closest to the real thing. For me Laoo's palette is the closest and that's the one I stick to. The palette was created (so I understand) by working from an output of an XE to a pc capture card.

 

Can you post a picture of that palette? I want to compare my NTSC A8 output to it -- I guess you are using PAL.

Here's a pic of the Laoo palette. It was based on a PAL output I belive so there will likely be a difference to the recognised NTSC colours.

Edited September 15, 2009 by Tezz

[candle]

i need to ask

why to bother with fixed pallete? you can load any pallete you want into vbxe...

[simonl]

i need to ask

why to bother with fixed pallete? you can load any pallete you want into vbxe...

They're mostly in the program for historical reasons, but there's two cases I can think of where you would do this:

 

• You're compositing multiple pictures together and they need to use the same palette, either one of the standard ones or a custom one you've created e.g. ripped from MAME
  
• You want to make something traditionally "Atari looking'
  

 

Alternatively, tick the "Adaptive" option on the palette menu, which will generate a 256 color best-fit palette from the image.

[candle]

understood

 

Simon, could you make in such way, that it could render the picture to 1024 colours (up to 256 in one line) and split color entries into 4 palettes

we could use such application to make any use of 1024 colors modes

[atariksi]

With regard to the differing palettes, it has been an issue for a while which a standard seemingly has not been agreed on. Different users have preference to different palettes that they perceive as being the closest to the real thing. For me Laoo's palette is the closest and that's the one I stick to. The palette was created (so I understand) by working from an output of an XE to a pc capture card.

 

Can you post a picture of that palette? I want to compare my NTSC A8 output to it -- I guess you are using PAL.

Here's a pic of the Laoo palette. It was based on a PAL output I belive so there will likely be a difference to the recognised NTSC colours.

 

That's CTIA so I guess I interpolate for GTIA. According to Mapping the Atari, the colors should be same for PAL/NTSC but someone else was claiming they are different.

[simonl]

understood

 

Simon, could you make in such way, that it could render the picture to 1024 colours (up to 256 in one line) and split color entries into 4 palettes

we could use such application to make any use of 1024 colors modes

No problem, I've already been thinking about this, I expect the user would have to specify the lines on which the palette changes take place and then I can run the adaptive palette generation multiple times. I don't know if you saw my post about the file format I'm working on for these images (here) but I need to think how to embed the palette changes in there so the displaying program on the Atari can interpret it - maybe just add a new section to the header with number of palette changes, and then the line and palette for each change?

[candle]

i'll take a peek now

i think simplest way to do it would be 256 byte table with pallete numbers to use in each scanline, and then all 4 palettes

i think user could point sections to alter, but app should be able to work automatically

[Tezz]

That's CTIA so I guess I interpolate for GTIA. According to Mapping the Atari, the colors should be same for PAL/NTSC but someone else was claiming they are different.

It's been a dark area for me only having used pal based systems but as you say there are opinions that they differ. I hope they are the same so that a universal standard can be set for emulation.

[candle]

from my personal experience - blue basic screen looks diffrent for PAL and NTSC machines, thus i was the one asking for color pallete for NTSC systems

for sparta dos this could be solved with little command line tool that would load desired act file and thus personalise the looks of new display

i don't know if and how mydos is handling command line parameters, and how does the mydos autorun works

 

i think someone more experienced as an atari coder should write something about (or possibly the tool)

 

Simon: can block for deflation be splitted that it would decompress into 4k window? (this is smallest window size that you can set for fx 1.20 core)

[simonl]

Simon: can block for deflation be splitted that it would decompress into 4k window? (this is smallest window size that you can set for fx 1.20 core)

 

Sure, I can add an option at export time for the block size (4kb, 8kb, are there any other values?) if that would be sufficient (although if an image was exported with 8k blocks this would still require 8k at decompression time). Also, is your proposed soundboard going to use a similar window-based method for access to the sample RAM, or do you think it would be based on streaming it via a register? I'd like to write a package linker for code, graphics, sound that would support VBXE RAM, built in RAM and the soundcard's RAM based on the same type of format and compression.

[Heaven/TQA]

cool... any chance of a OS X version???

 

Here you go, you'll need to install Mono if you don't already have it (available here).

 

PictureImport 1.0 Mac OS X.zip

 

Now, how's that for service? No hi-res importers, but I'm sure you can live with that for now, the problem's in the non-square pixel aspect ratio, but as GDI+ ignores that anyway I can just comment those lines out and rebuild sometime.

 

thanks! but I was little shocked when I saw the "non os x" look... but works... only little bit slow in terms of GUI refresh at least on my imac and leopard 10.6

[+CharlieChaplin]

Well,

 

the problem of different palettes is not only because of NTSC vs. PAL. Its also Atari 400/800 vs. XL vs. XE. I had both XL and XE computers and the colours of the XL`s and XE`s were always a little different (not that much, but enough one could see the difference in pictures and games). In the meanwhile I have sold all my XE computers and kept only the XL`s. Personally I have to say that the Laoo palette is quite close to my XL`s, but the OlivierP palette is much closer (still not 100% of my XL colours)... and yes, I am PAL user.

 

Now, on the emu simply load some of the TIP animations I did and play them back with OlivierP, Laoo, G2F and other palettes - you will notice quite big differences in the display of 256 colours !!! All tip animations were done with PAL setting, so just switch to NTSC and waahh, the colours then look extremely awful... luckily this is not so bad with the old A8 games on the real A8 (there are no such extremes of NTSC and PAL colour displays on the real machines, like on the emu - but then again, lots of old A8 games were only 4 colours)...

 

-Andreas Koch.

[simonl]

Now, on the emu simply load some of the TIP animations I did and play them back with OlivierP, Laoo, G2F and other palettes - you will notice quite big differences in the display of 256 colours !!! All tip animations were done with PAL setting, so just switch to NTSC and waahh, the colours then look extremely awful... luckily this is not so bad with the old A8 games on the real A8 (there are no such extremes of NTSC and PAL colour displays on the real machines, like on the emu - but then again, lots of old A8 games were only 4 colours)...

I had the same problem when I was playing around with TIP images where the hue is different between two frames as well as the lum being different. In theory it gives you ~4096 colors, in practice it gives you a purple mess unless you're on an emulator with the same palette you generated with or an Atari/monitor combination that matches the palette you generated with. It's a shame because the results were quite nice e.g.

 

 

becomes:

 

 

but the effects are too variable on different h/w for it to be much use. I'll maybe look at analysing the colors between different palettes to see if there are any "safe" combinations to use.

[mimo]

A noob question for you. I am not clever enough to get the emulator working, but I am looking forward to receiving my vbxe board.

My question is, how do you display these images using an Atari with vbxe fitted?