On 6/29/2016 1:05 PM, Matthew Malthouse wrote:

Over the last two days I've processed about 500 JPG files. Typically:

Open, auto levels (on F10 key) or manual, Crop or resize, maybe unsharp mask, overwrite (F9 key) with my default jpeg settings. each takes between 1 and 3 minutes. So fairly leisurely.

But the next group has already been processed for crop and size so all I need to is auto levels and over rewrite, keying:

Ctrl-O, ↓, ↓, Ent, F10, F9, Ent, Ctrl-W Ctrl-D

Open, down-arrow twice to select next image, enter, auto-levels, overwrite, enter, close, discard changes.

It's very rapid, processing four or five images a minute...

But after 5 or 6 images Gimp crashes — here are bits from the crash report

Segfault happened at: 0x71524: cmp %eax,(%r12) PC(0x00715254) ok
source (%eax" ok
destination "(%r12)" (0x00000000) not located in a known VMA region (needed writable region)!

gimp 2.8.12-0trusty2~ppa [prigin:LP-PPA-otto-kesselgulasch-gimp] gimp-2.8 crashed with SUGSEGV in file_open_image() and64
Ubunty 14.04
Unity
Ubuntu 3.13.0-91.138-generic 3.13.11-ckt39

4-core hyperthreaded (so 8 virtual) 16 Gb RAM, gimp allocated 8195 tile cache memory.

Computers a supposed to be faster than mere humans so I'm boggled that this should happen just because I'm doing things more rapidly than before.

I don't have a fix but I do know that if I were doing all these underlying calculations "by hand," the first one would probably be done around Christmas time.

Hi,

On Wed, Jun 29, 2016 at 7:05 PM, Matthew Malthouse wrote:

Over the last two days I've processed about 500 JPG files. Typically:

Open, auto levels (on F10 key) or manual, Crop or resize, maybe unsharp mask, overwrite (F9 key) with my default jpeg settings. each takes between 1 and 3 minutes. So fairly leisurely.

But the next group has already been processed for crop and size so all I need to is auto levels and over rewrite, keying:

Ctrl-O, ↓, ↓, Ent, F10, F9, Ent, Ctrl-W Ctrl-D

Open, down-arrow twice to select next image, enter, auto-levels, overwrite, enter, close, discard changes.

It's very rapid, processing four or five images a minute...

But after 5 or 6 images Gimp crashes — here are bits from the crash report

Segfault happened at: 0x71524: cmp %eax,(%r12) PC(0x00715254) ok
source (%eax" ok
destination "(%r12)" (0x00000000) not located in a known VMA region (needed writable region)!

gimp 2.8.12-0trusty2~ppa [prigin:LP-PPA-otto-kesselgulasch-gimp] gimp-2.8 crashed with SUGSEGV in file_open_image() and64
Ubunty 14.04
Unity
Ubuntu 3.13.0-91.138-generic 3.13.11-ckt39

Could you try the last version of GIMP (2.8.16) and if the problem still persists, could you run GIMP in gdb, get a stacktrace upon the crash and open a bug report with this information please? More about getting a stacktrace:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details For bug reports: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP

Thanks!

Jehan

4-core hyperthreaded (so 8 virtual) 16 Gb RAM, gimp allocated 8195 tile cache memory.

Computers a supposed to be faster than mere humans so I'm boggled that this should happen just because I'm doing things more rapidly than before.

Is there a fix?

I don't want to batch script because I need to eyeball the images to catch the occasional ones where auto-levels is a bad idea.

Matthew _______________________________________________ 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

ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot

On 29/06/16 19:05, Matthew Malthouse wrote:

I don't want to batch script because I need to eyeball the images to catch the occasional ones where auto-levels is a bad idea.

Processing and disk space are cheap. Script the whole lot, eyeball the results, and redo the odd ones manually (or with a different script). Or first do a visual check, split in two batches, one processed with auto-levels and one without, and apply a different script on each batch.

Hi,

On Fri, Jul 1, 2016 at 2:08 PM, Matthew Malthouse wrote:

On 30 June 2016 at 08:41, Ofnuts wrote:

Processing and disk space are cheap. Script the whole lot, eyeball the results, and redo the odd ones manually (or with a different script). Or first do a visual check, split in two batches, one processed with auto-levels and one without, and apply a different script on each batch.

In the end that's what I did. Couldn't get Gimp script on command line to work* so used Fred Weinhaus' autowhite script which
employs the Imagemagick function suit.

It was very effective, only 4 of 325 needed re-doing.

Even though you found a more effective way to do it, we'd still welcome a bug report with your stacktrace and step-by-step reproduction steps. :-)
Thanks!

Jehan

Matthew

* gimp -i -b '(batch-levels-stretch "*.jpg")' -b '(gimp-quit 0)' resulted in

(ufraw-gimp:5401): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
While parsing XMP metadata:
Error on line 46 char 1: End of element not expected in this context
While parsing XMP metadata:
Error on line 56 char 1: End of element not expected in this context

Metadata parasite seems to be corrupt While parsing XMP metadata:
Error on line 46 char 1: End of element not expected in this context

** (file-jpeg:5404): WARNING **: JPEG - unable to decode XMP metadata packet _______________________________________________ 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

ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot