Printable View
Dear colleagues,
does anyone have a pre-written piece of code for dumping an image loaded in a picturebox to a PCX file ? I've a project to present on monday and i just realised that VB6 does not have the PCX format embedded (vb3, from what i remember, used to work with PCX). I've looked up the PCX type on wotsit.com
but it's a little bit too late for me to start writing the PCX saving procedure now... tomorrow's Christmas and there's simply not enough time :(
Cheers !
Is pcx still being used? Wasn't it one of the earliest dos imaging formats?
What's wrong with bmp others than the file size?
edit: you may save it to jpeg - I think we have few samples posted out there.
Looks like the FreeImage library can do it.
Google vb6 freeimage wrapper
Well.... i wrote a program to upload images to an Intermec PD42 barcode printer...
the PD42 has a custom, internal 2-colour bitmap format.
This format is neither documented nor public, but it does accept ZSoft's PCX format as input. Only 2 colour files are supported :(
There's also something mentioned about the Intel HEX Format but, from my knowledge, that's more related to microcontrollers.... than to images.
yes, i've done quite a lot of research before posting this...Quote:
Originally Posted by VBClassicRocks
unfortunately, the freeimage.dll only supports :
PCX files [reading]
i need to write pcx images :sick:
There are few components out there to convert from bmp, jpg and other formts to pcx.
Here is one of them. I would try it and if it's something that you would need for awhile then what the heck - get it.
basically, it does what i need....
but i need to make MY APP convert the images into pcx.... the app is intended for... (pardon my expression) morons, so even if i buy the converter - which is inexpensive - i cannot explain to my customers
that they have to pre-convert the image to a certain format before uplading it to the printer.
I can already visualise the text : "What format ? Conversion !? Why doesn't you app do this.... what you call it... conversion thingy ?!"
:)
You need to stop being arrogant (sorry but that's how you "sound") - I'm sure there is an ocx/dll available (perhaps this one)...
Please excuse me, i didn't mean to upset either you, either anyone else.
i just meant to put a smile on your face and describe the situation i'm in,
i'm dealing with software developing for people who actually do not even know how to turn on/off the computer but only have "high demands"... i suppose you're familiar with the suppositions "If Microsoft did it, why can't you ?".
Again, please accept my apologies, i really did not mean to upset you. Communication is hard when it's entirely written, if we were face to face it i'm sure you would have perceived the previous text the way i meant it to sound.
PS: Batch Converter seems useful enough, i'll try and integrate it, so it's run in the background.
AndreiMhz,Quote:
I've a project to present on monday and i just realised that VB6 does not have the PCX format embedded ....... but it's a little bit too late for me to start writing the PCX saving procedure now... tomorrow's Christmas and there's simply not enough time
Life is sometime like that. I've now assembled a quickie for you. The code below should enable you to save an image to a 24-BPP PCX file, without compression (I believe you can add it later on if needed). Would you like to see if this is okay?
Edited: For compression subroutine, see Posting #1 inCode:Private Type RGBTriple
Red As Byte
Green As Byte
Blue As Byte
End Type
Private Type PCXHeader ' 128 bytes
Manufacturer As Byte
Version As Byte
Encoding As Byte ' 1 = RLE
BitsPP As Byte ' 1, 2, 4, 8
xMin As Integer
yMin As Integer
w As Integer
h As Integer
hDPI As Integer
vDPI As Integer
Palette(0 To 15) As RGBTriple
Reserved As Byte
Planes As Byte
BytesPerLine As Integer
PaletteType As Integer
HScreenSize As Integer
VScreenSize As Integer
Reserved2(0 To 53) As Byte
End Type
Private Type RGBQUAD
B As Byte
G As Byte
R As Byte
a As Byte
End Type
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDst As Any, pSrc As Any, _
ByVal ByteLen As Long)
Private Declare Function BitBlt Lib "gdi32" (ByVal hDestDC As Long, ByVal x As Long, _
ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hSrcDC As Long, _
ByVal xSrc As Long, ByVal ySrc As Long, ByVal dwRop As Long) As Long
Private Declare Function CreateCompatibleDC Lib "gdi32" (ByVal hDC As Long) As Long
Private Declare Function SelectObject Lib "gdi32" (ByVal hDC As Long, ByVal hObject As Long) As Long
Private Declare Function DeleteDC Lib "gdi32" (ByVal hDC As Long) As Long
Private Declare Function DeleteObject Lib "gdi32" (ByVal hObject As Long) As Long
Private Declare Function GetDIBits Lib "gdi32" (ByVal aHDC As Long, ByVal hBitmap As Long, _
ByVal nStartScan As Long, ByVal nNumScans As Long, lpBits As Any, lpbi As Any, _
ByVal wUsage As Long) As Long
Private Declare Function CreateDIBSection Lib "gdi32" (ByVal hDC As Long, pBitmapInfo As BITMAPINFO, _
ByVal un As Long, ByVal lplpVoid As Long, ByVal handle As Long, ByVal dw As Long) As Long
Private Const DIB_RGB_COLORS = 0
Private Const BI_RGB = 0
Private Type BITMAPINFOHEADER
biSize As Long
biWidth As Long
biHeight As Long
biPlanes As Integer
biBitCount As Integer
biCompression As Long
biSizeImage As Long
biXPelsPerMeter As Long
biYPelsPerMeter As Long
biClrUsed As Long
biClrImportant As Long
End Type
Private Type BITMAPINFO
bmiHeader As BITMAPINFOHEADER
bmiColors As RGBQUAD
End Type
Private Type BGRcolorspace
b As Byte
g As Byte
r As Byte
End Type
Public Function SavePCX(inFileSpec As String, inHDC As Long, inW As Long, inH As Long) As Boolean
Dim tmpPCX As PCXHeader
Dim mHandle As Integer
Dim arrByte() As Byte
Dim BI As BITMAPINFO
Dim tmpBitmap As Long
Dim tmpDC As Long
Dim arrPCXbyte() As Byte
Dim DIBw As Long
Dim PCXw As Long
Dim tmpByte() As Byte
Dim i As Long
If inW * 3 Mod 4 = 0 Then
DIBw = inW * 3
Else
DIBw = (inW * 3 \ 4 + 1) * 4
End If
If inW Mod 2 = 0 Then
PCXw = inW
Else
PCXw = inW + 1
End If
ReDim arrPCXbyte((DIBw) * inH - 1)
With BI.bmiHeader
.biSize = Len(BI.bmiHeader)
.biWidth = inW
.biHeight = inH
.biBitCount = 24
.biCompression = BI_RGB
.biPlanes = 1
End With
tmpDC = CreateCompatibleDC(inHDC)
tmpBitmap = CreateDIBSection(tmpDC, BI, DIB_RGB_COLORS, ByVal 0&, ByVal 0&, ByVal 0&)
SelectObject tmpDC, tmpBitmap
BitBlt tmpDC, 0, 0, BI.bmiHeader.biWidth, BI.bmiHeader.biHeight, inHDC, 0, 0, vbSrcCopy
'Adj for bottom up
BI.bmiHeader.biHeight = (0 - inH)
GetDIBits tmpDC, tmpBitmap, 0, inH, arrPCXbyte(0), BI, DIB_RGB_COLORS
ReDim tmpByte(PCXw * inH * 3 - 1)
'Put to PCX sequence
If inW * 3 <> DIBw Then
For i = 0 To inH - 1
CopyMemory tmpByte(i * PCXw * 3), arrPCXbyte(i * DIBw), PCXw * 3
Next i
Else
CopyMemory tmpByte(0), arrPCXbyte(0), UBound(arrPCXbyte) + 1
End If
DeleteDC tmpDC
DeleteObject tmpBitmap
With tmpPCX
.Manufacturer = 10
.Version = 5
.Encoding = 0
.BytesPP = 8
.Planes = 3
.xMin = 1
.yMin = 1
.w = inW
.h = inH
.hDPI = 96
.vDPI = 96
.Reserved = 0
.PaletteType = 0
.BytesPerLine = PCXw
End With
FormPCX24BPPbytes tmpByte, arrByte, PCXw, inH
'If compression is wanted, unblock
'CompressPCX arrByte, inScanW
mHandle = FreeFile
Open inFileSpec For Binary Access Read Write As mHandle
Put #mHandle, , tmpPCX
Put #mHandle, , arrByte
Close #mHandle
Erase arrPCXbyte
Erase tmpByte
SavePCX = True
End Function
Private Sub FormPCX24BPPbytes(inArrSrc() As Byte, inArrDest() As Byte, inScanW As Long, inH As Long)
Dim x As Long, y As Long
Dim nStartPos As Long
Dim h As Long
Dim arrBGR() As BGRcolorspace
ReDim arrBGR(inScanW * inH)
CopyMemory arrBGR(0), inArrSrc(0), (inScanW * inH * 3)
ReDim inArrDest(inScanW * inH * 3 - 1)
For y = 0 To inH - 1
For x = 0 To inScanW - 1
h = inH - y - 1
nStartPos = h * inScanW * 3 + x
With arrBGR((x + (inH - 1 - y) * inScanW))
inArrDest(nStartPos) = .r
inArrDest(nStartPos + inScanW) = .G
inArrDest(nStartPos + inScanW * 2) = .B
End With
Next x
Next y
End Sub
http://www.vbforums.com/showthread.php?t=636793
Roger Wilco :)
I shall test it this night, to see what it produces...
It's missing some DEF Types (Bitmap Info), but i have some already declared and i'll search through my older apps to see how i can mix some stuff to get your functions going.
Thanks a million, this is a real Christmas gift !
AndreiMhz,
They are there now, "some DEF Types (Bitmap Info)" and some others. I took it for granted that you already had those.
The code is supposedly to be a ready-to-run one. If there is still something missing, just drop a line here.
I've tested saving a JPG image to a PCX file alright -- ZIP of test project attached.
Petersen
Edited: Moved to new thread on 12/30/10
Dude.... i'm speechless.
Works flawlessly, gets the job done.
Asking here and there, i was also pointed another solution, for a free SDK and graphics library...
http://www.xnview.com/en/gfl.html
I also tested the DLL ActiveX they distribute and the results are the same.
Initially i thought of uploading some ZIP files of the SDK, but then again, this is copyrighted code and i'll better put a download link (i don't want to get into trouble)
http://www.xnview.com/en/download_gfl.html
Cheers and... MERRY CHRISTMAS !!!
Problem solved, Thread closed !
It doesn't save it as a PCX for me its just a load of multi colours lines.Quote:
Originally Posted by petersen
http://www.vbforums.com/images/ieimages/2005/12/1.gif
PCX is an old file format; I am not sure all viewers can handle it equally well. But for your information:
(1) My quickie was made to help AndreiMhz who had an urgent need and it proved to have accomplished what it is intended for, as AndreiMhz confirms that:
(2) A quick test shows that IrfanView loads the saved PCX okay.Quote:
Dude.... i'm speechless.
Works flawlessly, gets the job done.
......
Problem solved, Thread closed !
(3) Another test shows FreeImage loads it perfectly okay too.
(4) My own programs all load it okay too of course.
Indeed, in ACDSee 5 (which i use) it loads as a bunch of colours...
BUT, that's the viewer's fault, not Petersen's code.
I tried converting JPG's to PCX's with other converter's too and the result was the same : multi coloured lines in ACDSee.
Try downloading PCX Viewer (google these two words) and it will open the PCX correctly.
Both Petersen's code and other plugins i mentioned do the job right !
Yes sorry I was having a problem showing it. I generally use Microsoft Photo Editor but that just showed all multi coloured lines. I'm not downloading an app just to show a PCX. Oh VB3 won't load a PCX either so I'm not sure where he had that from?
I'm wondering why he wants it to be a PCX as VB won't show them either.
Merry Christmas. http://www.vbforums.com/images/ieimages/2005/12/1.gif
the answer's in earlier posts...Quote:
Originally Posted by Keithuk
changing from 24 bit to monochrome works fine by converting the input bitmap to monochrome and then converting to pcx format... the printer accepts it happily :)Quote:
Well.... i wrote a program to upload images to an Intermec PD42 barcode printer... the PD42 has a custom, internal 2-colour bitmap format.
This format is neither documented nor public, but it does accept ZSoft's PCX format as input. Only 2 colour files are supported
Even PhotoShop 7 might fail to load a PCX which is not compressed with RLE. However, it would be okay for a compressed one. Attached is a comprssed PCX of the same image in my earlier zip (due to weakness of RLE algorithm, the file size is only marginally smaller), in case you want to try it on your viewer software to satisify curiosity.
Merry Christmas!
FYI. I've been doing some research on PCX file formats. The most likely reason that viewers that can normally handle pcx files not displaying the ones created with Encoding=0 are not processed properly. And from reading the official documentation of the ZSoft pcx specifications, zero is not a valid entry. However, maybe zero has been accepted by some viewers to mean non-encoded. I'm only reporting what I've read.
Additionally, when using more than 1 color plane, it is not clearly described (at least I couldn't clearly decipher it) whether the RGB values should be written in which of the following formats. The project in post #12 above uses the 2nd format.
Imagine a 2 pixel image using one color: RGB(10,20,30)
1) 10,10,20,20,30,30 :: all reds, then all greens, then all blues
2) 10,20,30,10,20,30 :: rgb for each pixel
Still looking, but leaning towards the 1st format above as the 'proper' way?
And a slightly different interpretation on Wikipedia but sounds like format #1 aboveQuote:
Originally Posted by ZSoft
I've become interested in this simply because per specifications, it is possible to store 32 bit alphablended images in pcx format. Still researching...Quote:
PCX image data is stored in rows or scan lines in top-down order. Where the image has multiple planes these are stored by plane within rows. Such that all the red data for row 0 is followed by all the green data for row 0, then all the blue data
A follow-up for those that care.
I took Petersen's compressed.pcx file and also created a dozen others via PhotoEditor. All results were the same... In order to read the pcx file correctly, it must be encoded as those images are/were. The decoding/encoding itself has some gotchas that took me a bit to figure out. But that is another story. The point is that the encoding does have all Red values for the entire line written, then all Green for that line, then all Blue. This applies when more than 1 color plane is used, as is the case with 24bit pcx images. This is not what we are used to when we think of pixel color data.
So if it is required to read the pcx file that way, then it makes perfect sense that whether it is encoded or not, it must be written that way also. And because of this, I think is one of the reasons typical pcx viewers were misreading the pcx created from project in post #12.
And is zero a valid value for the Encoding flag within a pcx? Again, no documentation, that I can find so far, says it is valid. PhotoEditor has an option to save pcx uncompressed. So what is the result when doing that? Compressed. Checked it byte by byte.
Last note. So what would happen if I left the compressed pcx file as is but just changed the Encoding flag from 1 to 0? Would PhotoEditor read it ok, corrupt the image, or abort & fail to open it? The answer: Reads it just fine. This is a strong indication if other viewers do the same thing, that Encoding flag is ignored because encoding is always assumed because maybe there is no valid non-encoding value.
Whether a correct statement or not
But it appears MAC does support and create uncompressed pcx... But I doubt it would be written in a different RGB format than compressed pcx filesQuote:
Originally Posted by wikipedia
http://developer.apple.com/library/m...img-pcx.n.html
Those were my tests & will continue testing now that I have written a good pcx reader/writer; just need to apply paletted images & good to go.
Yes it is not tidy at all. I can recall clearly that even for the compressed ones, there are some difference in 8-BPP image handling between IrfanView on one hand and PhotoShop/FreeImage on the other (I didn't pursue further on that).
Well, I did find a relatively trustworthy app that creates pcx in both compressed/uncompressed and with other attributes: Image Majick. When created uncompressed, their pcx files are coded as I would have expected: same color format writing, just no RLE.
Have you tested the resultant 24-BPP and 8-BPP images on say IrfanView and FreeImage? (The point is if it fails on any of them, such failure indiciates it may not be a good one)
For your reference I've now attached two 8-BPP files, both compressed.
(1) aaa_8bpp.pcx (in aaa_8bpp.zip). There is some difference in image display between IrfanView on one hand and FreeImage/PhotoShop on the other (IrfanView appears to be much more capable with regard to PCX. Interestingly it can display the image alright, no matter how it is coded).
(2) bbb_8bpp.pcx (in bbb_8bpp.zip). There is no difference in image display among IrfanView, FreeImage and PhotoShop.
I don't use either of those apps/libraries. I'll be glad to look at them and give you my opinion from what I've been researching
I didn't know you use PhotoEditor LaVolpe?Quote:
Originally Posted by LaVolpe
Even if you save them under different compressions it brings me back to the original point. Why do they need to be a PCX images as VB can't load them anyway, whats point and whats the advantage? ;)
You don't necessary need to display image in your vb app - there are many different reasons to use old formats for some extarnal apps and/or piece of hardware.
One of them as OP mentioned is:
Quote:
i wrote a program to upload images to an Intermec PD42 barcode printer...
-- Seeing that he/she wants to save it as a PCX. I must ask this question: Are you working from a DOS/Windows app???
Did my previous post escaped you? :confused: Also read the reply that actually resolved this thread - code appears to be VB6 too. ;)
-- Well I used to work with Cash Registers and Docket Printers, when I was working for my company. But can only remember the Database work...
(Had a accidental electricution and cannot remember alot of that stuff.)
I hope you are not serious. :) Regardless, what's that got to do with this at all? You're raising questions that were answered already - just read the entire thread.Quote:
Originally Posted by ThEiMp
Regards.
ThEiMp appears to use "Cash Registers" to symbolize the "old" and "Database" the "new". Just for his information:
(1) If he likes to discuss something "new", by all means (I also deal with formats as new as JPEG2000, HDR and EXR, the High Dynamic Range images). I also have a thorough knowledge, e.g. on how to save to 1, 2, 4, 8, 16, 24, 32, 48 and 64-BPP PNG, interlaced or not.
(2) If he only recognizes "Database", I believe I am fully qualified to discuss it with him too (but not the kind of DAO/ADO thing, please). [Although he doesn't see any fancy "signature" after my name in vbForum, for the better part of my life, I belonged to various statutorily recognized professional bodies in different countries, e.g. Fellow of Chartered ...(UK), Certified ..... (Canada)......etc, as such, I do own some prestigious designatory letters after my name.]
-- Well when I mean Database. It was just a DOS dBase File (*.db). Which thank God, I forgot how to use it...
By DOS dBase, I guess you mean the then Ashton Tete's dBASE III and later Borland's dBase IV, excellent products and I knew them very well. By the time Borland tried Windows version, (jumping to) dBase 7 more than 10 years ago, it was too late.
But what is the relevance to the current thread! I have to stop here.
-- I think that I was rambling on, like I normally do in my Internal Emails...
ThEiMp,
Sometimes people do that; never mind.
I wish you a Happy New Year!
Petersen
-- Same to you, and all the members of VBForums!!
In Posting #24, I've attached a second 8-BPP PCX for which there is no difference in image display among IrfanView, FreeImage and PhotoShop
Petersen, with exception of 4 bit (4 color planes, 1 bit per pixel) format, paletted images should display same. This is because the palette indexes are written sequentially. 8bpp images store the palette at the end of file. In some cases, coders store first 16 colors in the color map header portion & remaining at end of file to save 48bytes of file size; but it's against pcx specifications.Quote:
Originally Posted by petersen
I made the file, so that I know the byte positions of course. What is interesting is aaa_8bpp.pcx, not bbb_8bpp.pcx -- the one that IrfanView can display perfectly alright, while FreeImage/PhotoShop cannot.
Regarding post #24 and the pcx that is displayed slightly different. Here is the reason I believe. That pcx is not breaking on each scanline. The RLE is continuing across scanlines and is not the norm. Per ZSoft specs, "There will always be a decoding break at the end of each scan line." I've seen this issue addressed on the net & have modified my parser to account for these; which is how I detected the variance.
Edited: sample screenshot
Attachment 81751
If you'd like to discuss pcx formatting/ideas, maybe open a thread in the graphics section? I think we have hijacked the OP's thread for too long. Aggreed?
Good idea; it has deviated too far indeed, unexpectedly. I would try to open a new thread later today. I will take a look at aaa_8bpp first, interesting as it is. From the outset, I agree with you as I can see the logic/necessity of scanline break.
Edited: It seems the problem is something else (I've revisited the original code and found there are already scanline breaks). I've now opened a new thread accordingly.
Just to inform:
Compression subroutine is available now, see Posting #1 in
http://www.vbforums.com/showthread.php?t=636793
The subroutine has been well tested, with actual data saved as 8-BPP and/or 24-BPP of different sizes (from small to big), and the saved 8-BPP and 24-BPP files loaded and displayed on AZ Paint Pro, IrfanView, FreeImage and PhotoShop all alright.
Just Saying: I have written a Data Stripper routine, that has one way to SaveAs and another to Open file data into a TextBox. I am still working on getting them to appear inside a PictureBox, instead of the TextBox.