Re: [Gimp-user] gbr viewer
On 05/30/2015 08:56 PM, mgroothuis wrote: >> Having gone nuts with my brush collection I not wish to cull it but >> have no easy way of viewing the brushes. Is there a piece of software >> like the abr viewer for GIMP brushes? > > *not=now This is a long standing annoyance. In the past I have done this: 1) Copy all the brushes from the GIMP's system wide 'brushes' directory into the user account 'brushes' directory. 2) Move or rename the system wide 'brushes' directory to make it invisible to the GIMP without risk of losing it. 3) In the GIMP's dockable dialog for brushes, with a blank white image canvas open and the brush tool active, work through the brush collection checking for and deleting unwanted ones. An easy way would be to convert all those .gbr files to jpg or png with the same names and review those in any image viewer. But alas... I was very surprised to find that Imagemagick does not have a decoder to read .gbr files, which makes the e-z way to convert all those brushes to PNG or other files for more convenient review a non-starter. The GIMP can do this, but I have never waded through the details and actually done it because Imagemagick is usually the right tool for the job of batch image conversion. https://stackoverflow.com/questions/5794640/how-to-convert-xcf-to-png-using-gimp-from-the-command-line :o/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] What causes random (in error) image color-inverting of TIFFs, over time? Is it correctable?
when you say youre seeing thison a web page, can i ask what type of system yure serving the pages with? wordpress etc? or is it an image generation with php or something? thanks dan On Sun, May 31, 2015 at 4:25 PM, Jay Smith wrote: > Greetings fellow Gimp Users, > > I make images using Gimp, but I assume that this question is not really > Gimp specific. > > I have tens of thousands of images (postage stamps) on my site. Every now > and then when I am looking at a page I discover that the image (a JPEG) has > had is colors "sort of inverted". The JPEGs were created in large batches > by a script from UNcompressed TIFF images. When I go back and look at the > the original TIFF, I discover that its colors are "sort of inverted" -- > thus the JPEG is a correct rendition of the appearance of its TIFF source. > > Thus the problem is in the TIFF. But, the problem happens now and then, > over the course of years. The TIFFs are _not_ being intentionally > manipulated in that time. The images was originally okay, now its not. It > seems to be completely random, just one image here and there. > > Somehow the TIFF is getting corrupted. I am assuming by a memory error or > a disk/RAID controller error, or such. The images are still openable in > Gimp. > > This is only happening to one out perhaps one out of five thousand images, > every five years. (I am just *guessing* at the error rate because I only > find out about them by randomly coming across them.) But, if I have 40,000 > images, that is eight images destroyed every five years. (And often I am > not able to replace the image because I no longer have the item.) > > This example image was originally created in 2006. I suspect (mostly > guessing) that it was corrupted sometime since 2010. There is no reason > that it would have been edited since that time and file modification > information shows nothing since 2006. > > On Ubuntu Linux, using "identify -verbose filename.tif" I can read the > header information. The only odd thing (to my eye) is that the create date > is 2011 and the modification date is 2006: > > Properties: > date:create: 2011-09-13T11:30:24-04:00 > date:modify: 2006-12-21T00:53:03-05:00 > > I am guessing that means the corruption may have happened in 2011, even > though the filesystems own file datestamp is 2006 and the lsattr command > shows nothing unusual. > > > Here is example of a) the resulting JPEG (just to illustrate the nature of > the corruption); b) a similar JPEG to show generally what it is supposed to > look like; c) the corrupted TIFF. > > Corrupted: > > http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-b_136468_r_l.jpg > > Correct image of a similar, but different item: > > http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-a_136467_r_l.jpg > > This is the TIFF file (corrupted, but viewable in Gimp; colors are > sort-of-inverted) Size 496 KB: > http://jsa.viewimage.net/temp/gimp/re02-pair_used-vf-b_136468.tif > > My primary question is whether there is a "particular bit that is getting > flipped" that could be "unflipped" by some sort of non-visual editing of > the source TIFF file? > > My secondary question is whether or not other people have seen this type > of problem crop up in large image libraries and what the causes have been? > > Any thoughts appreciated. > > Jay > ___ > gimp-user-list mailing list > List address:gimp-user-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list > List archives: https://mail.gnome.org/archives/gimp-user-list > ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] What causes random (in error) image color-inverting of TIFFs, over time? Is it correctable?
On Sun, 2015-05-31 at 17:25 -0400, Jay Smith wrote: > My primary question is whether there is a "particular bit that is getting flipped" that could be "unflipped" by some sort of non-visual editing of the source TIFF file? > My secondary question is whether or not other people have seen this type of problem crop up in large image libraries and what the causes have been? The nearest I have seen to this that i can remember involves software changes - e.g. a different version of libtiff or whatever. For example, recently some images on http://www.fromoldbooks.org/appeared to break, and it turned out to be a version of the jpeg library that had stopped supporting arithmetic encoding (for software patent reasons). TIFF is one of the more complex graphics formats in widespread use; for my own part I prefer to use PNG because at least the core image part is relatively simple and well-specified and widely supported. If by any chance you have both an "uncorrupted" and a "corrupted" TIFF file, and you know for sure what programs were used to create them and on what platform (e.g. Linux on SPARC, Linux on Intel-64, 32-bit Windows on Intel, etc) I'm willing to take a look, althogh I don't think I have TIFF debugging stuff around any more. It seems unlikely that the same single-bit error would happen on multiple images because of a hard drive problem, especially if a RAID 3 or higher storage system didn't detect it. Not impossible - an infinite number of monkeys typing for all eternity might all type nothing except page 54 of the January 1936 Great Western Railway timetable through Crewe - but I'd look for more likely causes first, the most likely of which might be a software change. Liam -- Liam R. E. Quin The barefoot typographer http://www.fromoldbooks.org/ - words & pictures from old books ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] What causes random (in error) image color-inverting of TIFFs, over time? Is it correctable?
Greetings fellow Gimp Users, I make images using Gimp, but I assume that this question is not really Gimp specific. I have tens of thousands of images (postage stamps) on my site. Every now and then when I am looking at a page I discover that the image (a JPEG) has had is colors "sort of inverted". The JPEGs were created in large batches by a script from UNcompressed TIFF images. When I go back and look at the the original TIFF, I discover that its colors are "sort of inverted" -- thus the JPEG is a correct rendition of the appearance of its TIFF source. Thus the problem is in the TIFF. But, the problem happens now and then, over the course of years. The TIFFs are _not_ being intentionally manipulated in that time. The images was originally okay, now its not. It seems to be completely random, just one image here and there. Somehow the TIFF is getting corrupted. I am assuming by a memory error or a disk/RAID controller error, or such. The images are still openable in Gimp. This is only happening to one out perhaps one out of five thousand images, every five years. (I am just *guessing* at the error rate because I only find out about them by randomly coming across them.) But, if I have 40,000 images, that is eight images destroyed every five years. (And often I am not able to replace the image because I no longer have the item.) This example image was originally created in 2006. I suspect (mostly guessing) that it was corrupted sometime since 2010. There is no reason that it would have been edited since that time and file modification information shows nothing since 2006. On Ubuntu Linux, using "identify -verbose filename.tif" I can read the header information. The only odd thing (to my eye) is that the create date is 2011 and the modification date is 2006: Properties: date:create: 2011-09-13T11:30:24-04:00 date:modify: 2006-12-21T00:53:03-05:00 I am guessing that means the corruption may have happened in 2011, even though the filesystems own file datestamp is 2006 and the lsattr command shows nothing unusual. Here is example of a) the resulting JPEG (just to illustrate the nature of the corruption); b) a similar JPEG to show generally what it is supposed to look like; c) the corrupted TIFF. Corrupted: http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-b_136468_r_l.jpg Correct image of a similar, but different item: http://jsa.viewimage.net/jsa/web/Lists/Denmark/AdPairs/Spec/re02-pair_used-vf-a_136467_r_l.jpg This is the TIFF file (corrupted, but viewable in Gimp; colors are sort-of-inverted) Size 496 KB: http://jsa.viewimage.net/temp/gimp/re02-pair_used-vf-b_136468.tif My primary question is whether there is a "particular bit that is getting flipped" that could be "unflipped" by some sort of non-visual editing of the source TIFF file? My secondary question is whether or not other people have seen this type of problem crop up in large image libraries and what the causes have been? Any thoughts appreciated. Jay ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] GIMP project's official statement on SourceForge's actions
This is the GIMP project's official statement on SourceForge's actions[1] in regard to "abandoned" projects on their service. We are fully aware that since their launch in 1999, SourceForge had been providing a valuable service to the Free Software community and that this service may still be relevant to some Free and Open Source Software projects today. The GIMP project did benefit from this service: SourceForge was the place to download the Windows installer for GIMP for many years and we appreciate it as an important part of GIMP history. When it comes to distributing GIMP, our goal is to make it as easy as possible for users to install GIMP. We do not want our users having to dodge any "offers" or to worry about possibly installing malware in the process. With our shared history, it was painful to watch the invasion of the big green "Download" button ads appearing on the SourceForge site. Our decision to move the Windows installers away from SourceForge in 2013 was a direct result of how its service degraded in this respect. The situation became worse recently when SourceForge started to wrap its downloader/installer around the GIMP project binaries. That SourceForge installer put other software apart from GIMP on our users' systems. This was done without our knowledge and permission, and we would never have permitted it. It was done in spite of the following promise made by SourceForge in November 2013 [2]: "we want to reassure you that we will NEVER bundle offers with any project without the developers consent." (emphasis in original) To us, this firmly places SourceForge among the dodgy crowd of download sites. SourceForge are abusing the trust that we and our users had put into their service in the past. We don't believe that this is a fixable situation. Even if they promise to adhere to the set of guidelines outlined below, these promises are likely to become worthless with any upcoming management change at SourceForge. However, if SourceForge's current management are willing to collaborate with us on these matters, then there might be a reduction in the damage and feeling of betrayal among the Free and Open Source Software communities. An acceptable approach would be to provide a method for *any* project to cease hosting at any SourceForge site if desired, including the ability to: * completely remove the project and URLs permanently, and not allow any other projects to take its place * remove any hosted files from the service, and not maintain mirrors serving installers or files differing from those provided by the project or wrap those in any way * provide permanent HTTP redirects (301) to any other location as desired by the project This is not unreasonable to expect from a service that purports to support the free software community. [1] http://web.archive.org/web/20150529094757/https://sourceforge.net/blog/gimp-win-project-wasnt-hijacked-just-abandoned/ [2] http://web.archive.org/web/20131115022447/http://sourceforge.net/blog/advertising-bundling-community-and-criticism/ -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Image transformation batch processing
Thanks for this inspiring piece of code. JLuc Le 29/05/2015 18:32, Saul Goode a écrit : On 28/05/15 19:44, JLuc wrote: What is that for a lisp-like code ? The difficulty that arises when recursing into subdirectories is that Script-fu does not provide a means of creating subdirectories (yet[1]). If I were to place all of the processed files in the same output directory, identically named files in subdirectories would overwrite each other, and I am too lazy to devise some renaming scheme that takes such duplicates into account. [1] https://bugzilla.gnome.org/show_bug.cgi?id=725626 ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] gbr viewer
Having gone nuts with my brush collection I not wish to cull it but have no easy way of viewing the brushes. Is there a piece of software like the abr viewer for GIMP brushes? -- mgroothuis (via www.gimpusers.com/forums) ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] gbr viewer
>Having gone nuts with my brush collection I not wish to cull it but >have no easy way of viewing the brushes. Is there a piece of software >like the abr viewer for GIMP brushes? *not=now -- mgroothuis (via www.gimpusers.com/forums) ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
