After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 338997 - jpegtran performance enhancement
jpegtran performance enhancement
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: Editing
CVS
Other Linux
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
Depends on:
Blocks: 165645 339081
 
 
Reported: 2006-04-19 10:47 UTC by Stephane Delcroix
Modified: 2018-07-12 00:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stephane Delcroix 2006-04-19 10:47:20 UTC
When doing lossless jpeg rotation, using JpegUtils.Transform, there is major performance issue in f-spot.

f-spot use the libjpegtran code borrowed from gthumb, end gthumb has the same issue.

e.g., for rotating a 7Mpixels jpeg of 3.18MB, it takes ~30sec.

The problem is NOT in f-spot, since I can reproduce it with the commandline version of jpegtran.

This issue can be fixed after settig en environment variable before starting f-spot.

$ export JPEGMEM=64m
$ f-spot

We are now in 2006, and the default memory allocation from jpegtran (released in 98) is no longer sufficient.

I see 2 ways of cleanly fixing this:
 - at compile time, setting a higher value for jpegtran memory usage
 - at runtime, let's the user choose (an option in the preference dialog ?) the amount of memory for jpegtran

For my point of view, I think we need to implement both solutions. Set a default minimal value a compile time, and let's users with bigger needs and higher memory to allow a bit more
Comment 1 Larry Ewing 2006-05-01 19:41:11 UTC
What exactly is the jpegtran doing in the low memory case that is so painfully slow?  I'd be ok with just setting the enviroment variable inside f-spot if it actually avoids the horrible slowness.
Comment 2 Stephane Delcroix 2006-05-12 17:05:14 UTC
After a few more investigations (and 2 weeks off), find hereafter some facts, and also some guesses.

The default is defined in /usr/include/jconfig.h
   #define DEFAULT_MAX_MEM 33554432
Redefining DEFAULT_MAX_MEM when recompiling jpegtran (the original one, command-line tool) does not works, because it is linked agaisnt libjpeg.so

I think that recompiling libjpeg for f-spot is clearly out of the scope.

The other (and only) remaining solution is to set up the environment variable.

And to answer your question, jpegtran will never allocate more memory than specified. Si I guess that it rotate only portions of the image, write them to the file and so on.
Comment 3 Bengt Thuree 2007-11-26 17:54:35 UTC
Have we incorporated this changing environment variable JPEGMEM into the start script for f-spot?

I just checked, and can not find it.
Comment 4 André Klapper 2018-07-12 00:03:18 UTC
F-Spot has moved to https://github.com/f-spot/f-spot/issues

If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub.

Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.