GNOME Bugzilla – Bug 569833
file-jpeg-save erroneous with small quality values
Last modified: 2009-08-10 19:37:07 UTC
Please describe the problem: I developed a batch to compress one image at all Q levels, from 1 to 100 and found that levels 1 thru 5 are not working in Script-Fu, trying to set such a quality level creates an image with the default jpeg quality level. Example: (file-jpeg-save RUN-NONINTERACTIVE image drawable "Q001.jpg" "Q001.jpg" (/ 1 100) 0 0 0 "" 0 1 0 1) The quality level is, according to the Procedure Browser, a float between 0 and 1, I select it with (/ 1 100) to mean 0.01 (the same happens if I use float values). Steps to reproduce: 1. Go to script-fu, load an image, get its drawable 2. Execute (file-jpeg-save RUN-NONINTERACTIVE image drawable "Q001.jpg" "Q001.jpg" (/ 1 100) 0 0 0 "" 0 1 0 1) Actual results: The resulting file will not have the selected quality level of 1 (it will be 85, the default) Expected results: A JPEG file output with quality level 1, as selected in the command Does this happen every time? Yes Other information: For any values between 6 and 100 it works as expected.
I guess this is a problem in libjpeg then. GIMP just passes the value to libjpeg. If libjpeg doesn't work properly for values < 6, then we should probably document this and bail out with a calling error if the quality is too small.
I don't think it's libjpeg's fault, because if you save a file in jpeg format using the usual Save As... with jpg extension and then select the quality in the dialog, it works perfect for any quality. So I'd say it is something in the way the float value is being read in the console.
So you are saying this is a Script-Fu bug then? Could you perhaps try the same thing using Python?
Could you please tell me how to do it on Python? Anyways if you want to confirm the bug, you could try the scm script I use (which works perfect for Q>5) Just open the output.jpg file with an app like jpegsnoop ( http://www.impulseadventure.com/photo/jpeg-snoop.html ) and at the very end of the window you'll see the true quality value the jpeg has been saved to (and this program works perfect, I'm deep into jpeg spec.) Save the script as simple-jpeg.scm and run it like: (simple-jpeg 'd:\\image.bmp') (define (simple-jpeg filename) (let* ((image (car (gimp-file-load RUN-NONINTERACTIVE filename filename))) (drawable (car (gimp-image-get-active-layer image))) (Q 1) (jpgname "output.jpg")) (while (< Q 7) (set! jpgname (string-append jpgname (number->string Q))) (set! jpgname (string-append jpgname ".jpg")) (file-jpeg-save RUN-NONINTERACTIVE image drawable jpgname jpgname (/ Q 100) 0 0 0 "" 0 1 0 0) (set! Q (+ Q 1))) (gimp-image-delete image) ))
Created attachment 140313 [details] [review] Proposed fix Here the problem is that the plug-in 'file-jpeg' uses default settings when run non-interactively and the quality parameter received is less than or equal to 0.05. see: http://git.gnome.org/cgit/gimp/tree/plug-ins/file-jpeg/jpeg.c#n349 The patch is against 'plug-ins/file-jpeg/jpeg.c' of release 2.6.6.
It would really be so much nicer if you started to send patches against git master formatted by git. It feels like a waste of time to do these commits the old way... commit fc979283de60d67591cb61e11f5c9aba2f2b543d Author: Massimo Valentini <sixtysix@inwind.it> Date: Mon Aug 10 21:26:53 2009 +0200 Bug 569833 – file-jpeg-save erroneous with small quality values Use the passed parameters if the quality setting is 0.01 or greater instead of rejecting values below 0.05 in non-interactive mode. plug-ins/file-jpeg/jpeg.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)