From: Arnd B. <arn...@we...> - 2004-06-16 16:52:25
|
Hi, I am in the process of becoming a big fan of PyX, in particular since the nice bitmap module was added. But now I am struggling with the following: When generating a file using `bitmap`, everything looks nice with `gv`. But when printing, my printer (HP Laserjet 2200, built in level 2 postscript interpreter) does not print (Just one blink of the LED that something arrived...). A short example is ############################################################################## from pyx import * from pyx import bitmap from pyx.graph.axis import linear c = canvas.canvas() g = graph.graphxy(width=5,height=5,x=linear(min=0.0, max=1.0), y=linear(min=0.0, max=1.0)) image_bw = bitmap.image(2, 2, "L", "\0\377\377\0") bitmap_bw = bitmap.bitmap(0, 1, image_bw, height=0.8) c.insert(g) #c.insert(bitmap_bw) # uncommenting this line no output is c.writeEPSfile("fig.eps") # obtained when printing ############################################################################## I am not sure if this is caused by the printer not being a level 3 one, or something else. The difference in fig.eps between the versions with and without `c.insert(bitmap_bw)` are #---------------------------------------------- gsave /DeviceGray setcolorspace << /ImageType 1 /Width 2 /Height 2 /BitsPerComponent 8 /ImageMatrix [0.088194 0.000000 -0.000000 -0.088194 0.000000 4.500000] /Decode [0 1] /DataSource currentfile /ASCII85Decode filter /FlateDecode filter >> %%BeginData: 2 ASCII Lines image Gar:=s.9;l"TJN&~> %%EndData grestore #---------------------------------------------- Is there a work-around or fix, or is the postscript interpreter of my printer broken so that I better buy a postscript level 3 printer ;-)? Many thanks in advance (and many thanks for PyX), Arnd |
From: Markus M. <me...@me...> - 2004-06-17 07:09:08
|
Arnd, the FlateDecode compression method is only supported in Postscript Level 3. Postscript Level 2 does support LZW, but since it is still patented in some countries and not very effective, LZW is not implemented in PyX. You can use DCT compression instead, or disable the compression. DCT compression is the same compression as used by the jpeg image format, and thus is lossy. I'd suggest you experiment with the compression parameters and see if the quality provided by DCT is ok for you. Example: bitmap_bw = bitmap.bitmap(0, 1, image_bw, height=0.8, compressmode="DCT", dctquality=75) Hope that helps Markus Am Mit, den 16.06.2004 schrieb Arnd Baecker um 18:52: > Hi, > > I am in the process of becoming a big fan of PyX, in particular > since the nice bitmap module was added. > But now I am struggling with the following: > > When generating a file using `bitmap`, > everything looks nice with `gv`. > But when printing, my printer (HP Laserjet 2200, > built in level 2 postscript interpreter) does not print > (Just one blink of the LED that something arrived...). > > A short example is > ############################################################################## > from pyx import * > from pyx import bitmap > from pyx.graph.axis import linear > > c = canvas.canvas() > g = graph.graphxy(width=5,height=5,x=linear(min=0.0, max=1.0), > y=linear(min=0.0, max=1.0)) > image_bw = bitmap.image(2, 2, "L", "\0\377\377\0") > bitmap_bw = bitmap.bitmap(0, 1, image_bw, height=0.8) > c.insert(g) > #c.insert(bitmap_bw) # uncommenting this line no output is > c.writeEPSfile("fig.eps") # obtained when printing > ############################################################################## > > I am not sure if this is caused by the printer > not being a level 3 one, or something else. > > The difference in fig.eps between the versions with and without > `c.insert(bitmap_bw)` are > > #---------------------------------------------- > gsave > /DeviceGray setcolorspace > << > /ImageType 1 > /Width 2 > /Height 2 > /BitsPerComponent 8 > /ImageMatrix [0.088194 0.000000 -0.000000 -0.088194 0.000000 4.500000] > /Decode [0 1] > /DataSource currentfile /ASCII85Decode filter /FlateDecode filter > >> > %%BeginData: 2 ASCII Lines > image > Gar:=s.9;l"TJN&~> > %%EndData > grestore > #---------------------------------------------- > > Is there a work-around or fix, or is the postscript interpreter > of my printer broken so that I better buy a > postscript level 3 printer ;-)? > > Many thanks in advance (and many thanks for PyX), > > Arnd > > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > _______________________________________________ > Pyx-user mailing list > Pyx...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-user |
From: Arnd B. <arn...@we...> - 2004-06-17 08:02:46
|
Hi Markus, On Thu, 17 Jun 2004, Markus Meyer wrote: > the FlateDecode compression method is only supported in Postscript Level > 3. I think I could have figured that out myself (well, it was one of _those_ days yesterday ;-) > Postscript Level 2 does support LZW, but since it is still patented > in some countries and not very effective, LZW is not implemented in PyX. > You can use DCT compression instead, or disable the compression. DCT > compression is the same compression as used by the jpeg image format, > and thus is lossy. I'd suggest you experiment with the compression > parameters and see if the quality provided by DCT is ok for you. I just googled a bit for DCT and it seems that even with quality=100) it still provides a reasonable compression. If that is true (could not test it, see below), then an implementation of RLE or LZW (whenever we are allowed to ;-) is unnecessary. > Example: > > bitmap_bw = bitmap.bitmap(0, 1, image_bw, height=0.8, > compressmode="DCT", dctquality=75) For this I get the following Traceback (most recent call last): File "gen_fig_minimal.py", line 12, in ? compressmode="DCT", dctquality=75) File "/usr/lib/python2.3/site-packages/pyx/bitmap.py", line 240, in __init__ dctquality, dctoptimize, dctprogression) File "/usr/lib/python2.3/site-packages/pyx/bitmap.py", line 88, in tostring raise RuntimeError("encoding not supported in this implementation") RuntimeError: encoding not supported in this implementation Is this to be expected ? (note that I took pyx 0.6.3 and added bitmap.py from CVS) Using `compressmode=None` works fine, including printing at the price of a .eps which is about a factor 2 larger in size. > Hope that helps Indeed, it does !! Many thanks, Arnd |
From: Markus M. <me...@me...> - 2004-06-17 15:13:13
|
Arnd, Am Don, den 17.06.2004 schrieb Arnd Baecker um 10:02: > I just googled a bit for DCT and it seems that > even with quality=100) it still provides > a reasonable compression. Fact is that you will not get 100% accurate results with DCT compression, even with a very high quality setting. The results should be OK for all practical purposes, though (i.e. you will not be able to distinguish the results when plainly looking at them). It's like having a MP3 audio file encoded at 300 kbps, no one will really hear a difference, but technically, it's still a lossy compression. > > bitmap_bw = bitmap.bitmap(0, 1, image_bw, height=0.8, > > compressmode="DCT", dctquality=75) > > For this I get the following > > RuntimeError: encoding not supported in this implementation I cannot reproduce this, but I must admit that I have a slightly hacked version of bitmap.py in my own tree. The only thing I know is that Andre (who wrote this module) is supposedly on vacation so it won't hurt if you could debug this yourself; if it's a problem within PyX it's surely only a small bug. Markus |
From: Arnd B. <arn...@we...> - 2004-06-17 15:24:51
|
Hi Markus, On Thu, 17 Jun 2004, Markus Meyer wrote: > > > bitmap_bw = bitmap.bitmap(0, 1, image_bw, height=0.8, > > > compressmode="DCT", dctquality=75) > > > > For this I get the following > > > > RuntimeError: encoding not supported in this implementation > > I cannot reproduce this, but I must admit that I have a slightly hacked > version of bitmap.py in my own tree. The only thing I know is that Andre > (who wrote this module) is supposedly on vacation so it won't hurt if > you could debug this yourself; if it's a problem within PyX it's surely > only a small bug. Well, in `__init__` of `class bitmap` we have the segment # create data if compressmode == "Flate": self.data = zlib.compress(image.tostring(), flatecompresslevel) elif compressmode == "DCT": self.data = image.tostring("jpeg", image.mode, dctquality, dctoptimize, dctprogression) else: self.data = image.tostring() self.singlestring = self.storedata and len(self.data) < self.maxstrlen So only for the DCT case `image.tostring` is called with arguments. Looking at `class image` the def tostring(self, *args): if len(args): raise RuntimeError("encoding not supported in this implementation") return self.data So maybe it would help me if you send me your hacked bitmapy.py (off-list) and I will run a tkdiff to hunt this down this night and report tomorrow. Arnd |
From: Markus M. <me...@me...> - 2004-06-17 21:25:24
|
Hi Arnd, Am Don, den 17.06.2004 schrieb Arnd Baecker um 17:24: > So only for the DCT case `image.tostring` is > called with arguments. Okay, now I see the problem. The DCT compression is just not implemented in the "image" class. My "hacked" module doesn't help in this case, because it doesn't implement this method either. Provided your original image is already in JPEG format, you can work around this limitation by using the "jpegimage" class which automatically uses the DCT encoding without further conversions. Alternatively, you can use the Python Imaging Library (PIL), which has an "Image" class which is compatible to the interface needed by PyX. This class provides the necessary "tostring" method which can create DCT data. Markus |
From: <ba...@ph...> - 2004-06-21 07:30:36
|
Hi Markus, On Thu, 17 Jun 2004, Markus Meyer wrote: > Am Don, den 17.06.2004 schrieb Arnd Baecker um 17:24: > > So only for the DCT case `image.tostring` is > > called with arguments. > > Okay, now I see the problem. The DCT compression is just not implemented > in the "image" class. My "hacked" module doesn't help in this case, > because it doesn't implement this method either. Provided your original > image is already in JPEG format, you can work around this limitation by > using the "jpegimage" class which automatically uses the DCT encoding > without further conversions. Which it isn't in my case.... > Alternatively, you can use the Python Imaging Library (PIL), which has > an "Image" class which is compatible to the interface needed by PyX. > This class provides the necessary "tostring" method which can create DCT > data. Indeed - For the archive I attach a simple example below. (It seems that this was one of the cases where providing a simple example caused more problems than my original code: There I was using PIL from the beginning, i.e. the DCT compression would have worked "out of the box" ;-) Anyway, for the "real" plot I am just doing it turned out that dctquality=100 still leads to some noticable (and relevant) artefacts (I did not yet play around with dctoptimize and dctprogression). For some other plots DCT compression with dctquality=75 worked fine and I could not spot any differences. _Many_ thanks, Arnd ################################################################### from pyx import * from pyx import bitmap from pyx.graph.axis import linear import Image c = canvas.canvas() g = graph.graphxy(width=5,height=5,x=linear(min=0.0, max=1.0), y=linear(min=0.0, max=1.0)) Nx,Ny=50,2 im=Image.new("RGB",(Nx,Ny)) for nx in range(Nx): for ny in range(Ny): im.putpixel((nx,ny),(int(255*nx/Nx),int(255*nx/Nx),int(255*nx/Nx))) bitmap_rgb = bitmap.bitmap(0, 1, im, width=4.0,height=2.5, compressmode="DCT", dctquality=75) c.insert(g) c.insert(bitmap_rgb) c.writeEPSfile("fig.eps") ################################################################### |
From: Andre W. <wo...@us...> - 2004-06-24 17:09:50
|
Hi, On 21.06.04, ba...@ph... wrote: > > Alternatively, you can use the Python Imaging Library (PIL), which has > > an "Image" class which is compatible to the interface needed by PyX. > > This class provides the necessary "tostring" method which can create DCT > > data. > > (It seems that this was one of the cases where > providing a simple example caused more problems than > my original code: There I was using PIL from the beginning, > i.e. the DCT compression would have worked "out of the box" ;-) BTW this is exactly the intended behaviour. PyX does not provide a DCT compression but relies on the implementation of the tostring method of the image instance. If you use PIL with jpeg support compiled into you can use the DCT compression, but if you use the image method from the bitmap module it will not work (except for already jpeg compressed data using the jpegimage class -- then its not at all needed to decode and reencode the jpeg compressed data). > Anyway, for the "real" plot I am just doing it turned out > that dctquality=100 still leads to some noticable (and relevant) > artefacts (I did not yet play around with dctoptimize and dctprogression). > For some other plots DCT compression with dctquality=75 > worked fine and I could not spot any differences. As far as I can tell, dctoptimize and dctprogression will not at all alter the qualitiy of the compressed images. It will certainly not help to suppress various jpeg intrinsic missfeatures, especially those typical box like artefacts at line drawings. André PS: There is another (known) issue regarding this whole thread: We should denote needed features (like Flate/DCT compression, PostScript Language Level) within proper DSC comments. Jörg, this somehow also addresses the prolog vs. bbox discussion we had privately before. It turns out that all those informations could be collected within a single prolog roundtrip ... without a special handling of bbox anymore. I would suggest to make this *simplification* at some point. Any thoughts? -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Joerg L. <jo...@us...> - 2004-06-25 08:00:14
|
On 24.06.04, Andre Wobst wrote: > PS: There is another (known) issue regarding this whole thread: We > should denote needed features (like Flate/DCT compression, PostScript > Language Level) within proper DSC comments. Jörg, this somehow also > addresses the prolog vs. bbox discussion we had privately before. It > turns out that all those informations could be collected within a > single prolog roundtrip ... without a special handling of bbox > anymore. I would suggest to make this *simplification* at some point. > Any thoughts? If it doesn't degrade performance too much, I would support doing so. But for this, the merging algorithm for prolog items probably has to be improved... Jörg |