Viewing raw images in correct colors

[andreas]

Hi

I have a color problem with this raw image (attached - change extension if necessary, bloody extension filters :P)

I've tried it with PicCon (thanks Stingray ), but the colors are all wrong.

Format is recognized as 8bit iff (bin), not to be confused with IFF-ILBM which *always* has the FORM-ILBM header at the beginning of the file.

I've also tried with Kefrens IFF Converter, but colors are wrong there too.

Where's my (logical) mistake?

[StingRay]

You need to load the palette. Raw files don't have any color information attached.

[thor]

Originally Posted by andreas

Format is recognized as 8bit iff (bin)

which is wrong, it's 3bpp (8 colors) and 320x128 resolution (320/8*128*3=15360) and as StingRay said, there is no palette data, so you could either rip that (don't know where you got the picture from) and load it for the image or try to adjust the colors by yourself.

[andreas]

OMG, adjust them myself, good one ;-)

Thanks for the info, this does make lots of sense that these pics have no palette information :)

Well it's taken from a game ... and I could see hardcoded relative pic paths in the executable ( :pics/pic20 ), hence I would assume the palette is set by the main program or a subroutine...so without disassembling, it won't be too easy to find the right colors, hah fantastic :-)

which is wrong, it's 3bpp (8 colors) and 320x128 resolution (320/8*128*3=15360)

Doubtful! When I set screenmode to 320x256 non-interlaced PAL, the graphics appear in correct aspect ratio.
If 320x128 were true, pics would appear quite vertically stretched!

[thor]

Doubtful! When I set screenmode to 320x256 non-interlaced PAL, the graphics appear in correct aspect ratio.
If 320x128 were true, pics would appear quite vertically stretched!

It's not a fullscreen picture (would also explain the little amount of colors), maybe something in a RPG where party information fills the rest of the screen. 15360 is the filesize and exactly what it requires for 320x128x3 (see equation above). Load the picture in IFFMaster, set resolution to 320*400*1. You'll see the same three pictures thrice, which are the bitplanes. You can also check the height of each row. Then set height to 128 and 3 bitplanes, you'll see it's correct.

OMG, adjust them myself, good one ;-)

Well, would of course depend on the accuracy wanted ;) But at least I got a decent looking picture in a very quick test, it's just 8 colors and with a bit of common sense...

Well it's taken from a game ... and I could see hardcoded relative pic paths in the executable ( :pics/pic20 ), hence I would assume the palette is set by the main program or a subroutine...so without disassembling, it won't be too easy to find the right colors, hah fantastic :-)

What game is it? Depends on your skills, but finding the correct colors shouldn't take too long or you could play the game and save the picture to get the colors or use a monitor to check the color values in the registers.

[andreas]

to cut a long story short: yes you were right
in my sample pic, all pics are already duplicate!

but the 400 (exactly even 384 [128 * 3]) seems reasonable because I *DID* try to change colors with my sample above, but only first 4 color fields reacted on my modifications...

also thanks for the IFFMaster pointer, will try that one too...

BTW, as far as I understand the matter: am I right that the pic parts get MERGED when I reduce the Y axis to a height of Y divided by the amount of bitplanes?
They actually should because the 3-way pic in 384 vertical pixel reminds me a bit of process-color-printing (Vierfarbendruck) used for professional printing products like encyclopedia: partial pictures absolutely identical in pixels, but different in color values; eventually merged for the final product.

[Leffmann]

Originally Posted by andreas

BTW, as far as I understand the matter: am I right that the pic parts get MERGED when I reduce the Y axis to a height of Y divided by the amount of bitplanes?
They actually should because the 3-way pic in 384 vertical pixel reminds me a bit of process-color-printing (Vierfarbendruck) used for professional printing products like encyclopedia: partial pictures absolutely identical in pixels, but different in color values; eventually merged for the final product.

In a sense yes, but the separate image planes are not separated in terms of color as such. Each pixel value in an 8 color image is represented by 3 binary digits, and each image plane contributes to one of the 3 digits.

[andreas]

Thanks everybody for participating in this thread: I've learned lots of things now!

I could even use KEFRENS IFF-Converter from days of yore to get proper pictures!
I just had to force the program to use 128 pixels only on the Y axis!
This did indeed cause the picture to get its bitplanes merged, so I finally ended up with a picture with more than 4 colors! Nice!