Bug 305636

Summary:	crop uses 0.75 jpeg quality factor instead of file quality factor
Product:	[Applications] gwenview	Reporter:	emmanuel.manchester314
Component:	general	Assignee:	Gwenview Bugs <gwenview-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	benni, cfeck, emmanuel.manchester314
Priority:	NOR
Version:	2.9.0
Target Milestone:	---
Platform:	Mandriva RPMs
OS:	Linux
Latest Commit:		Version Fixed In:

Description emmanuel.manchester314 2012-08-22 22:39:35 UTC

When cropping, file is saved at the 0.75 jpeg quality factor, irrespective of the orginal file quality

You can check with imagmaick command :
identify -verbose *.jpg *.jpeg | grep -i quality

gwenview should 
1) save with the same quality factor
2) offer an option in the general settings to offer a fixed factor different of that of the read file

Thanks

On mandriva cooker and and 2011

Comment 1 Christoph Feck 2012-08-23 00:28:08 UTC

> save with the same quality factor

If you want to retain quality, you have to save to a lossless format, or with q=1.00 if you need JPEG. What imagemagik tells you is information, it doesn't mean that it's best to save again at this setting.

Comment 2 emmanuel.manchester314 2012-08-23 02:38:57 UTC

it is the same problem with red eye reduction

by the way this is faster : identify -format "%Q" *.jpeg
than identify -verbose *.jpg *.jpeg | grep -i quality

>>If you want to retain quality, you have to save to a lossless format
Indeed, and I am using raw format as well.
plus I can use jpegtran  -crop WxH+X+Y
<<Crop the image to a rectangular region of width W and height H, starting at point X,Y.  The 
**lossless** crop feature>>

I suppose gwenview uses the crop feature (or libraries) of convert / imagemagick
This may not be lossless, I do not know

Nevertheless, I do not want gwenview to choose the quality factor for me.
Especially to go from 0.94 to 0.75

>>it doesn't mean that it's best to save again at this setting.
This wahy I am asking it saves with the same quality factor as the original file

Comment 3 Benni Hill 2012-12-08 20:56:40 UTC


*** This bug has been marked as a duplicate of bug 294594 ***