Sign in to follow this  
Joshua Bell

PCX Plug-In

Recommended Posts

Joshua Bell    0

I needed to muck with some PCX images. Searching the forum showed some other interest (http://paintdotnet.12.forumer.com/viewtopic.php?t=334), so I buckled down and wrote a plug-in for it.

As I said over yonder (before Rick showed me the error of my ways):
 

 

I've written a PCX file type plugin for Paint.NET which supports:

* Loading 1-, 2-, 4-, 8- and 24-bit color PCX files
* Saving 4- and 8-bit PCX files

The save path is based heavily on PDN's GIF file type handler. It uses the palettization code from PaintDotNet.Data.Quantize (a copy of the code shoved into a different namespace, since those classes aren't exposed) and the same UI (again, a copy; someday there might be more options).


I've tested it on various sample images I could find online, but haven't used it thoroughly in content production cycles. Let's call this an early alpha. If anyone is interested in trying it out, e-mail me at inexorabletash@hotmail.com. After at least a few reports of it working I'll put the binary up somewhere for download.

UPDATE:

I've had enough positive feedback that I'll go ahead and post a direct download link:

http://www.calormen.com/tmp/PcxFileType.zip

Please let me know if you have any problems with it.


UPDATE:

A user kindly reported that the plug-in seemed to bloat the sizes of files on save (e.g. load a 16k image, save it at 300k). I investigated and it turned out that my code had a flaw such that compression would never occur. Oops. (Serves me right for wanting more of a file loader than a file saver.)

I've updated the code to version 0.9.2.0, which is available for download at the above URL.

Sorry for any inconvenience!

UPDATE (2007-10-20):

The plug-in is provided AS-IS, and is free for commercial and non-commercial use, and may be freely distributed.


UPDATE (2007-10-22):

Updated to 0.9.3.0. Now conforms to PDN 3.10 plug-in API so may require an update. Now forces monochrome (1-bit) images to black/white palette.

 

UPDATE (2014-06-24):

Updated to 0.9.4.0. Now works with PDN 4.0, so far as I can tell. Same download link as the above.

 

UPDATE (2015-01-09):

 

I may have mucked up the last ZIP. Anyway, rebuilt with .NET 4.5 requirement, republished. Otherwise, no changes.

Edited by Joshua Bell

Share this post


Link to post
Share on other sites
Rick Brewster    825

Bumping because I saw this thread had some revisions.

Also, you should know that for 3.0 FileTypes, you can simply call Quantize() to do your quantization. It is a protected instance method of FileType (as opposed to public static).

Share this post


Link to post
Share on other sites
Joshua Bell    0

Someone emailed me asking if there was a way to ensure that when loading then re-saving, the same palette was used as when loaded. (E.g. if you have special needs like black/white as the first two colors or some such)

The plug-in doesn't support this. I'm not sure of the best way to do this with Paint.NET's infrastructure. One approach might be to have the plug-in (1) annotate the document with the palette, and then on save either (2a) force-quantize to that palette or (2b) quantize and use the same pallette ordering only if they match.

The source palette could probably be stuffed into user-defined metadata. From a quick glance at the Document/MetaData code this seems like it'd be supported, but it was a really quick glance.

If there was an overload of Quantizer.Quantize() which took a Palette (of some variety) in lieu of calling GetPalette(), then approach #2a would appear to be relatively straightforward. Doable now by copying the source, but perhaps this could make it into PDN 3.0?

(Other fancy things to do would be to have the save UI let you pick a pallette file and/or another image to load a palette from, but I'm not going there.)

Any other thoughts?

(And if anyone wants to beat me to this, I'm happy to share the source.)

Share this post


Link to post
Share on other sites
Joshua Bell    0

The ZIP is updated with a new build - this one has an option on save called "Use original palette". If checked, and if the document was originally loaded as a PCX (or as a PCX and saved as a PDN file, I think) then it will re-save using the original palette.

The user who requested it reports "It works perfect now" so I guess it's behaving as desired.

Share this post


Link to post
Share on other sites
Joshua Bell    0

Hrm... I probably should have looked at the new API sooner before 3.0 went final... but I was waiting for it to be final before taking a new dependency. D'oh!

I had thought that the classes in the PaintDotNet.Data.Quantize namespace would just be made public. Instead, there's the new FileType.Quantize method.

To support requests I've received via email (see above) I support two options - quantizing to an existing palette or dithering. So the PaintDotNet.Data.Quantize.OctreeQuantizer and PaletteQuantizer and PaletteTable are perfect.

I'm not seeing how to do this via FileType.Quantize.... but it's late and perhaps I'm missing something.

Share this post


Link to post
Share on other sites
Renaux    0

Hi everyone!

Is there a possibility to update the .pcx filetype-plugin, so that I can also open .dcx files.

As far as I know .dcx is a Fax-format and is nothing else than more .pcx files, like pages.

:?:

Thanx

Share this post


Link to post
Share on other sites
Limerick    0

Hello everybody,

After installing PDN v3.10 and the PCX plugin, the .pcx images I open with PDN are all black.

But these images are well opened by Faststone Image Viewer for example.

Do you have any idea of what to do ?

Thank you for your help.

Share this post


Link to post
Share on other sites
Joshua Bell    0

Limerick:

Hey - sorry to hear you're having trouble with the files and filter.

Email me one of the PCX files that's not working for you and I'll see if I can figure it out. inexorabletash -at- hotmail -dot- com

Renaux:

Yikes, never saw this. DCX does indeed look like it would be fairly simple to support (http://www.fileformat.info/format/pcx/egff.htm) - I could treat each image in the DCX bundle as a PDN layer (and vice versa). It'd be strange when the images were different sizes, but that's probably rare in practice.

If this is still of interest to anybody, let me know.

Share this post


Link to post
Share on other sites
Joshua Bell    0

FYI, Limerick's image has the following characteristics:

PCX 3.0 (includes palette)

1-bit per pixel (i.e. monochrome)

Included palette is all dark (so the image appears all black)

Other sample PCX images that were v2.8-with-palette or 3.0 and 1-bit per pixel included a reasonable palette (i.e. black/white as the two colors). I suspect that other PCX loaders slam the palette to black/white for 1-bit images... so I've done the same.

If Limerick's other images test out OK with the change, I'll post an update plug-in for download.

Share this post


Link to post
Share on other sites
Limerick    0

Hello Joshua,

Your plugin works fine now.

Yes, in fact, I need to print monochrome images (1bit).

I don't know what's going on with the palette. These are images sent to me and I've to change them to monochrome.

I do this while saving the files from FastStone in the Advanced window.

This was the easiest way to be sure the file was monochrome.

Maybe there's a best way to do but with your help, I manage to reach my goal.

Thank you very much for your very kind support.

PS : How was the hour without power? It may be fun :)

Share this post


Link to post
Share on other sites
Joshua Bell    0

Glad things are working for you!

Sadly, I completely missed the Lights Out SF event - having a 5 year old is a bit distracting.

However, we had a 6-hour power outage on our block a few weeks ago, so I'll call it even.

Share this post


Link to post
Share on other sites
Joshua Bell    0

Just a note that I received a bug report that the PCX plugin wasn't working with PDN 4.0. I've tweaked it, seems to work, bug reporter is happy. Same link as usual in the top post.

 

Side note: I still can't use the built-in FileType.Quantize method, because the plugin optionally allows (1) variable alpha cutoff support and (2) quantizing to a target palette. Bummer.

Share this post


Link to post
Share on other sites
Rick Brewster    825

Just a note that I received a bug report that the PCX plugin wasn't working with PDN 4.0.

 

Can you post the error / exception that it was giving?

 

Were you using Quantize(Surface, int, int, ProgressEventHandler) before? I removed one of the overloads in 4.0 (and also in 4.0.1) because I thought no one was using it. I was wrong. I've added it back for 4.0.2

 

If you'd rather update now without having to wait for 4.0.2, you can use Quantize(Surface, int, int, bool, ProgressEventHandler), which I recommend, and you can use the implementation of the other Quantize(...) as a guide:

        protected Bitmap Quantize(Surface quantizeMe, int ditherAmount, int maxColors, ProgressEventHandler progressCallback)
        {
            // This is the old version of the function took maxColors=255 to mean 255 colors + 1 slot for transparency.
            // The new version expects maxColors=256 and enableTransparency=true for this.
 
            if (maxColors < 2 || maxColors > 255)
            {
                throw new ArgumentOutOfRangeException(
                    "maxColors",
                    maxColors,
                    "Out of bounds. Must be in the range [2, 255]");
            }
 
            return Quantize(quantizeMe, ditherAmount, maxColors + 1, true, progressCallback);
        }

Share this post


Link to post
Share on other sites
Joshua Bell    0

 

Can you post the error / exception that it was giving?

 

Were you using Quantize(Surface, int, int, ProgressEventHandler) before? I removed one of the overloads in 4.0 (and also in 4.0.1) because I thought no one was using it. I was wrong. I've added it back for 4.0.2

 

 

Sorry, just thought to check back here now. :(

 

From the email report, the error was:

 

System.MissingMethodException: Method not found: 'Int32 PaintDotNet.Utility.ReadUInt16(System.IO.Stream)'.

   at PcxFileTypePlugin.PcxFileType.PcxHeader.ReadUInt16(Stream input)

   at PcxFileTypePlugin.PcxFileType.PcxHeader..ctor(Stream input)

   at PcxFileTypePlugin.PcxFileType.OnLoad(Stream input)

   at PaintDotNet.FileType.Load(Stream input) in d:\src\pdn\paintdotnet\src\Data\FileType.cs:line 459

   at PaintDotNet.Functional.Func.Eval[T1,TRet](Func`2 f, T1 arg1) in d:\src\pdn\paintdotnet\src\Base\Functional\Func.cs:line 156

 

Per the above it was the use of Utility.ReadUint16(). If no-one else complained it's probably not worth changing.

 

I've plopped the source up at: 

 

https://github.com/inexorabletash/PcxFileType/

Share this post


Link to post
Share on other sites
Rick Brewster    825

Yeah you're not supposed to use code in Utility. That's why it was removed.

 

I recommend using something like Reflector or ILSpy to look at the old version of that method (from the 3.5 DLLs), and then copy it into your own code so that you can keep using it.

Share this post


Link to post
Share on other sites
Rick Brewster    825

Also, is that the only method that's not working? I can easily make it available in the next update so that existing installations of the plugin will go back to working. You won't be able to use it for any subsequent updates of yours, however.

 

In order to do this I'll need all the methods that give errors like this. You can get me this list by recompiling your plugin, as long as you've set the references to the new Paint.NET DLLs.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this