On Thu, Jun 17, 2010 at 9:10 PM, Jade wrote:

he thinks the EXIF data is still in there but he's too busy and I don't know what to do.

IIRC, Gimp's format does not have any EXIF data. (And EXIF is genrally a JPEG thing, no?). Try comparing the size of the last save with previous saves, and see if the last one looks large enough to contain useful data. If the last save is too small to fit your image, you probably won't be able to extract useful data.

On Fri, Jun 18, 2010 at 6:32 PM, Jade wrote:

Also, if I had previous saves, I'd be fine... I saved the same file over and over and now it's empty. It's about 70 Kb and I think that's too small.

I think something like this has happened to all of as at some point. It's a bitter pill to swallow, but there's a take-away lesson: every so often do File->Save As and save a copy. I tend to name my files like 'project_name-01', and after an hour or two (or any client revisions) save as 'project_name-02', then '-03', '-04', etc.

There's a GIMP plug-in that adds an iterative save option (I've never used it though):
http://registry.gimp.org/node/18873

For what it's worth I learned my lesson from Photoshop, not GIMP. It trashed a file I had been working on for over 6 hours and I was only able to retrieve bits and pieces - nothing close to the full document. I had to start over. Over the past 10 years I've seen trashed files at least once from most of the Adobe suite, so I don't think you give up on GIMP just yet. A crash during the save process can be a very dangerous thing, no matter which program you're using.

HTH, Chris

On Thu, 17 Jun 2010 21:10:00 +0200 (CEST) "Jade" wrote:

I read on several googled pages that it's possible to recover layers from EXIF data, etc, and it would help me out a lot to recover even the line art.

EXIF data in 'Extra' information, generally things such as dates, exposure time, if the flash was activated or not, etc. The EXIF data does not contain any graphical info at all, so it won't be of any help for recovering the image.

John

I had a similar problem. Not with such a valuable drawing, thank goodness for me. Can you tell me how you saved it? Was it just as .xcf or did you save a .jpeg or .gif version? If the file is stored somewhere, if you remove gimp from your computer, then reinstall, the file may come up again. This happened to me, but with a jpeg file I was able to find using Picasa.

Is there another program that read .xcf files you could use to find the drawing. Eg. Inkscape?

Regards Michaela

-----Original Message----- From: gimp-user-bounces@lists.XCF.Berkeley.EDU [mailto:gimp-user-bounces@lists.XCF.Berkeley.EDU] On Behalf Of Jade Sent: Saturday, 19 June 2010 10:43 AM To: gimp-user@lists.XCF.Berkeley.EDU Subject: [Gimp-user] Help recovering a bad .xcf file

On Thu, 17 Jun 2010 21:10:00 +0200 (CEST) "Jade" wrote:

I read on several googled pages that it's possible to recover layers from EXIF data, etc, and it would help me out a lot to recover even the line art.

EXIF data in 'Extra' information, generally things such as dates, exposure time, if the flash was activated or not, etc. The EXIF data does not contain any graphical info at all, so it won't be of any help for recovering the image.

John

Dang. I don't know what he was thinking, then.

Jade:

Just for what it might be worth, here's my ordinary work method.

When I decide to start a major project, I give it a name, and use that name for a directory / folder. Then I create a text file, "Log.txt" using my favorite text editor. I next create a subdirectory "Start" into which I copy any material from external sources; if I would have to spend much time searching for some item I used, it would get stored in this folder. Information I might want to keep track of about files in the "start" folder, for example, the name of the source, and the path at the time I found the image, would be listed in the log.txt file.

When I start work, I keep progress notes in the log file, for example

> Started with my image; adjusted color balance to ... >
> Added image2.png as a layer to the image, and converted it to use as > a mask.

At major break points, for example, if I decide to retrieve something from the kitchen, or if someone comes to the door, if it's been a while since I saved my work, or most importantly, if I reach a point where I'm not sure what to do next, I save the working image as 00n.xcf, where n is the next sequential number. At the same time, I save the log file as 00n.txt. I close the file (and often close GIMP), reopen the files (00n.xcf and 00n.txt), and immediately save the files wioth an incremented name so that subsequent work does not overwrite the previous save.

This sounds like a lot of work, but I think it has actually saved me a lot of time, in the number of times I decided a ways down one path, that I should have done it the other way. It's a whole lot easier in this case to save version 010, and reload version 006, and explore the results of taking the other path. And the reason for saving version 010, is that sometimes I only think I would have liked the other path.

Finally, I regularly save the main folder in multiple places on different mediums. For example, on two different physical hard drives, or on a physical hard drive and thumb drive. I can't think of a significant file of which I don't have at least two copies.

ns

Friends

The reason behind part of what I wrote:

At the same time, I save the log file as 00n.txt. I close the file (and often close GIMP),

Partly this is habit from my early years of personal computing, when software I chose to use sometimes had the habit of getting more error prone the longer it was used. I found with various packages, most no longer around, that if I periodically closed down the software, and allowed it to reset itself, that I had fewer abnormal ends. This is not so true with GIMP, and other modern packages, but I still find that I'm much more likely to have a serious problem with GIMP when I've worked on 35 or 40 images during a work session, than when I've worked with 4 or 5.

ns

I've one more observation to add to this.

BIG FAT DISCLAMER: Please, _PLEASE_ don't turn this into just another flame war.

Anyway, I don't know if it's just me or not, but Gimp's extremely stable on Linux. I've seen it crash maybe two or three times in past year, and it certainly never crashed when saving images... ever. So, it's another option for those that are having stability issues with Gimp.

I first noticed this difference when I was told by a windows user about performance issues with Gimp on Windows, and I installed it at work to see what it was about. And it is quite different, especially comparing the antiquated Windows XP to latest Linux distros in 64-bit incarnations.

I myself run Arch Linux, 64-bit version, with Gimp 2.6.8 (in fact the modified version called Painters Studio), and stability- or performance-wize, I've got nothing to complain about, and have certainly never lost any work.

Regards,

Hi,

Also I was really surprised that an auto backup isn't in GIMP already. I used to use a really old, backwoods photo editor and it automatically made a backup file and autosaved it every ten minutes.

What you really need for your case is not an auto-backup feature, but atomic save operations. Instead of writing over the existing file when you save, GIMP should write to a temporary file in the target directory. And only if it succeeds in writing this file completely should it move the temporary file over the existing file. That way you wouldn't have lost your file completely.

Please feel free to open a bug report for this.

Sven

On Sat, Jun 19, 2010 at 8:52 PM, Jade wrote:

I'm running the latest Ubuntu and it's probably more of a hardware issue than a software. When I say "Gimp crashed," I mean that it froze up and then exited. I don't know what happened besides that. I have a super old computer with three quarters of a gig of ram and it probably was having a hard time processing such a big image and shut it down. I don't really know. I was working with a 3000 x 3000 image with several layers; it was probably too much for the PC to handle, not Gimp. The file's gone, either way. :(

Ooh, that _is_ a big image. What you can do is repartition the hard drive to give Linux more swap space. It probably ate up all the swap space and killed itself. Even with the large swap space (say 4 or even 8 G) it will be super-slow (RAM is always faster, obviously), but at least it won't die easily.

You can also add the system monitor applets to your panel, and monitor the swap usage (right-click the newly added applet, and you'll find the appropriate checkbox in the preferences). If swap becomes full, it's time to save the image and restart Gimp. The history of your edits contributes to memory usage, so restarting Gimp will free some.

On Sat, Jun 19, 2010 at 10:44 PM, Sven Neumann wrote:

Hi,

Also I was really surprised that an auto backup isn't in GIMP already. I used to use a really old, backwoods photo editor and it automatically made a backup file and autosaved it every ten minutes.

What you really need for your case is not an auto-backup feature, but atomic save operations. Instead of writing over the existing file when you save, GIMP should write to a temporary file in the target directory. And only if it succeeds in writing this file completely should it move the temporary file over the existing file. That way you wouldn't have lost your file completely.

Please feel free to open a bug report for this.

Better way would be to do what most text editors do. Create a backup of the old file (remember those files that end with a tilde '~'?) before overwriting it with the new save. It should be a trivial fix.

On Sun, 2010-06-20 at 03:29 +0200, Branko Vukelic wrote:

On Sat, Jun 19, 2010 at 10:44 PM, Sven Neumann wrote:

Hi,

Also I was really surprised that an auto backup isn't in GIMP already. I used to use a really old, backwoods photo editor and it automatically made a backup file and autosaved it every ten minutes.

What you really need for your case is not an auto-backup feature, but atomic save operations. Instead of writing over the existing file when you save, GIMP should write to a temporary file in the target directory. And only if it succeeds in writing this file completely should it move the temporary file over the existing file. That way you wouldn't have lost your file completely.

Please feel free to open a bug report for this.

Better way would be to do what most text editors do. Create a backup of the old file (remember those files that end with a tilde '~'?) before overwriting it with the new save. It should be a trivial fix.

It is actually a very difficult fix. There are hundreds of save plug-ins and all would have to be fixed. Also GIMP plug-ins may save using a helper plug-in that transparently enables saving to remote locations. It is definitely not trivial to fix this.

Sven

On 06/20/2010 06:45 PM, Sven Neumann wrote:

On Sun, 2010-06-20 at 03:29 +0200, Branko Vukelic wrote:

Better way would be to do what most text editors do. Create a backup of the old file (remember those files that end with a tilde '~'?) before overwriting it with the new save. It should be a trivial fix.

It is actually a very difficult fix. There are hundreds of save plug-ins and all would have to be fixed. Also GIMP plug-ins may save using a helper plug-in that transparently enables saving to remote locations. It is definitely not trivial to fix this.

Doing it for XCF would be enough, especially with the new Save and Export separation we do.

/ Martin

On Sun, 2010-06-20 at 03:26 +0200, Branko Vukelic wrote:

On Sat, Jun 19, 2010 at 8:52 PM, Jade wrote:

I'm running the latest Ubuntu and it's probably more of a hardware issue than a software. When I say "Gimp crashed," I mean that it froze up and then exited. I don't know what happened besides that. I have a super old computer with three quarters of a gig of ram and it probably was having a hard time processing such a big image and shut it down. I don't really know. I was working with a 3000 x 3000 image with several layers; it was probably too much for the PC to handle, not Gimp. The file's gone, either way. :(

Ooh, that _is_ a big image. What you can do is repartition the hard drive to give Linux more swap space. It probably ate up all the swap space and killed itself. Even with the large swap space (say 4 or even 8 G) it will be super-slow (RAM is always faster, obviously), but at least it won't die easily.

3000x3000 is not that large. How much RAM do you have and how is the tile-cache size configured in GIMP?

Sven

On Sun, Jun 20, 2010 at 6:45 PM, Sven Neumann wrote:

It is actually a very difficult fix. There are hundreds of save plug-ins and all would have to be fixed. Also GIMP plug-ins may save using a helper plug-in that transparently enables saving to remote locations. It is definitely not trivial to fix this.

If this kind of thing cannot be implemented for all formats, then I guess it is a design flaw. How come things like saving a backup copy of the target cannot be implemented in a single place for all file formats? That simply stinks of bad design, sorry. Now, I'll just STFU since I'm not the one to contribute the patch, and hopefully this has been already fixed in the devel branch (I remember reading something about this).

Regards,

On Sun, Jun 20, 2010 at 7:34 PM, Sven Neumann wrote:

On Sun, 2010-06-20 at 03:26 +0200, Branko Vukelic wrote:

On Sat, Jun 19, 2010 at 8:52 PM, Jade wrote:

I'm running the latest Ubuntu and it's probably more of a hardware issue than a software. When I say "Gimp crashed," I mean that it froze up and then exited. I don't know what happened besides that. I have a super old computer with three quarters of a gig of ram and it probably was having a hard time processing such a big image and shut it down. I don't really know. I was working with a 3000 x 3000 image with several layers; it was probably too much for the PC to handle, not Gimp. The file's gone, either way. :(

Ooh, that _is_ a big image. What you can do is repartition the hard drive to give Linux more swap space. It probably ate up all the swap space and killed itself. Even with the large swap space (say 4 or even 8 G) it will be super-slow (RAM is always faster, obviously), but at least it won't die easily.

3000x3000 is not that large. How much RAM do you have and how is the tile-cache size configured in GIMP?

I guess it might be on an older machine OP mentioned.

As for myself, I've got 2G RAM, and 1G swap space (big mistake, I know) on a 64-bit linux. I sometimes run out ?f memory/swap on a image that is like a little smaller than 3000x3000 when I have more than 20 layers and couple of hours of work on it. Tile cache is at 1024M.

Regards,

On Sun, 2010-06-20 at 22:17 +0200, Branko Vukelic wrote:

As for myself, I've got 2G RAM, and 1G swap space (big mistake, I know) on a 64-bit linux. I sometimes run out ?f memory/swap on a image that is like a little smaller than 3000x3000 when I have more than 20 layers and couple of hours of work on it. Tile cache is at 1024M.

Why would you limit your tile-cache size to 1GB if you have 2GB of RAM? You might want to read http://www.gimp.org/unix/howtos/tile_cache.html

Sven

On Mon, Jun 21, 2010 at 9:27 PM, Sven Neumann wrote:

On Sun, 2010-06-20 at 22:17 +0200, Branko Vukelic wrote:

As for myself, I've got 2G RAM, and 1G swap space (big mistake, I know) on a 64-bit linux. I sometimes run out ?f memory/swap on a image that is like a little smaller than 3000x3000 when I have more than 20 layers and couple of hours of work on it. Tile cache is at 1024M.

Why would you limit your tile-cache size to 1GB if you have 2GB of RAM?

Because I haven't read the howto? :D

You might want to read http://www.gimp.org/unix/howtos/tile_cache.html

Thanks for the link.

On Sun, 2010-06-20 at 22:12 +0200, Branko Vukelic wrote:

On Sun, Jun 20, 2010 at 6:45 PM, Sven Neumann wrote:

It is actually a very difficult fix. There are hundreds of save plug-ins and all would have to be fixed. Also GIMP plug-ins may save using a helper plug-in that transparently enables saving to remote locations. It is definitely not trivial to fix this.

If this kind of thing cannot be implemented for all formats, then I guess it is a design flaw. How come things like saving a backup copy of the target cannot be implemented in a single place for all file formats? That simply stinks of bad design, sorry. Now, I'll just STFU since I'm not the one to contribute the patch, and hopefully this has been already fixed in the devel branch (I remember reading something about this).

Yes, it is a very terrible design and it dates back to the last millenium. But fixing such design flaws in a backward-compatible manner is rather difficult. Doing this correctly is on the list of things to fix if we should ever revamp the file plug-in API.

For now we can probably fix it easily for XCF files and with some more effort some of the most often used file plug-ins.

Sven

On Mon, Jun 21, 2010 at 9:30 PM, Sven Neumann wrote:

For now we can probably fix it easily for XCF files and with some more effort some of the most often used file plug-ins.

Well, as someone else has already pointed out, fixing this for XCF-only is a good option.