Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
On Fri, 2009-12-18 at 18:09 -0500, Jay Smith wrote: 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. Well, you say that you want to process thousands of images. Then GIMP is the wrong tool for the job. 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. But that is exactly the same thing that happens when you open a TIFF file in GIMP and save it again. The pixel data is loaded into GIMP and your file is not any longer a TIFF file then, it is a collection of pixels, let's call it an image. Then when you save it as TIFF again, this collection of pixels is encoded as a TIFF file. Pretty much exactly what tifftopnm | pnmtotiff is doind. 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. Since GIMP doesn't support a maxval 255, you would more likely lose information if you used GIMP for this. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
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 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
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 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
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 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
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 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
On Fri, 2009-12-18 at 14:33 -0500, Jay Smith wrote: 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. Any software that dies while processing has a bug, so you could file a bugzilla report that loading broken files causes a plugin crash. They would potentially address whatever crash-related problems the broken file exposes (buffer overflows, etc), but are not likely to try to support broken files. The file that was processed correctly was, at best, an accident, albeit a fortunate one. I'd give you a link to bugzilla but the developer.gimp.org site doesn't seem to be responding for me right now. Might be a problem on my end. Anyway, check developer.gimp.org to find the link to bugzilla. -- Michael J. HammelPrincipal Software Engineer mjham...@graphics-muse.org http://graphics-muse.org -- There is a very fine line between hobby and mental illness. -- Unknown. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
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 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
Jay Smith wrote: 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. Hi, You seem like a nice guy with a healthy attitude, so it would be a shame if this would end up as your only contribution to GIMP. I encourage you to file a bug report so that it is possible to reproduce the problematic behavior and so that we can track progress in dealing with this. The address http://bugs.gimp.org/ redirects to GIMP's bugzill, which right now seems to be done. Thanks and regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Reducing UI clutter, docking bars removed ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
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 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
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 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
On Fri, 2009-12-18 at 18:09 -0500, Jay Smith wrote: 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. GIMP is the wrong tool for applying a common, single process (re: remove the color profile) to thousands of files. For that you would be better off using the NetPBM or ImageMagick suite of command line tools. GIMP is the right tool for editing the images, one (or a relatively small set) at a time, after the color profiles have been removed. Sven's suggestion of tifftopnm | pnmtotiff is nearly literal in how you run it from the command line. That | is a pipe symbol and means take the output from the command on the left and pass to the input of the command on the right. It's use is specific to the use of shell environments (such as BASH) and has nothing to do with GIMP, NetPBM or ImageMagick. All that is missing in Sven's example is the input file names and the output file names. Since there are thousands of these, you need to write a shell script (or Perl or Python or some other scripting language) to iterate over the existing file names and generate new file names. However, BASH, NetPNM and ImageMagick are not part of GIMP. For specific help on these you should visit their web sites and/or join a discussion group specific to those tools. To answer your specific question: no, you don't want to use GIMP to remove the color profiles from your thousands of images. It's the wrong tool to do that. -- Michael J. HammelPrincipal Software Engineer mjham...@graphics-muse.org http://graphics-muse.org -- Force has no place where there is need of skill. -- Herodotus; Book 3, Ch. 127 ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Is this a bug? Setting image w/corrupted icc profile to sRGB; plugin dies
On Fri, 18 Dec 2009 11:56:54 -0500 Jay Smith j...@jaysmith.com wrote: 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? I note there has been a number of replies, but I think the right tool for the right job is appropriate If you use imagemagick, convert orig.file +profile * new.file, it may get rid of all profiles and comments. If you have hundreds, just wrap the command in a script Owen ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
