What's the rule of thumb for converting images

[rcman]

Hi you Coding masters,

So what is the rule of thumb when converting images. If I have a 320x200 BMP image and I use something like XNView to convert them to IFF what should I expect.

Say I want to have 16x16 blocks that I've made in windows and I want to use them on the Amiga. I used a combination of Dpaint V and PPaint but I'm finding it's not giving me what I want.

What can you tell me oh Guru of programming meditation?

RC

[volvo_0ne]

I'd like to know too, they always seem to be in a random palette order too!

[Daedalus]

Well, what are you looking to do with them? The palette order is something you have little control over when you converting images from a colour-per-pixel format to a palette-based colour look-up format like the Amiga uses. The conversion process will end up creating a palette of the most used / most suitable colours and recreating the image with them, based on one of a number of possible algorithms.

In general though, you might get better results doing the conversion on the Amiga. I generally use PPaint for that - it will read all the main PC formats too and has several options for colour reduction that give excellent results.

If you're looking to use a particular palette, you can use PPaint to remap an image to those colours. Then, depending on how it looks, you can do some tweaking of the destination palette and repeat the mapping until you get what you need.

The palette editing functions in PPaint and DPaint let you rearrange the colours and then remap the image to suit, but I wrote a more comprehensive palette editor that can load and save palette objects, copy and past blocks of colours and so on. It's called PaletteEd, and might be useful It's AGA-only though I'm afraid...

[Master484]

I'd like to know too, they always seem to be in a random palette order too!

I have always drawn my Amiga graphics in Windows Paint, and save them in PNG, and then convert them to Amiga IFF using XnView.

The colors of the resulting image will usually show wrong in Blitz, but a simple trick will solve this problem.

Just place your game palette colors to the upper left corner of the image you're trying to convert, like this:



Make sure that the colors appear in right order, so put your game palette color 0 first, then color 1, then color 2, and so on.

This gives the resulting IFF image the right colors.

I think XnView reads the colors from the image one pixel at a time, starting from the upper left corner and automatically creates the palette from them. The first color it sees becomes palette color 0, and the next color becomes palette color 1, and so on.

---

Another important thing is the OCS color values. On AGA each RGB component can have values from 0-255, but on OCS the RGB values have a range of 0-15.

So on when making AGA graphics the colors from Windows Paint can be used directly, and they'll show up exactly the same on an Amiga AGA screen. But on OCS the colors will not be 100% the same. Although I think that on OCS the RGB values convert automatically to closest equivalent values, so the image will show up, but the colors can be slightly off.

But there is a workaround for this problem too.

When creating your graphics on PC, just use RGB values that correspond directly to the OCS RGB values.

Here are all OCS RGB component values between 0-15 and their 0-255 color equivalents.


0 -- 0
1 -- 17
2 -- 34
3 -- 51
4 -- 68
5 -- 85
6 -- 102
7 -- 119
8 -- 136
9 -- 153
10 -- 170
11 -- 187
12 -- 204
13 -- 221
14 -- 238
15 -- 255


Draw your image using only those RGB values for all colors, and the colors should show up exactly the same on an Amiga OCS screen.

[Daedalus]

Originally Posted by Master484

I have always drawn my Amiga graphics in Windows Paint, and save them in PNG, and then convert them to Amiga IFF using XnView.

Paint? Is it really worth all that extra hassle over using, say, PPaint or DPaint? Under emulation if you don't have a suitably-equipped Amiga.

The colors of the resulting image will usually show wrong in Blitz, but a simple trick will solve this problem.

Not just Blitz, but in general the palette will be arranged as the conversion algorithm sees fit.

Just place your game palette colors to the upper left corner of the image you're trying to convert, like this:

Make sure that the colors appear in right order, so put your game palette color 0 first, then color 1, then color 2, and so on.

This gives the resulting IFF image the right colors.

I think XnView reads the colors from the image one pixel at a time, starting from the upper left corner and automatically creates the palette from them. The first color it sees becomes palette color 0, and the next color becomes palette color 1, and so on.

Yep, it's likely something like that alright. Just bear in mind that other conversion algorithms are likely more sophisticated and might not necessarily adhere to that scheme. Also, bear in mind that if you're only using a single sheet of images, the order might not necessarily matter. Blitz can read the palette information from an image and use it as it is. If you need to share a palette between multiple images or otherwise have control over it, remapping an image with the correct colours on the wrong palette order is trivial in DPaint or PPaint.

Another important thing is the OCS color values. On AGA each RGB component can have values from 0-255, but on OCS the RGB values have a range of 0-15.

Indeed, forgot to mention this aspect...

So on when making AGA graphics the colors from Windows Paint can be used directly, and they'll show up exactly the same on an Amiga AGA screen. But on OCS the colors will not be 100% the same. Although I think that on OCS the RGB values convert automatically to closest equivalent values, so the image will show up, but the colors can be slightly off.

What actually happens is that the 4 least significant bits of the value are simply ignored, leaving just the upper 4 bits to determine the level of colour.

But there is a workaround for this problem too.

When creating your graphics on PC, just use RGB values that correspond directly to the OCS RGB values.

Here are all OCS RGB component values between 0-15 and their 0-255 color equivalents.

[...]

Draw your image using only those RGB values for all colors, and the colors should show up exactly the same on an Amiga OCS screen.

Sort of, but not quite. If you look at the upper 4 bits of the values involved, your 8-bit values start to differ from the 4-bit OCS values as you move up the scale. You'll get similar results, but they won't be 100% identical to what you intended.

[Master484]

Paint? Is it really worth all that extra hassle over using, say, PPaint or DPaint?

Maybe not, but I have always used MS Paint for almost all gfx work, and so I just stubbornly continue using it.

What actually happens is that the 4 least significant bits of the value are simply ignored, leaving just the upper 4 bits to determine the level of colour.

Ok, thanks for the info.

And about the color value conversions that I posted, I think they should be right.

I have checked many OCS game screenshots, opening them on Paint and checking the RGB values of different colors, and the values have always been those that are in that list.

But I quickly checked some binary values from that list, and for example OCS value 4 in binary is 0100 and the corresponding RGB value of 68 is 0100 0100. And OCS value 9 is 1001 in binary and corresponding RGB value 153 is 1001 1001. And OCS value 14 is 1110 and the corresponding RGB value 238 is 1110 1110. So everything seems to be right, although I might be wrong of course.

[Daedalus]

Originally Posted by Master484

Maybe not, but I have always used MS Paint for almost all gfx work, and so I just stubbornly continue using it.

Well, fair enough!

I have checked many OCS game screenshots, opening them on Paint and checking the RGB values of different colors, and the values have always been those that are in that list.

Interesting... It would be of interest to see the values in the raw assets, rather than a screenshot from an emulator. But that seems strange as it's not how the OCS chipset really worked.

But I quickly checked some binary values from that list, and for example OCS value 4 in binary is 0100 and the corresponding RGB value of 68 is 0100 0100. And OCS value 9 is 1001 in binary and corresponding RGB value 153 is 1001 1001. And OCS value 14 is 1110 and the corresponding RGB value 238 is 1110 1110. So everything seems to be right, although I might be wrong of course.

Yeah, it's a recommendation in the RKRMs for using 4-bit colour, that you fill the redundant bits with a copy of the relevant 4 bits to assure compatibility with both OCS and AGA chipsets, which is where that table of numbers came from. But converting the other way is a little different.

[rcman]

Hmm,

I think I'm even more confused. uhg
RC

[bjadams]

I never managed to convert a picture I reduced to 32 colours on Windows (using RGB range 0-255) to look good on OCS, because the RGB values have a range of 0-15.
When using graphic software on Windows, reducing to 32 colours gets acceptable results, that's why I am doing it this way. But I'm stuck with the palette problem.
So far I did not find a program on Windows to limit the colour palette to RGB 0-15 from the start.

[volvo_0ne]

Originally Posted by bjadams

I never managed to convert a picture I reduced to 32 colours on Windows (using RGB range 0-255) to look good on OCS, because the RGB values have a range of 0-15.
When using graphic software on Windows, reducing to 32 colours gets acceptable results, that's why I am doing it this way. But I'm stuck with the palette problem.
So far I did not find a program on Windows to limit the colour palette to RGB 0-15 from the start.

Maybe someone will now make one & post it on Aminet as an Amiga converter?

You never know....

[bjadams]

I wish!

[malko]

Maybe of any help ? GrafX2 (from posts #71 to #79)

[Daedalus]

I know it's probably not much help, but my PaletteEd program can be used for rearranging palettes, and also includes a feature for rounding a palette to 4-bit depth (OCS/ECS colour). This might be useful to use for defining a target palette with the required colour order and bit depth to which you can remap images in PPaint for example.

It is however AGA only I'm afraid...

[bjadams]

Could be helpful. thanks

[meynaf]

Originally Posted by Daedalus

Interesting... It would be of interest to see the values in the raw assets, rather than a screenshot from an emulator. But that seems strange as it's not how the OCS chipset really worked.

The trick is not in how OCS chipset works, but in how AGA chipset works.
When a palette entry is written to the high nibble, it is copied to the low nibble as well, thus multiplying the value by 17.
If AGA had shown OCS images differently than OCS itself did, we would know it by now, wouldn't we ?