PCX graphic format conversion and display

[Mark Yedinak]

Does anyone know if there is any LabVIEW code for converting a graphic image stored as a PCX image to a raw bitmap? In our printer testing we have the capability of receiving the label image which will be printed. Some of our printers return raw bitmpas and others use the PCX format. Since many of our existing tests were developed for the printers which use the bitmap fomrat I would like to convert the PCX images to a raw bitmap. Does anyone have code for doing this?

[bmoyer]

I haven't used it, but the Image Toolbox http://www.geocities.com/gzou999/imgtool.htm has a PCX read file VI.

Wikipedia also gives a very good description of the file format: http://en.wikipedia.org/wiki/PCX

Bruce

[crelf]

QUOTE (bmoyer @ Mar 11 2009, 03:34 PM)

Wikipedia also gives a very good description of the file format: http://en.wikipedia.org/wiki/PCX

If you want to go down that route (it should be pretty straightforward to implement), this might help:

[Mark Yedinak]

Well, so far it looks like neither of these solutions will work. The Image Toolbox only supports 8-bit per pixel PCX images and mine are 1-bit per pixel image. The Image Toolbox doesn't include any block diagrams so I wouldn't be able to modify them for the different color depth.

The IMAQ solution doesn't know how to handle the run length encoding used by the PCX format. I have been trying to roll my own but so far the images aren't displaying correctly. It appears that I am doing decode of the RLE data correctly but the image definitely is not being displayed correctly. If anyone has any other suggestions I would appreciate hearing them.

[crelf]

QUOTE (Mark Yedinak @ Mar 11 2009, 08:56 PM)

I have been trying to roll my own but so far the images aren't displaying correctly. It appears that I am doing decode of the RLE data correctly but the image definitely is not being displayed correctly.

Can you upload what you've tried (including an example PCX file)?

[vugie]

QUOTE (Mark Yedinak @ Mar 11 2009, 09:58 PM)

Does anyone know if there is any LabVIEW code for converting a graphic image stored as a PCX image to a raw bitmap? In our printer testing we have the capability of receiving the label image which will be printed. Some of our printers return raw bitmpas and others use the PCX format. Since many of our existing tests were developed for the printers which use the bitmap fomrat I would like to convert the PCX images to a raw bitmap. Does anyone have code for doing this?

Try calling ImageMagic. In Code Repository you'll also find http://forums.lavag.org/LVOOP-ImageMagick-Interface-file90.html' target="_blank">nice wrappers for its command line syntax.

[Mark Yedinak]

QUOTE (crelf @ Mar 12 2009, 12:18 AM)

Can you upload what you've tried (including an example PCX file)?

Yes, I was remiss in doing that last night. It was getting late, I was tired and hungry and wanted to leave work after a 13 hour day. Anyway, here is the code and a few PCX images that I have been testing

[Mark Yedinak]

OK, so I have the convert working now however I am not satisfied with the performance. I have been playing with different variations and am not sure what else I can do to improve the performance. We have a test that has hundreds, possibly greater than a thousand of these images used during the test. At present, both versions of code that I have included here take approximately 15 seconds per image for the decode. Obviously when multiplied by several hundred this really adds up. If anyone can think of any ways to improve the performance I would love to hear your suggestions.

[bmoyer]

It took 0.046 seconds to read for me! Seems pretty fast actually.

Bruce

[TobyD]

QUOTE (Mark Yedinak @ Mar 13 2009, 10:28 AM)

At present, both versions of code that I have included here take approximately 15 seconds per image for the decode.

I am also seeing load times of well below 1 second. Scan Lines with queues is taking nearly 0.5 seconds, but scan lines is in the hundredths of seconds. Are your real images much larger than the sample images you posted?

[Mark Yedinak]

Alright now I am concerned as well as a little relieved. I am relieved that you are seeing decent performance. I have been racking my brains over this for the last couple of hours trying to see what could possibly be taking so long. At least you validated that I am not completely insane thinking this code should have been running better than what I was seeing.

Now comes the fun part. After hearing your times I rebooted my computer and tried running it again. For a few runs I was seeing it take 3 seconds to complete. Then it jumped back to 15.2602 seconds. I then tried running it on a completely different machine and it was taking about 11 seconds on that machine. Both of these machines are decent machines (Intel Xeon CPU, 5110@1.6 GHz dual core and a Intel T2400@1.83 GHz dual core laptop) and both had crappy performance. Would anyone have any ideas what could be causing the severe performance problems? Our firmware developers ran into an issue recently and it turned out that our IT department had something running which caused their compiles to stall and take a very long time. I will check further into this. Are there other things that I should be looking for? This will be a major problem if I can't resolve what is causing the performance problems.

BTW, the image files that I posted are the ones I have been using for testing. So, we are comparing the same conversions.

[TobyD]

QUOTE (Mark Yedinak @ Mar 13 2009, 11:39 AM)

Are there other things that I should be looking for?

How much free memory do you have? I ran both versions using the "Run Continuously" button and did not notice any performance lags or memory leaks, but I'm thinking that if you are running into low memory problems and having to use swap space that could slow you way down.

I'm on a T7200 @ 2.0GHz with 2GB RAM for what it's worth.

[Mark Yedinak]

QUOTE (TobyD @ Mar 13 2009, 02:05 PM)

How much free memory do you have? I ran both versions using the "Run Continuously" button and did not notice any performance lags or memory leaks, but I'm thinking that if you are running into low memory problems and having to use swap space that could slow you way down.

I'm on a T7200 @ 2.0GHz with 2GB RAM for what it's worth.

One machine has 2 GB of RAM with at least 1 GB free. The other has 3 GB of RAM with at least 2 GB free. I don't think memory is an issue. Our FW development team told me that our IT department has recently installed some spyware to monitor our computers that effectively broke their compiles. I am removing this to see if this is causing my problems as well.

[Mark Yedinak]

Here is an update regarding the performance issues. It appears that I ran into a bug with the In-place structure that was in version 8.5 of LabVIEW. After experimentation and working with NI I found that I could save the VI as an 8.2 version and run it there without any problems. I could also create and save it in 8.5.1 without any problems. However, if I saved the code in 8.5 I would have the performance issue. However, if I opened the version I saved in 8.5.1 in 8.5 it ran fine. This was definitely a strange issue. Needless to say the difference in performance is significant from when it works correctly (0.04 seconds to convert) to when it is not wokring correctly (15.3 seconds to convert).

I see an upgrade in the near future.

[Yair]

QUOTE (Mark Yedinak @ Mar 17 2009, 09:04 PM)

However, if I opened the version I saved in 8.5.1 in 8.5 it ran fine. This was definitely a strange issue.

8.5 and 8.5.1 were binary-compatible. This meant that you didn't have to recompile your VIs when upgrading (e.g. to mass-compile vi.lib), but it also meant that if you have code which has an 8.5 bug which was fixed in 8.5.1, you would have to recompile the VI explicitly for the correct machine code to be generated.

[Mark Yedinak]

QUOTE (Yair @ Mar 17 2009, 02:16 PM)

8.5 and 8.5.1 were binary-compatible. This meant that you didn't have to recompile your VIs when upgrading (e.g. to mass-compile vi.lib), but it also meant that if you have code which has an 8.5 bug which was fixed in 8.5.1, you would have to recompile the VI explicitly for the correct machine code to be generated.

I definitely understand that. What I meant about the strange issue was tracking down exactly where this issue was introduced. It took a while to nail it down to something specifically in 8.5 itself.

[Rolf Kalbermatter]

This is a version I did about 15 years ago in what was then LabVIEW 3.1. I programmed it to work with 8bit color images but it seems to work well for the 1 bit images you provided too.

It is by far not what I would recommend to program nowadays although I think there are some interesting ideas in there. If you look at the Decode Bitmap function you may wonder why it is programmed like it is. The reason is manyfold. First there was no inplace operations back then. Second this had to run on 486DX 33 MHz CPUs back then without requiring minutes of runtime execution. I think you could squezze out a few more optimizations but in general it was what was necessary to make a RLE Decoder performant in LabVIEW back then.

As said it is not really how I would program it today both in terms of using LabVIEW features as well as overal architecture but here it is. I only upgraded it to 6.0.2 from 3.1 so it can be also read with the newest LabVIEW version. Nothing else was really changed.

Download File:post-349-1237721972.llb

Rolf Kalbermatter