On Sat, Apr 23, 2005 at 08:03:07PM -0600, jim feldman wrote:

I'm working with scanned medium format film images that are TIFF's of 100MB each. The GIMP environment is gimp 2.2.6 (built from ports about a week ago) on FreeBSD 5.3 Release. The display is a Linux (RH9) box. The tiff's are created by vuescan on linux.

i am curious if you have other file format options. just because the gimp can open and save as tiff does not mean that it likes to do this. can you make your scans directly into png and see if you still have the same problems?

carol

On Sun, Apr 24, 2005 at 11:43:00AM -0600, jim feldman wrote:

my options are tiff, jpg and pdf.? Of possible interest is that if I read in (using TC set to 400mb) one of the big tiff's, write it back out as a xcf (GIMP native), set the TC up to 600, read back the xcf, and it still crashes with the same errors.

why doesn't GIMP like TIFF?

to be completely honest with you, i rarely work with tiff and most of the information i have is based on what i have read here on this list & on the developer list.

the gimp uses image libraries that other people have written and maintain. you have libraries for tiff and jpeg and gif (many more as well). tiff is one of the older formats. if my information is correct, it was designed and then redesigned several times after the original.

another thing about tiff and gimp is their origins. tiff is not as free as gimp. i suggested png because it is smaller and contains all of the color information from your scanner that gimp can use right now. generally, png is much much smaller. this information about your scanner is from what i can see, still propietary information (meaning that if you want to use it correctly you still need to buy the software and hire a human to do some work with you, your scanner, your monitor and your printer) and probably not information that you need.

i have really seen it where gimp doesnt change, libtiff doesnt change yet there are all of a sudden a bunch of tiffs that dont work in the free software chain.

are you using linux? i am surprised if you are using linux that you do not have an option for png. this format is newer and designed after people had a better idea of what they wanted from their computers and their images. also, it has been free from the start so the writers of all image software know exactly what is there and how to use it.

in your original question, you seemed to understand that there was being some file size issues, and some one might help you with that. Meanwhile, for your own view of file formats, you can try to save a small image in tiff, png, pdf and jpeg and compare the image sizes. if you are scanning greyscale images, you can save the png's with Image->Mode->Greyscale and make an even greater size difference with not very much color loss. you can also make png's bigger than necessary as well, if you save it with an alpha channel that you do not need -- png's are not perfect either.

when i spoke of gimp "not liking tiffs" it was a simple way of saying that not all the information about them is available to the free apps and there is nothing that the developers can say about how they were or are designed. you are on the free software chain and for so many reasons it is better to use the formats that have always worked well for free.

sorry to ramble on like this, carol

On Sunday 24 April 2005 15:42, Carol Spears wrote:

On Sun, Apr 24, 2005 at 11:43:00AM -0600, jim feldman wrote:

my options are tiff, jpg and pdf.? Of possible interest is that if I read in (using TC set to 400mb) one of the big tiff's, write it back out as a xcf (GIMP native), set the TC up to 600, read back the xcf, and it still crashes with the same errors.

why doesn't GIMP like TIFF?

Actually,once an image is loaded, there is absolutely no difference for GIMP were it came from.

Ys, you had hit a bug, and yes, the best action is file a bug at bugzilla about it.

The only time it crashes is int eh decompose filter? Fine - it deserves a bug report, nonetheless, and if you could provide a traceback of the crash (as an attachemtn to the bug report), it would be an advance.

As for your work - what did you say you were uisng the decompose filter? To get a P&B version of the image? Anyway, try filters->colors->color mixer - if it won't have the same problens, it will allow you to do your work.

If you only need a PB version, even better is layers->colors->desaturate

Regards, JS
->

On Sun, Apr 24, 2005 at 11:43:00AM -0600, jim feldman wrote:

what i learned about pdf from the openicc mail list.

long ago when i was first able to read and make pdf on my little linux computer, my pdf looked terrible on my computer and the pdf i was able to make did not look good displayed on windows. this was a fact. these files also really taxed my computer. it was a 486. i had limited ram, cpu and disc space. i could read pdf, my computer had a very difficult time doing anything else while i displayed it, however. this week i found out one of the reasons for this.

the only way they could ensure that pdf display really well on windows was to include the font that they used in the file. fonts are huge files! my poor old computer was suffering by needing to read in the huge file when it could only read and display small portions of this information that was clogging the resources.

probably this was a terrible illegal thing they did also, saving the font with file. i think the free software people would have gotten into huge amounts of legal trouble if they had did this. it is theft and it is a stupid design.

gimp has suffered a lot from refusing to do things this way throughout the years, however, things work much better now, for everyone; not just gimp and linux. and none of gimps smart developers wasted too much time doing stupid things like writing software that makes you steal fonts.

when the gimp finally can manage color, i have a feeling everyone will know that it is REALLY HONESTLY managing color. not just assuring you that it is.

carol

Hi Jim,

Though I have never worked with such large images, don't you think it would be a good idea to save each TIFF as XCF, do whatever you want to do on XCF and then save the modified XCF as TIFF again? May be odd behavior will go away that way because XCF is the native file format. May be increasing the tile cache will work with the XCF!

Best regards

Asif

On 4/24/05, gimp-user-request@lists.xcf.berkeley.edu wrote:

Date: Sat, 23 Apr 2005 20:03:07 -0600 From: jim feldman
To: gimp-user@lists.xcf.berkeley.edu Subject: [Gimp-user] Odd behavoir with big images and memory

I'm working with scanned medium format film images that are TIFF's of 100MB each. The GIMP environment is gimp 2.2.6 (built from ports about a week ago)
on FreeBSD 5.3 Release. The display is a Linux (RH9) box. The tiff's are created by vuescan on linux.

The FreeBSD box was running with "only" 512MB memory. GIMP and the OS paged so much, the disk light went solid red for 2 minutes every time I touched
the image. I doubled the system memory, and figured I should set GIMP's tile
cache up to 600MB. I load the first image, and gimp tells me the image is 6228x5117, True color, and 247 MB in memory. I then tried to filters> colors>
decompose> RGB (so I could play with B&W) and GIMP died. I've attached a log
from a run that included stack trace mode and debug handlers. we died in gmem.c trying to allocate 8192 bytes. If I set the tile cache back down to 400MB however, everything works fine. 500MB also caused it to crash. I fI don't instrument it, I get a script-fu:29966: LibGimpBase-WARNING **: script-fu: wire_read(): error before it exits.

Bugzilla time?

thanks jim

On Sunday 24 April 2005 21:06, jim feldman wrote:

Quoting Asif Lodhi :

Hi Jim,

Though I have never worked with such large images, don't you think

it

would be a good idea to save each TIFF as XCF, do whatever you want

to

do on XCF and then save the modified XCF as TIFF again? May be odd behavior will go away that way because XCF is the native file

format.

May be increasing the tile cache will work with the XCF!

Best regards

Thanks for the offer, but thats exactly what I WAS doing. Both TIFF and XCF blow up, and it's not just during decompose, thats just one way for me to get it to happen relieably. I've had it happen during levels, making a layer copy, anything which seems to effect the whole image.

FIne...
So it is past the time for bugzilla. The main developers will answer you faster there.

This is surely a great malfunction which should be fixed - yoiu have not mentioned the O.S. you are using, did you?

Ok..better fill these details in bugzilla - search in there too (in other bug reports) for how to generate a traceback - developers wlll need it.

Regards,

JS
->

jim

jim feldman wrote:

Quoting Asif Lodhi >:

> Hi Jim, >
> Though I have never worked with such large images, don't you think it > would be a good idea to save each TIFF as XCF, do whatever you want to > do on XCF and then save the modified XCF as TIFF again? May be odd > behavior will go away that way because XCF is the native file format. > May be increasing the tile cache will work with the XCF! >
> Best regards

Thanks for the offer, but thats exactly what I WAS doing. Both TIFF and XCF blow up, and it's not just during decompose, thats just one way for me to get it to happen relieably. I've had it happen during levels, making a layer copy, anything which seems to effect the whole image.

jim

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

I have a curious question.

Have you tried to play with the tile cache sizes? I had a problem some time ago but I didn't get a chance to go further due to priority changes. I was having problems with large images as well. I got as far as changing tile cache sizes and I ran into weird problems.

I will have to get back to this by summer, hopefully. :)

On Sat, Apr 23, 2005 at 08:03:07PM -0600, jim feldman wrote:

I'm working with scanned medium format film images that are TIFF's of 100MB each. The GIMP environment is gimp 2.2.6 (built from ports about a week ago) on FreeBSD 5.3 Release. The display is a Linux (RH9) box. The tiff's are created by vuescan on linux.

The FreeBSD box was running with "only" 512MB memory. GIMP and the OS paged so much, the disk light went solid red for 2 minutes every time I touched
the image. I doubled the system memory, and figured I should set GIMP's tile cache up to 600MB. I load the first image, and gimp tells me the image is 6228x5117, True color, and 247 MB in memory. I then tried to filters> colors> decompose> RGB (so I could play with B&W) and GIMP died. I've attached a log from a run that included stack trace mode and debug handlers. we died in gmem.c trying to allocate 8192 bytes. If I set the tile cache back down to 400MB however, everything works fine. 500MB also caused it to crash. I fI don't instrument it, I get a script-fu:29966: LibGimpBase-WARNING **: script-fu: wire_read(): error before it exits.

For what it's worth, I (a graphics newbie) encountered this problem over the weekend. Images ranged in size from 15 to 87 MB. They were acquired by scanning using xsane on a Debian 3.0r2, Linux 2.4.18 machine and saved directly to xcf format using gimp 1.2.3. I was trying to separate the text of a scanned glossy-magazine article from the page background using the select by colour menu funtion. Got around it by copying smaller amounts of text to a separate layer and selecting by colour on these smaller portions of text.

Ta,

Gerald

Bugzilla time?

thanks
jim

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

jim feldman wrote:

> I have a curious question.
>
> Have you tried to play with the tile cache sizes? I had a problem > some time ago but I didn't get a chance to go further due to priority > changes. I was having problems with large images as well. I got as > far as changing tile cache sizes and I ran into weird problems. >
> I will have to get back to this by summer, hopefully. :) > --
> Robin Laing
>

playing with tile cache is what got me in trouble. Much over 400 causes the problems.

jim

This sounds like the problem that I had. If it is, then this is something that has been carried over from 1.2 into 2.x.

It looks like bug report time.