At 12:09 PM 7/14/2006 +0200, dan1 wrote:
>> At 10:39 PM 7/13/2006 +0200, dan1 wrote:
>>>Hello.
>>>
>>>I have seen a quite strange behaviour lately:
>>>If I convert a picture from jpeg to jpeg in a
smaller size, then I end up
>>>with 323Kbytes. However, if I do first convert
this same source file to a
>>>TIFF (no resize), and then resize it from tiff
to jpeg in the same
>>>dimension than the other file, I end up with
only 255Kbytes.
>>>
>>>So there seems to be a problem in how the
conversion is handled inside the
>>>algorithm.
>>>Visually speaking, I think that both results
quality are exactly the same
>>>(watching closely), but the only difference is
that we lose a lot of disk
>>>space from jpg to jpg..
>>>
>>>Can someone tell me if this is a bug, a lack of
optimization (I think so),
>>>or if there is something else to do ?
>>>I would personnally suggest to re-code this part
to make that the file
>>>would be uncompressed in memory the same way
than in TIFF, and then
>>>compressed again, as the resulting compression
is much better !
>>>
>>>Currently I think of doing a script which does
the conversion in two
>>>phases, but doing it directly so inside the
algorithm would be great !
>>>
>>>Here is the jpg source file I used, in 1600x1200
pixels:
>>>http://w
ww.edenpics.com/pub/bugs/001-001.jpg
>>>
>>>This is the resulting file when converted
directly from jpg to a resized
>>>jpg using the comand: 'convert -geometry
1024x768 -quality 82 -strip
>>>001-001.jpg 001-001b.jpg:
>>>http://
www.edenpics.com/pub/bugs/001-001b.jpg
>>>
>>>Here is the converted file when first converting
from jpeg to TIFF with
>>>'convert 001-001.jpg 001-001tiff.tif'
>>>http
://www.edenpics.com/pub/bugs/001-001tiff.tif
>>>
>>>Here is the converted file from this last TIFF
to jpeg resized using the
>>>command: 'convert -geometry 1024x768 -quality
82 -strip 001-001tiff.tif
>>>001-001d.jpg'
>>>http://
www.edenpics.com/pub/bugs/001-001d.jpg
>>>
>>>I am using ImageMagick V6.0.7.1-14 running on
CentOS 4.3.
>>>
>>>Please make some tries and tell me what you
think.
>>
>> You may be seeing the result of truncating the
precision to 8
>> bits per color sample when converting to TIFF,
compared to working
>> with 16-bit samples when converting from JPEG to
JPEG.
>>
>> Does the Q8 ImageMagick binary behave the same way?
>>
>> Glenn
>
>Hello, Glenn.
>
>I don't know how to use the 'Q8 ImageMagick' binary,
and what it is exactly.
>Also, can I force that with a setting parameter passed
to 'convert' command
>line so that it would directly convert and work in 8
bits instead of 16 ?
>I tried '-depth 8', but this doesn't change anything
to the result, the file
>size is the same than without it.
>
>Most probably this is an important thing to take into
account, as it could
>reduce by more than 30 % the resulting size, which would
bring a good added
>value to ImageMagick.
>
I experimented with your files using the latest version of
IM (6.2.8-4),
with a Q8 build. I reproduced your results, more or less
(the TIFF-JPEG
conversion crashed so I used PPM as the intermediate format
instead).
The direct JPEG-JPEG conversion was 323,888 bytes while the
JPEG-PPM-JPEG
conversion was 255,439 bytes. Running "identify
-verbose" on both
output JPEGs reveals that the directly-converted file has
sampling factors
of 1x1,1x1,1x1 while the jpeg-ppm-jpeg-converted file has
sampling factors
of 2x2,1x1,1x1. Running
convert -geometry 1024x768 -quality 82 -sampling-factor 2x2
-strip 001-001.jpg 001-001e.jpg
results in a file with 225,439 bytes, identical to the
jpeg-ppm-jpeg result.
The reason the conversions use different sampling factors is
that the
default is 2x2 but your original file has 1x1. In the
direct conversion
the 1x1 sampling factor is preserved while when converting
to an intermediate
format the sampling factor setting is lost and IM reverts to
its default.
Glenn
_______________________________________________
Magick-developers mailing list
Magick-developers imagemagick.org
http://studio.imagemagick.org/mailman/listinfo/m
agick-developers
|
