Hi,

tino.schwarze@informatik.tu-chemnitz.de (Tino Schwarze) writes:

BTW: Is it possible that there is a 3 Gig limit on per-process memory? The machine has 6 GB, no ulimits and I got a "could not allocate x bytes" message when I gave 3 Gig tile cache to GIMP (it took about 500 Meg for other stuff, so I settled with 2.5 GB tile cache and still got a 3 Gig swap file plus 3 Gig memory usage).

On a 32bit platform a single process cannot allocate more than 4GB so I guess you've been hit by that limit somehow. You will need a 64bit architecture in order to address memory beyond 4GB. We haven't tested this but if you were using a 64bit platform GIMP-1.3 should allow you to extend the tile cache beyond 4GB even.

Sven

On 24-Sep-2003, Tino Schwarze wrote:

BTW: Is it possible that there is a 3 Gig limit on per-process memory? The machine has 6 GB, no ulimits and I got a "could not allocate x bytes" message when I gave 3 Gig tile cache to GIMP (it took about 500 Meg for other stuff, so I settled with 2.5 GB tile cache and still got a 3 Gig swap file plus 3 Gig memory usage).

Its up to how your os and processor arch works. Like, x86 has a limit of 4 gigs per process, and Linux is defaultly setup for something like 3 gigs for the process, 1 for the kernel. You could be hitting that.

So the huge image you generated is a fractal? Isn't it a bit silly to render such images (especially if they are huge) with GIMP, where all of the image's pixels are kept in memory (or the tile cache) all the time? Aren't many fractals such that you could calculate the value of each pixel independently of the others, with a very simple and minimal (non-interactive) program?

(And if your desired output file format is PostScript, why not let the printer do the job ;-) PostScript is after all a programming language... Just send the printer a PostScript program that calculates the desired image. For many fractals, it might be surprisingly short.)

--tml

tino.schwarze@informatik.tu-chemnitz.de (2003-09-24 at 1132.48 +0200):

I'd just like to say: Well done. I managed to create a A1 poster at 600 dpi - a whopping 1.1 Gig of picture data (about 20000x14000 pixels).

Was there a real difference between 600 DPI and 300 DPI? I have a mag here that is done in 300-400 DPI, with good paper... and it looks nice, and it is something you look nearer than a wall poster.

BTW: Is it possible that there is a 3 Gig limit on per-process memory? The machine has 6 GB, no ulimits and I got a "could not allocate x bytes" message when I gave 3 Gig tile cache to GIMP (it took about 500 Meg for other stuff, so I settled with 2.5 GB tile cache and still got a 3 Gig swap file plus 3 Gig memory usage).

What kind of processor and OS was used?

GSR

Guillermo S. Romero / Familia Romero wrote:

tino.schwarze@informatik.tu-chemnitz.de (2003-09-24 at 1132.48 +0200):

I'd just like to say: Well done. I managed to create a A1 poster at 600 dpi - a whopping 1.1 Gig of picture data (about 20000x14000 pixels).

Was there a real difference between 600 DPI and 300 DPI? I have a mag here that is done in 300-400 DPI, with good paper... and it looks nice, and it is something you look nearer than a wall poster.

IMO - Text...reading text in 600 DPI and on 300 DPI just feels different.

For graphics however, the " lots of DPI" are just used - in most cases - to emulate the color deph we have on CRT.

Arranging for the GIMP to be able to generate PDFs with "text layers as text" is on my "todo for 2.2" list.

Last month I made an artowork here that went to press either: 150DPI and A4, with text over graphics. Since the graphics in the case were "washed out" to work as a background, 150DPI was just good for it. The text however loooked a bit "steppy"

Hi,

"Joao S. O. Bueno" writes:

Arranging for the GIMP to be able to generate PDFs with "text layers as text" is on my "todo for 2.2" list.

To get that done in sane way, you'd have to use a PDF Pango backend. There is such a beast but last I checked it wasn't working that well and it depends on PDFLib. Also the current PDB API for text is definitely not sufficient for this but it would be worth to extend it for this matter.

BTW, it would be really nice if you could communicate this better. Your "todo for 2.2" should better be made available to the other developers since we will soon have to decide on the feature list for GIMP 2.2.

Sven

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Tino Schwarze wrote: | Hi there,
|
| I'd just like to say: Well done. I managed to create a A1 poster at 600 | dpi - a whopping 1.1 Gig of picture data (about 20000x14000 pixels). | While GIMP 1.2.4 crashed while rendering the fractal, GIMP 1.3.20 | managed to get it done and even save it as Postscript. Weehee! |
| BTW: Is it possible that there is a 3 Gig limit on per-process memory? | The machine has 6 GB, no ulimits and I got a "could not allocate x | bytes" message when I gave 3 Gig tile cache to GIMP (it took about 500 | Meg for other stuff, so I settled with 2.5 GB tile cache and still got a | 3 Gig swap file plus 3 Gig memory usage).

If you are using IA32, on linux, then yes there is a 3 Gig limit on per-process memory. 1 gig for the kernel and 3 gigs for the process.

If you are using Opteron, Itanion, Power4, G5, UltraSPARC, or Athalon 64, then you don't have that limit.

- -- Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/cf4yad4P1+ZAZk0RAhT6AKCWSVCrb8iqNDsBRamHFOyxrkvuqACfVS5t ZYYakwlna9ufenHocYObxYc=
=54ge
-----END PGP SIGNATURE-----

Tino Schwarze writes:
> You're right. If you could tell me such a program... I would have used > it. The nearest approximation was xfractint but it's cumbersome to use > and doesn't have a gradient editor (and I'm not sure whether it's > capable of rendering 20000x14000 pixel images). ;-)

Wouldn't it then be quicker to render the fractal in smaller pieces in GIMP, output as ppm files, and the just slap the pieces together with pnmcat and convert to PS with pnmtops?

> > (And if your desired output file format is PostScript, why not let the > > printer do the job ;-)
> Muhahaha. The printer took about 8 hours to RIP the precalculated stuff. > The Xeon/2.4GHz took about an hour to render the fractal.

Yeah, that was mostly a joke...

--tml

Ok. let's see.

Sven Neumann wrote:

Hi,

"Joao S. O. Bueno" writes:

Arranging for the GIMP to be able to generate PDFs with "text layers as text" is on my "todo for 2.2" list.

To get that done in sane way, you'd have to use a PDF Pango backend. There is such a beast but last I checked it wasn't working that well and it depends on PDFLib. Also the current PDB API for text is definitely not sufficient for this but it would be worth to extend it for this matter.

Well, I have never enve looked at Pango. My idea would be to get the text chars and attributtes from the GIMP, generate a image without the text only layers with no other layers above it, and "hand code" the PS code necessary to write a similar layer with the same font and coordinates. To embbed the font, I then would run GS with "pdfwrite" on a temporary PS.

If Pango thinks about providing the pdf layers itself, them I will probably check what it does, and does need improvement.

BTW, it would be really nice if you could communicate this better. Your "todo for 2.2" should better be made available to the other developers since we will soon have to decide on the feature list for GIMP 2.2.

Ok.
There are 4 things on this list:
1) The Custom Layer Combination Mode This will record a plain ASCII parasite with a mathematical c-like expression on how to combine pixels from this layer with the one bellow. (And with themselves, like dissolve mode). If not for the flexibility, this mode will avoid cluttering the UI each time one finds a fine-tune to the "add mode", as is the Grain merge.
2) Improve the postscript export (and maybe import) filter: - Easy: save indexed images as indeed indexed. They are saved as full RGB currently
- Save text layers as text
- Save multiple layers as multiple pages, with some meta-information - Change import filter to erad multiple page into multiple layers as an option. Use meta-info from above for offsets, and combination modes.
3 and 4 would be just plugins.
3) Plugin to manage postscript scriptlets (scale and color) The scriptlets would live in a .gimp-2.0 subdir, and be resources just like brushes and patterns. Them provide a bunch of scritlets like:
- Radial stripes
- Hex. grid
- Peano's curve
- more. (those two are ready) This one will need GS installed. 4) Scriptable graphic turtle plugin
- Actually, i've made a Python g.t. to use with the GIMP. The uses of this one would overlap with the above...maybe this one will obsolete the one above. Instead of PS, there would be a LOGO like set of statements to make scrippted drawings.

Besides that, what I am looking forward most for post 2.0 are: Brush transformations - dinamically resize and rotate the brush. Seens like much of what is needed for this is done already. Maybe even working....

And above all!! : MACRO RECORDER (with python output, please)... :-) Is someone looking at it? it made a lot of noise here a couple of months ago.

I also think we can get in touch with the scribus guys to have some of that color-correction-cmyk-CIE in place just to shut some of the said "professionals" up (and me no longer needing to load my images on f&&$$corel draw before sending them to the printer). And, why not, get a "edit in the GIMP" option inside scribus :-)

Sven

Hi,

"Joao S. O. Bueno" writes:

Well, I have never enve looked at Pango.

You will not get around it, see below.

My idea would be to get the text chars and attributtes from the GIMP, generate a image without the text only layers with no other layers above it, and "hand code" the PS code necessary to write a similar layer with the same font and coordinates. To embbed the font, I then would run GS with "pdfwrite" on a temporary PS.

I don't think it will be acceptable to write a "similar" layer. The PDF text layer will have to identical to what you see on screen. Tiny differences might be acceptable but you definitely want to apply the same font mapping, glyph substitution, line-breaking and bidi algorithms as the text tool. That's why you won't get around using Pango for the text layout.

If Pango thinks about providing the pdf layers itself, them I will probably check what it does, and does need improvement.

I was talking about a third-party Pango extension. It's not part of the standard Pango package.

There are 4 things on this list:
1) The Custom Layer Combination Mode This will record a plain ASCII parasite with a mathematical c-like expression on how to combine pixels from this layer with the one bellow. (And with themselves, like dissolve mode). If not for the flexibility, this mode will avoid cluttering the UI each time one finds a fine-tune to the "add mode", as is the Grain merge.

I don't see how this would avoid UI cluttering. You don't expect people who want to use an effect like Grain Merge to enter the mathematical formula manually, do you?

2) Improve the postscript export (and maybe import) filter: - Easy: save indexed images as indeed indexed. They are saved as full RGB currently
- Save text layers as text
- Save multiple layers as multiple pages, with some meta-information - Change import filter to erad multiple page into multiple layers as an option. Use meta-info from above for offsets, and combination modes.
3 and 4 would be just plugins.

(2) would be plug-in only as well, no?

Sven

On Friday 26 September 2003 7:19 am, Sven Neumann wrote:

Hi,

"Joao S. O. Bueno" writes:

Well, I have never enve looked at Pango.

You will not get around it, see below.

My idea would be to get the text chars and attributtes from the GIMP, generate a image without the text only layers with no other layers above it, and "hand code" the PS code necessary to write a similar layer with the same font and coordinates. To embbed the font, I then would run GS with "pdfwrite" on a temporary PS.

I don't think it will be acceptable to write a "similar" layer. The PDF text layer will have to identical to what you see on screen. Tiny differences might be acceptable but you definitely want to apply the same font mapping, glyph substitution, line-breaking and bidi algorithms as the text tool. That's why you won't get around using Pango for the text layout.

If Pango thinks about providing the pdf layers itself, them I will probably check what it does, and does need improvement.

I was talking about a third-party Pango extension. It's not part of the standard Pango package.

There are 4 things on this list:
1) The Custom Layer Combination Mode This will record a plain ASCII parasite with a mathematical c-like expression on how to combine pixels from this layer with the one bellow. (And with themselves, like dissolve mode). If not for the flexibility, this mode will avoid cluttering the UI each time one finds a fine-tune to the "add mode", as is the Grain merge.

I don't see how this would avoid UI cluttering. You don't expect people who want to use an effect like Grain Merge to enter the mathematical formula manually, do you?

No, I think of having a bunch of pre-loaded formulas as gimp resources (Plain ASCII in a .gimp-2.2/layer_modes/ ). And them, if someone wants to fine tune any of them he will just type his values there.

2) Improve the postscript export (and maybe import) filter: - Easy: save indexed images as indeed indexed. They are saved as full RGB currently
- Save text layers as text
- Save multiple layers as multiple pages, with some meta-information - Change import filter to erad multiple page into multiple layers as an option. Use meta-info from above for offsets, and combination modes.
3 and 4 would be just plugins.

(2) would be plug-in only as well, no?

Well yes...sorry, is that this one would come with the GIMP, the others might or not get in.

Sven

JS
->