Jump to content

Talk:PCX

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Too technical

[edit]

This is a nice article, but too technical, or at least technical without explanations for the casual reader. Any experts feel like updating this? Wyatt Riot 22:41, 8 September 2006 (UTC)[reply]

i think so too, even though i have a high IQ (about 146) i mean, i thought that they were data/video files that would affect the game "icy tower", because certain characters affect the way the "stuff" looks VFD642 1 january 2007

Your high IQ is certainly not in evidence, VFD642. Lack of punctuation and capitalization makes your comment almost incomprehensible.—QuicksilverT @ 23:26, 31 January 2011 (UTC)[reply]

Last statement unrelated

[edit]

The last statement should not be in this article since it refers to another meaning of PCX. Perhaps move it to another article; creating a disambiguation page for PCX would probably be necessary then.

Introduction improved

[edit]

Hello, I improved the introduction with a general paragraph about image file formats, which can aid (I think) to understood the basis of the PCX article. If you are satisfied with the simple description, you should untag the article.Ricardo Cancho Niemietz 17:51, 28 February 2007 (UTC)[reply]

Article untagged. I like most of the changes, except one:


While not totally irrelevant, this information is utterly non-specific to the PCX format. Keep in mind that this is an article about a graphics file format and not, say, Introduction to Computer Graphics 101. ;) --Stratadrake 03:11, 1 March 2007 (UTC)[reply]
(PS: Plural words can usually be wikilinked like this: [[link]]s .)
I agree with you, my added paragraph was very general. Simply, I tried to follow the instructions given in the tag. Curiously, after untag, the introduction has left *exactly* as it was.
I suggest that, in place of to drop completely the paragraph (and before to reedit the article), a mention could be made in the sense that the PCX was one of the first true image file formats used with IBM compatible PCs, due to the fact that early paint software simply dump the contents of the video buffer to a raw file. The Handmade Software's Image Alchemy tool, for example, still is capable to open such raw files (for example, John Bridges' PCPAINT .pic files), and it suppose their characteristics (res, color number) only based on the file size (due to every PC graphic mode has its own specific number of bytes).
Some years ago I wrote in C a PCX parser which supports every feature of the PCX format (even the 24 bit RGB flavour), so I planned to put in the article some details on PCX header; I think it is necessary due to the lack of a external link pointing to some public specification. And I'm sorry for not to have such a link; I lost the document source I used when I wrote the parser, but I still have my source code. I'll wait for your comments before I start with it, to kindly avoid a "war of editions".
Thanks also to note the plural style of wikilinks, but I think that for stylistic reasons, a single word should not to be in two colors. It's only my point of view.--Ricardo Cancho Niemietz 10:24, 2 March 2007 (UTC)[reply]
I've added an external link to ZSoft's PCX specification. It can also be found in other places, such as Wotsit.org. (By the way, the wikilink problem you are talking about was fixed years ago: links is not in two colours.) --Zundark 13:40, 2 March 2007 (UTC)[reply]
By "true" image format I guess you mean display-independent format? Okay, that definitely sounds worth mentioning. (I remember writing a PCX parser in VB6 so I could use it in some DX7 rendering. That was pretty fun, but also pretty stressful.) --Stratadrake 01:26, 3 March 2007 (UTC)[reply]
I've changed the intro paragraph in the commented sense. I hope it was adquire a definitive (or, at least, more stable) form. I'm also studyng how to give more technical details about the format without "paste" the entire specification. Thanks for put the link. And, due to I am a recent wikipedia member, I wasn't aware about the plural wikilinks issue.Ricardo Cancho Niemietz 09:59, 6 March 2007 (UTC)[reply]
Hope you don't mind me tweaking that intro to give it more standard terminology and meaning (ie device-independent rather than "hardware" ;) - I get the sense of what you mean, with it being a completely flexible format (luckily having 1,2,3,4,8 and 24/32 bits matches most requirement) rather than being completely tied to a particular machine's hardware and even its exact framebuffer (EG the old Koalapaint and Degas formats from the non-PC-monoculture days which did similar just with a little extra data such as pallete animation thrown in). Also I'm not entirely sure what Extended VGA is, when suitable definitions exist within regular VGA, XGA etc standards - though I kept the original for truecolor because going on about VESA cards and the like would be even more confusing and tedious 77.102.101.220 (talk) 20:25, 16 February 2010 (UTC)[reply]

Comparison with BMP

[edit]

I comparison with BMP would be very helpful. –Wulf (talk) 21:41, 28 January 2008 (UTC)[reply]

Is this a common Wikipedia thing? If so I'd be happy to do it. Don't understand why BMP though? Why not JPG, PNG or GIF? BMP dosen't have many features to compare with. 83.216.149.7 (talk) 19:54, 16 July 2008 (UTC)[reply]
The paint program bundled with Windows 3.1 saved and loaded .BMP and .PCX so BMP and PCX are kinda linked in a lot of folks' minds. Also PCX was the only compressed format saved by the original Windows paint program. Naaman Brown (talk) 19:25, 22 September 2009 (UTC)[reply]
They're also quite similar formats that do the same job as each other under different names, just with slight differences... like the position of the pallette data and so forth. I think BMP only does 1, 4, 8 and 24 bit (plus 4 & 8 bit RLE of it's own different design, later) single plane storage for a start, so it's slightly less efficient for 4 and 8 color images (rare as they are). Microsoft maybe just wanted something that did much the same as ZSoft's format without having to owe them any particular allegience for having PCX image code underpinning their operating system and apps instead of just having Paint compatible with it... or putting much work into it :)77.102.101.220 (talk) 20:29, 16 February 2010 (UTC)[reply]

4 plane 1 bit

[edit]

The Table A. Typical PCX Image Formats lists 4 plane 1 bit but not the much more common 1 plane 4 bit. Both are 16 color formats, but frankly 4 plane 1 bit PCX files are relatively rare. Naaman Brown (talk) 17:37, 24 September 2009 (UTC)[reply]

I think the table is based on a table from the PCX specification. I suspect you would be right about 4-bit 1-plane files. I never managed to find any examples of PCX files with less than 8-bit's, and I wonder if the hardware in question (EGA) organised the data in bit planes rather than nibbles.
83.216.149.7 (talk)
But wasn't one of the points of it all supposed to be that it was hardware-independent? Having it arranged this way would be mostly for coding convenience when loading/saving to and from that one type of card - you'd still need to do conversion on all the others anyway, so it's not like it's an absolute requirement to match it. Convert it all to indexed single-plane color when loading or saving then split it back into whatever the required bitplanes are. Just so long as you have enough memory or the committment to undergo a whole load of disc accesses to do the processing. 77.102.101.220 (talk) 20:33, 16 February 2010 (UTC)[reply]

PCX algorithm efficiency

[edit]

The PCX algorithm works best in compressing B&W monochrome images such as scanned text or line drawings because they tend to have long runs of black or white. The PCX algorithm may also be efficient with 16 color images, which tend to be cartoonish with long runs of the same color. With 256 color images with few runs of the same color (such as color reduced photographs) the PCX algorithm is not efficient. Naaman Brown (talk) 17:50, 24 September 2009 (UTC)[reply]

PC compression is byte based, it works no better with monochrome images than TGA, BMP or PNG compression so that doesn't seem relevent. CITT compression (used by fax machines) is much better at compressing B&W images. The same applies to simple line art style images, it works but not as well as other formats.83.216.149.7 (talk)

Finding the palette in an 8-bit PCX

[edit]

The statement "the only way to find the actual length of the image data is to read and process it" is not necessarily true. In my program IMAGUTIL after analyzing header data and identifying a file as a PCX image, the concluding PCX check is:

if (bits_pixel == 8)
{  //  PCX 256 color palette is appended to end of file
   fseek(f_in, 0L, SEEK_END);
   palette_off = ftell(f_in) - sizeof(PCXcolor256) - 1;
   fseek(f_in, palette_off, SEEK_SET);
   c = fgetc(f_in);
   if (c != 12)        // error
   palette_off = 0L;   // signal no palette
      else             // else retain defined palette
   fread(PCXcolor256, sizeof(PCXcolor256), 1, f_in);
}                      // PCXcolor256 is worka for color conversions

(f_in points to a random access disk file. PCXcolor256 is defined as 768 bytes.) Before processing the image file you:

fseek(f_in, 0L, SEEK_SET);    // reset pointer to start of file

but you do not have to read and process the image data to get the length of the file or the palette location. adding a sig Naaman Brown (talk) 14:56, 18 November 2009 (UTC)[reply]

What you have written is accurate, however the PCX format including padding each scan line to the end of a byte and also padding the rows of the image data, typically to an 8 row boundary.
You can reliably infer the existance of an 8-bit palette from the bit depth. However if the image is 4-bit and a programmer has written the palette to the end of the file, rather than in the header as they are supposed to, it's very difficult to be sure the palette exists. You could read back from the start of the file and find the value 12, except this dosen't prove that the 12 isn't part of the image data.
That is not a valid use of the PCX format, so I do agree with your comment. I mention it because many of the PCX files I use for test have this error. Many are 8-bit and have the palette id as C0h rather than 0Ch.
83.216.149.7 (talk) —Preceding undated comment added 14:22, 14 December 2009 (UTC).[reply]
I have edited this section of the page, the changes appear on the edit page but not in the article. I have no idea why that is, some kind of new Wikipedia behaviour? --83.216.149.7 (talk) 16:46, 18 August 2011 (UTC)[reply]

Bytes, palette indices or pixels?

[edit]

The description of PCX's compression confuses bytes with pixels and color values. All PCX files uses the same compression method, which works on bytes. A byte may contain several pixels or only part of a pixel. The way this is written is only valid for 8-bit indexed PCX files.83.216.149.7 (talk) 12:09, 10 August 2011 (UTC)[reply]

TGA has a run length of 128

[edit]

Please do not change the run length for TGA to 127. TGA uses 7 bits to indicate a run length, it does not allow zero length runs so the value zero indicates a run length of one and the value 127 indicates a run length of 128.--83.216.149.7 (talk) 18:46, 15 August 2011 (UTC)[reply]

Viewer Section

[edit]

A section for Viewers has been added to this article. It says PCX is supported by many programs but only mentions IrfanView by name. As such it appears to be advertising IrfanView in some sense. Given the lack of information I don't see the purpose for a viewers section in this article, there isn't a corresponding section in other image file articles on Wikipedia so I have removed this section.87.115.120.124 (talk) 12:43, 26 November 2012 (UTC)[reply]

Also, there is a link to proprietary viewer for Windows. Unlikely it adds much value to the article. Remove? — Preceding unsigned comment added by 46.242.97.19 (talk) 12:50, 18 February 2013 (UTC)[reply]

Diagram of "rows"

[edit]

Is there a particular reason that the "green" row has only 8 Gs whereas the other rows have 9 Rs, Bs or As?82.12.109.64 (talk) 20:26, 18 May 2017 (UTC)[reply]