Re: [Gimp-developer] Print plugin
Sven Neumann wrote: Hi, On Sun, 2007-07-22 at 14:10 +0200, Stefan Roellin wrote: The current implementation/patch now has a disadvantage: if you print to a postscript target, the image has to be exported TWICE: once for the 'print preview widget' (with alpha) and once for the postscript target (without alpha). This is certainly not optimal regarding memory consumption. I have attached a patch to the bug report that outlines a way to work around this problem. If yes, a solution could be to not distinguish between a Postscript and a PDF target (i.e. to embed only opaque images into a PDF despite the fact that PDF can handle images with alpha values). Would this approach have any disadvantages? It pretty much doesn't matter what you can do with a PDF target, so long as there is still the ability to directly print as PostScript and save as EPS/PS. Should an image be intended for print, then there would be no harm in dumping alpha and using opaque. Someone may want to actually further edit an image, in which case a PDF losing alpha would be a disadvantage...but PDF is the wrong format for this anyway (most of the PDF editing tools out there are junk, set with features to sell a product that breaks if you mix it with the wrong situation). The up side to only embedding opaque is easier maintenance, common code set, etc. Quite likely it would result in better reuse of code. If you want a final answer, you're going to have to know who uses alpha in a PDF which is intended to be in its final form, and not as an intermediate product of editing. Newer PDF formats have a lot of features which barely anyone uses...when they are used, I see it for interactive purpose, not for print. D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Sven Neumann wrote: Hi, On Sun, 2007-07-22 at 14:43 -0600, D. Stimits wrote: For me, it is a serious problem. I work in the print industry, typically creating PostScript drivers. The PS output is quite good quality, and every conversion generally suffers serious quality issues. Gimp is one of the best tools available for UNIX side PostScript. Photoshop and some other tools, despite being Adobe products, tend to break standards compliant high end print systems (most of those products work great so long as you don't mix them with other people's products, then they suck...gimp PS works flawlessly with all of the certified systems). As soon as you start making PDF-to-PostScript conversions or PostScript-to-PDF-to-PostScript, the output is hopeless. Don't do it. We are talking about the new Print plug-in here, not about the plug-in that is used to save an image as a Postscript file. So your concerns are probably not valid. Yes and no. The PostScript which I have to slice-and-dice is from save as, but all of the printers involved are PostScript printers. Some can handle PDF, others cannot. If I were to print a high res image on a quality printer (definitely not some ink jet from the local store), it'd be rare that any conversion process would leave the quality in tact. The only time exporting a transparency is a problem is if you plan to print on some sort of custom paper that isn't plain white, but then there should be a background color anyway. With an exception that is irrelevant, there are no printers with transparent ink (that exception being in the dye sublimation, but the transparent ink is a coating for longevity, and has no knowledge of any alpha channel). Show me a printer takes advantage of mixing transparent inks, taking advantage of an alpha channel, and I'll agree that there is a reason to not export to a non-transparent color space. On the other hand, every single printer out there which handles PostScript natively (and there is no such thing as a good PCLprinter, even if it emulates PostScript) will suffer by removing direct PostScript output. I do indeed print directly from gimp without an intermediate step, as proofs and other samples going to a quality PostScript printer are best done from gimp...some of the other products are known to crash printers under some images, gimp never does this, it's the only really stable program for that purpose (all of these printers are Adobe certified, the low end systems start at about $10k, the I-Gen systems range from over $100k on up...which Adobe products tend to crash). Being able to take advantage of a PPD file during print from gimp is very useful, and I print directly from gimp daily. A PDF conversion would ruin this, so I'm in the opposite position by having a real PostScript system. So I pose this question...if print via PDF is to be considered, why remove the existing PS system, which is pretty much the best quality PostScript among all of the apps (commercial and free)? There isn't any reason to not add a PDF print preference, but PDF language is not intended as a print language, it is a document interchange format, and should not be converted to this format until interchange is needed. A preference could easily be set if both formats are available, but there is a genuine need for real PostScript output in the non-windows world. I don't want to hand craft save-as-eps files for specific hardware every time someone wants a sample print, just so I can keep the image quality. I really don't understand why anyone would want to remove PostScript print options instead of adding PDF to it, especially since much of the PostScript code directly translates to PDF code. D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Stefan Roellin wrote: Hi, I have submitted a patch which (slightly) improves the quality of the print plugin (see Bug #387604). The problem basically was that Postscript can't cope with transparency. In contrast, PDF is able to do so. The current implementation/patch now has a disadvantage: if you print to a postscript target, the image has to be exported TWICE: once for the 'print preview widget' (with alpha) and once for the postscript target (without alpha). This is certainly not optimal regarding memory consumption. So the question is, whether this is a real problem or not. For me, it is a serious problem. I work in the print industry, typically creating PostScript drivers. The PS output is quite good quality, and every conversion generally suffers serious quality issues. Gimp is one of the best tools available for UNIX side PostScript. Photoshop and some other tools, despite being Adobe products, tend to break standards compliant high end print systems (most of those products work great so long as you don't mix them with other people's products, then they suck...gimp PS works flawlessly with all of the certified systems). As soon as you start making PDF-to-PostScript conversions or PostScript-to-PDF-to-PostScript, the output is hopeless. Don't do it. If yes, a solution could be to not distinguish between a Postscript and a PDF target (i.e. to embed only opaque images into a PDF despite the fact that PDF can handle images with alpha values). In this case, we only have to export the image at most once. PDF is pretty much a subset of PostScript with a hierarchy, at least in the basic early versions. When you start getting into more recent versions, it diverges, but still contains mainly a subset of PostScript operators for the vector and bitmap part of it. If you wanted support for PDF, you'd be better off making both PS and PDF output options. It'd be nice to have direct PDF output, but this is a document interchange format, and NOT a print format. There is no reason to not add dual output format, but there is an extrordinary loss of quality by removing direct PostScript output (FYI, I must often slice and dice the raw PostScript, and gimp has the most sane version among the common tools). FYI, a proper conversion tool can convert from PS to PDF without loss, but virtually all tools have issues, mainly when converting vector to bitmap, or using lossy compression without an option to say no to it. If anyone really felt the need to improve print options, my own feeling from coding for the print industry is that more options on compression formats and font embedding (perhaps not relevant for gimp) would be appropriate. D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory manage in python-fu
... I think you have hit an actual bug, and that it doesn't have anything to do with python, because I have encountered a similar thing in a modified version of gimpressionist that I worked up, written purely in C. I believe that there is some sort of memory leak that causes gimp in some situations to maintain reference to tiles that are no longer being used in any way, and it is something that shows up when you create and delete layers over and over again, in a certain way. So it would probably be useful for you to file a bug report about this, if you would. It would only be useful if that bug report included a way to reproduce the problem. And it would probably be helpful to discuss that code example beforehand. I am not saying that there are no memory leaks in GIMP. But we are frequently testing the software for this and I am not aware of any major memory leaks such as the one that Bill describes here. The memory that is being exhausted, by the way, is the swap area that gimp allocates on the hard disk each time you run it. The tile manager moves tile data there if space is needed. Actually, it doesn't do that when space is needed, but when the memory allocated for tiles exceeds the limit configured as 'tile-cache-size'. There could be a mix of a gimp bug, and definitely some portion of my plug-in. Although I know for a fact that I had a memory leak that was my fault, the reaction to the leak was unexpected. The system in question has only a /boot and /, with well in excess of 30 GB unused (lots of inodes as well). For a moment I thought that perhaps it was a max open file descriptor limit...which it could still be, but the system itself has a default setting of a max of around 76,618. The thing I did not expect was that it had well over a gig of ram left unused, no swap used, 30 gig of unused drive, and it still thought the hard drive was full. On the other hand, it might not be worth pursuing when it requires a memory leak for it to show up. I do believe that after using the delete function in the loop, that it still used up memory which it did not release. The amount was barely noticable though, and after running all night to create 45,000 800x800 color jpegs, I'd say the amount was barely distinguishable as above the amount it started with (I didn't take exact measures, I was going by a mix of top and a graphical tool). Without a breakdown though of where gimp was using the memory, it'd be a bit of a stretch though to say it truly was a leak...it could simply be doing something like caching of something, e.g., it was using the text generation and changing fonts on each of the 45,000 images. I know gimp has some ability to put out debug code, but I'm curious if it has any sort of way of dumping statistics on how it's using memory? In the future I'll have to work on several plug-ins to do mass image handling, probably less than 45,000 per batch most of the time. I'll watch and see if I can find anything useful to report. Otherwise, just have a loop intentionally create 800x800 images without deleting, expect it to run out of resources, but see if it does it in the way expected...mine ran out of resources LONG before the system was even stressed slightly. Again, I suspect the slow laptop hard drive compared to fast core2 and tons of ram made it a race the hd could not win. D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] memory manage in python-fu
I've created a simple python-fu plugin to generate test images for use in another project (all on linux, gimp 2.2.13, fedora core 5). It works, but terminates before finished. What the plugin does is to create images of a given specification, in a loop. Each pass of the loop alters the image slightly. It creates the image, it creates a layer, it does some painting (basically bucket fills and text), then it saves the file. It does not do any interactive display of the image. After about 4000 images, it fails, claiming no space left on device. However, there's about another 30 GB left. Furthermore, I monitor ram use, and there is still about 1.25 GB of ram left (it has swap turned off, it's all physical ram). Monitoring ram, I do see ram use continually climb, and never drop (actual use, not cache). The amount roughly appears to corresponds to the image sizes. I need to generate approximately 45000 files per batch. I have not found any python-fu way to close a file, or to reclaim memory after creating an image or layer. Is there such a thing? Is there instead some sort of garbage collection? Speculating about why it claimed it was out of memory, I'm wondering if the hard drive simply was too slow responding. It's a laptop, running with core duo, entirely in ram. The drive is thus much slower than the ability to consume ram. How does gimp determine that there is no space left on the device...is it a timeout in addition to other means? D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] finding plug-in prototypes
Not all plugin-related functions and objects are described directly from within gimp's help, e.g., register, or the gimp object and gimp.Image. I'm using python-fu, and can find some of the simple answers in the actual gimpfu.py, but others are embedded elsewhere. I'm wondering if there is a reference web page somewhere which might list the functions used in plug-ins (especially python-related) which are not explicitly listed in the PDB or help menus of gimp? I'm especially interested in gimp.Image and gimp.Drawable. Thanks, D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
