Hi,

GIMP 2.6.6 running on Ubuntu 8.04 "Hardy" Linux.

In the archives I found information that to delete a color profile, you just set the color space (Image, Mode, Assign Color Profile...) to sRGB which apparently is a color space without color profile.

There were three TIFF images which PhotoShop 5.x on Windoze would not open due to corrupted color space. These images are believed to have been corrupted years ago when a server had bad RAM and wrecked a couple thousand images being transferred to a particular external hard drive; most were easy to identify as corrupted (i.e. reported, not real, size grew to over 2GB ea; but we still find a few that generally work okay, but have corruption in the profile). I was trying to fix them for another person so that they could open them in PhotoShop.

Using the above mentioned technique in GIMP, I fixed one of them just fine. Its corruption (and on-open error message) was different than the other two.

However, two others were not fixable by this method.

??? Is this a bug?

This is what happened...

In the Open File dialog, upon just clicking on the filename (prior to actual opening, but resulting in seeing a preview), Gimp put out error messages:

lcms: Error #12288; Corrupted memory profile

However, the file _could_ be opened in Gimp.

Upon attempting to assign the sRGB to the image (Image, Mode, Assign Color Profile...) just clicking on the last part (Assign Color Profile...) resulted in a) the dialog did not open for doing that task; b) the menu collapsed back to normal state; c) the error message appeared

lcms: Error #12288; Corrupted memory profile

and d) in the Message Console (sorry, I lost the exact text) it says that the "dying plugin... may have left Gimp... unstable state" or something like that.

So, just clicking to get the dialog to change to sRGB killed the plugin that was do to that task.

(In the end I solved my problem by literally copying & pasting the image into a new window and then saving that as the same filename.)

I _do_ have a saved sample corrupted image file if anybody needs this for testing purposes.

Is this a bug? Is it known? Should I post on the developer list? Should I put it in bugzilla?

Lastly.... is there a command-line bulk/batch method to remove color profile (i.e. set to sRGB) on hundreds of image files (TIFF) at a time?

Jay

On 12/18/2009 02:02 PM, Sven Neumann wrote:

On Fri, 2009-12-18 at 11:56 -0500, Jay Smith wrote:

I _do_ have a saved sample corrupted image file if anybody needs this for testing purposes.

Is this a bug? Is it known? Should I post on the developer list? Should I put it in bugzilla?

Your files are corrupt. You can't possibly expect GIMP to fix them. Of course if you really care, you could probably write some code that is capable of dealing with your broken files and that may even be able to fix them. But don't expect this work to be done by someone else for you.

Sven

Sven,

Yes, the file is corrupted. And, no, I didn't and don't expect Gimp to automagically fix it for me -- though sometimes (as in one of the three files) it does fix it; maybe that functionality should be removed? So, when there is a problem with a file, Gimp is one of the tools I reach for first, just in case Gimp can help.

I think my point was somewhat misunderstood and I feel that the tone of part of your response is less than friendly. I was trying to point out something that could perhaps be _helpful_ but instead I feel a bit "slapped down". There is a reason that new users often feel unwelcome in such arenas.

My point is that the *error/reporting messages say* that (because of the corrupted file) the plugin has died and potentially left Gimp in an unstable state.

If I were a developer, with the necessary skills, I would be curious about what was killing off the plugin and why the plugin dieing (especially when it was just trying to open a dialog and had not actually attempted to take action on the image yet) would leave the whole program in a potentially unstable state. Perhaps that's just me. The file is okay enough to display a preview, to be opened, to be edited, and to be saved, etc., in Gimp (but it can't even be opened in PhotoShop 5.x). So already Gimp is more robust. That robustness surely came by design, intent, and application of considerable skill. My _intent_ was that somebody with the proper skills might be interested and might want to look at the plugin to see what about it is not as robust as the rest of the program environment. By sharing my experience and making sure I have available a sample of such a corrupted file, I make such exploration possible for anybody with the skills and interest who is curious about it. If nobody is curious about it, then fine -- not a problem.

At NO point do I recall asking anybody to do any work for me.

I was attempting to contribute and share and experience and information.

I infer from your response that I have been instructed to think twice before trying to get involved again.

I apologize for wasting your time and some electrons.

Jay

On 12/18/2009 03:16 PM, Sven Neumann wrote:

Hi,

On Fri, 2009-12-18 at 14:33 -0500, Jay Smith wrote:

If I were a developer, with the necessary skills, I would be curious about what was killing off the plugin and why the plugin dieing (especially when it was just trying to open a dialog and had not actually attempted to take action on the image yet) would leave the whole program in a potentially unstable state.

The message that tells you about the dying plug-in is just a general dialog. It says that GIMP 'might' have been left in an unstable state. In general this is not the case and there's nothing to worry about here.

I have written the plug-in that crashed, and I can tell what's most likely going wrong, without having a look at the code or your broken image. The assumption that the plug-in would not have accessed the image before it opens the dialog is wrong, since the plug-in needs to read the color profile from the image in order to present information about the current color profile to the user. If the attached profile is corrupt, then it may crash at this point. I don't really care about fixing this for all sorts of corrupt input data. Such a fix would most likely introduce regressions and would make the code much more difficult to read and maintain.

You can probably get the plug-in to do its job of removing the attached color profile by calling the plug-in procedure non-interactively. Or you could simply remove the "icc-profile" parasite from the image.

Sven

Sven,

Thank you very much for this information. It is very helpful.

When I originally searched for information about how to do this, before I posted, I came across a discussion of the subject -- and you were a participant.

But, what I have _not_ found information about how to do is:

a) Call the plug-in procedure non-interactively

b) Use gimp_image_parasite_detach -- I am not sure in what environment this is used, etc. I found
http://authors.phptr.com/essential/gimp/appE/gimp_image_parasite_detach.html but can't figure out how to run it (from the command line does not work).

c) "simply remove the "icc-profile" parasite from the image" as you suggest. This is what I wanted to do all along, from the very start, but somehow my searching is not finding instructions. I must not be searching with the correct search terms.

Any advice would be appreciated.

By the way, if possible, I would like to do this parasite removal on tens of thousands of files. Perhaps as the 'exec' of a 'find' command.

Thanks!

Jay

On 12/18/2009 05:48 PM, Sven Neumann wrote:

Hi,

On Fri, 2009-12-18 at 15:39 -0500, Jay Smith wrote:

By the way, if possible, I would like to do this parasite removal on tens of thousands of files. Perhaps as the 'exec' of a 'find' command.

I don't understand why you are even considering to use GIMP then. If all you care about is the image data, then a simple tifftopnm | pnmtotiff will probably do the trick.

Sven

Hi Sven,

I am afraid I am not 100% following what you are saying. Perhaps I miscommunicated. Or perhaps I am just not filling in assumed knowledge well enough.

I want to use Gimp as an image editor.

However, there are thousands of images that have been created over the years on different versions of various programs, some of which have varying ICC profiles embedded. And, then, importantly, there are apparently some that have corrupted ICC profiles which were caused by a major data corruption event years ago.

So, I was asking about how to get to sRGB for all them (i.e. remove the color profile). You had mentioned some methods, but I don't have enough information on how to use those methods.

Perhaps I am really missing something -- in Gimp is there a method / command to (one at a time) remove the color profile parasite? That question was never answered in the archived newsgroup messages I have read. Instead there is reference to changing it to sRGB which apparently accomplishes the same thing as removing the color profile parasite. I thought that I had once done some method/command in Gimp to remove the color profile parasite, but perhaps I am mis-remembering.

My goals are two-fold:

a) When I find an individual image with a corrupted profile, I wish to remove the color profile parasite. (Changing to sRGB is not an option due to the previously discussed problem that it is a corrupted file and of course the plug-in is not always going to be happy with it.) I am no farther along in understanding whether Gimp has a tool to do this.

b) I would like to find a method to remove color profile parasites on thousands of images, via the command line. You have suggested trying "tifftopnm | pnmtotiff" do to this. I will experiment with that, but I have a concern as noted below.

Based on your most recent recommendation, I looked at http://netpbm.sourceforge.net/doc/tifftopnm.html and I am not sure how this helps me, unless you are suggesting to ROUNDTRIP using these two programs.

However, I noted it said [below] that theoretically you can lose information in certain cases. I have no idea if my images would be affected by that.

"The PNM output has the same maxval as the Tiff input, except that if the Tiff input is colormapped (which implies a maxval of 65535) the PNM output has a maxval of 255. Though this may result in lost information, such input images hardly ever actually have more color resolution than a maxval of 255 provides and people often cannot deal with PNM files that have maxval > 255. By contrast, a non-colormapped Tiff image that doesn't need a maxval > 255 doesn't have a maxval > 255, so when tifftopnm sees a non-colormapped maxval > 255, it takes it seriously and produces a matching output maxval. Another exception is where the TIFF maxval is greater than 65535, which is the maximum allowed by the Netpbm formats. In that case, tifftopnm uses a maxval of 65535, and you lose some information in the conversion."

Thanks.

Jay