🔒 Locked

PCX issues

Started by sidvicious Jan 21, 2004 at 8:21 PM 6 replies 300+ views

Original Post

Jan 21, 2004 at 8:21 PM

I''m writing PCX support for an OpenGL game engine that i''m working on. I read/decode/display version 5 PCX files with 8bits per pixle plus a 256 color palette or 24 bits per pixle with no palette. This works completely fine for PCXs with a width that is even. I resized two of my test images to have an odd width with Gimp(one 24 bit, one 8 bit w/ palette), but the bytes per line field in the header says the bytes per line is an odd number, which violates the specification. From what I understand the end of each scanline should be padded with extra bytes to make the scanline have an even lenght. I tried going by the line length reported in the header, and this does not display correctly. I try assuming that it is the next even number, and I ignore the padding at the end of each scanline, but I run out of data before the entire image buffer is full, so obviously the padding is not there. Can someone explain to me how I''m supposed to read these in? My code works 100% for images with even widths, and I wrote code, which I though would handle odd widthed images according to the PCX specification, but it does not appear to work.

Deranged

Jan 21, 2004 at 8:31 PM

Maybe its because odd nubers arent and cant be powers of two(2 4 8 16 32 64 128 256 512 etc...)

[Mercury Software] [Google!] [ Look I DONT Follow Trends ]

sidvicious

Jan 21, 2004 at 9:46 PM

quote:
Original post by DerAnged
Maybe its because odd nubers arent and cant be powers of two(2 4 8 16 32 64 128 256 512 etc...)

[Mercury Software] [Google!] [ Look I DONT Follow Trends ]

I know odd numbers are not and can not be powers of two. I''m not an idiot. I have a degree in Computer Science, so I hope I know what a power of two is. The PCX specification does not require powers of two for the lenght of a scanline, the only requirement AFAIK is that they are even numbers. The bytes per line is supposed to be rounded up to the next even number in the case that the image is an odd width. My code works fine for non-powers of two as long as they are even, for example one of my test images is 300 by 200.

Deranged

Jan 21, 2004 at 9:49 PM

quote:
Original post by sidvicious
quote:
Original post by DerAnged
Maybe its because odd nubers arent and cant be powers of two(2 4 8 16 32 64 128 256 512 etc...)

[Mercury Software] [Google!] [ Look I DONT Follow Trends ]

I know odd numbers are not and can not be powers of two. I'm not an idiot. I have a degree in Computer Science, so I hope I know what a power of two is. The PCX specification does not require powers of two for the lenght of a scanline, the only requirement AFAIK is that they are even numbers. The bytes per line is supposed to be rounded up to the next even number in the case that the image is an odd width. My code works fine for non-powers of two as long as they are even, for example one of my test images is 300 by 200.

ok i never use PCX ive used PNG more often lately which does require bowers of two just like jpeg and bmp.

[Mercury Software] [Google!] [ Look I DONT Follow Trends ]

[edited by - DerAngeD on January 21, 2004 10:50:05 PM]

FReY

Jan 22, 2004 at 2:22 AM

DerAnged, those image formats don''t require powers of 2 either. It''s probably your texture loading that requires that the images be powers of 2, not the image specification itself.

sid, have you tried with really tiny images and see how they work? (eg. 3x3) Maybe the visual artefacts would give a clue as to what is happening...
Also, you might also assume that the Gimp does everything correctly when in fact it may not. Try some other software if you can find it and try write the same images out (sorry, I can''t be more useful with a link or something)

-FReY

superpig

Jan 22, 2004 at 5:00 AM

quote:
Original post by sidvicious
I know odd numbers are not and can not be powers of two. I''m not an idiot. I have a degree in Computer Science, so I hope I know what a power of two is.

Chill out, dude...

To be honest I''ve always had problems with the PCX ''standard.'' The traditional PCXes I used under DOS were incompatible with the ones saved by Windows Paint (i.e. one type always crashed Andre''s PCX loader, the other did not), and yet I''m not quite sure how the two could deviate from the standard by accident...

What if you were to add padding as you read in each scanline? That is, read in what it tells you is there, and then add the extra byte to make it an even width.

sidvicious

Jan 22, 2004 at 8:58 AM

quote:
Original post by superpig

What if you were to add padding as you read in each scanline? That is, read in what it tells you is there, and then add the extra byte to make it an even width.

I''ll try this, and small 3x3 images next.

It appears that Gimp doesn''t honor the bytes per line has to be even requirement, but in my mind as long as my code goes by what value is in the bytes per line header field it should work... so if gimp says there are 299 bytes per line, and the width of the image is 299 I shouldn''t have to worry about padding even though I am expecting a value of 300 byptes per line on an image with a width of 299.

I''m not even sure if I''ll ever need to read a PCX with an odd width in my engine, so I might not even bother to fix this problem until I need it...I just hate having something that only half works though

superpig

Jan 22, 2004 at 9:09 AM

quote:
Original post by sidvicious
in my mind as long as my code goes by what value is in the bytes per line header field it should work...

Yeah, but evidently that''s not the case

Unless we suppose that the scanline length isn''t the only part of the specification that GIMP isn''t adhering to. But then I guess your even-sized images probably came from it as well...

Hrm. By padding the data out like I suggested, you''re basically just converting a nonstandard image into a standard one - in a production system it might even be something you''d want to move out to a seperate program. Though that program would probably do other things (like use something a little more sophisticated than RLE compression

).

GIMP is open-source. Maybe you''d be better off fixing the source of the problem?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.