Legacy ImageMagick Discussions Archive

Thank you!

Hello,

I got a similar bug report, see:

https://bugzilla.suse.com/show_bug.cgi?id=867943

Basically, the title (string inside parenthesis) is expected to be UTF16BE, if I understand correctly. Other way to fix would be to not write /Title at all. What do you think?

Thank you!

With 6.9.2-3, I get following read error:
This is not the case with 6.9.1-10.

http://upload.wikimedia.org/wikipedia/commons/5/57/PT05_ubt.jpeg is one of the online image that exposes the problem for me. File size indicates the issue for -quality=69,70,71,97,99,100 (only few bytes) plus md5sum indicates the issue for -quality=37,38,68,93,94,95,96. http://upload.wikimedia.org ...

But: For quality=`seq 1 100`, there's no difference in file sizes when git/cups/doc/images/smiley.jpg stands for original image (test.jpg). Today's tests was performed with IJG jpeg library as a backend. According to initial comment of this topic, there would be at least one difference (for default ...

If that would be interesting for you, I tried the differences for quality=`seq 1 100`, and I get the following. First column is quality percent and second number is file size. --- s390x.txt 2015-01-27 11:33:37.132312580 +0100 +++ x86_64.txt 2015-01-27 11:33:20.876111770 +0100 @@ -10,92 +10,92 @@ 10 ...

x86_64$ for i in 10 30 50 100; do convert test.jpg -quality $i test1.$i.jpg; ls -l test1.$i.jpg; done -rw-r--r-- 1 linux users 75854 Jan 27 11:15 test1.10.jpg -rw-r--r-- 1 linux users 153799 Jan 27 11:15 test1.30.jpg -rw-r--r-- 1 linux users 215478 Jan 27 11:15 test1.50.jpg -rw-r--r-- 1 linux users ...

Namely: original test with /usr/lib64/libjpeg.so.8.0.2 from libjpeg-turbo project on both s390x and x86_64. Second test (comment from 2015-01-22T14:32:14+01:00) was trough /usr/lib64/libjpeg.so.9.1.0 from IJG jpeg library and ImageMagick built against it (again, on both s390x and x86_64).

Yes.

Yes. The resulting files differs in file size.

Original test was performed with ImageMagick 6.8.8-1 libjpeg-turbo 1.3.1 I tested also with ImageMagick 6.8.8-1 jpeg 9a With this setup, I get smiley.jpg converted to the same image (checked with md5sum). That is not true for my original (real photo) testcase: -rw-r--r-- 1 linux users 715719 Jan 22 ...

According to jpegdump, resulting images differ in Huffman tables. $ jpegdump -v -v test1.x86_64.jpg > test1.x86_64.jpg.dump $ jpegdump -v -v test1.s390x.jpg > test1.s390x.jpg.dump $ diff -a -upr test1.{x86_64,s390x}.jpg.dump --- test1.x86_64.jpg.dump 2015-01-20 16:11:43.055645497 +0100 +++ test1 ...

x86_64$ convert test.jpg test1.x86_64.jpg x86_64$ ls -l test1.x86_64.jpg -rw-r--r-- 1 linux users 715665 Jan 22 10:27 test1.x86_64.jpg x86_64$ s390x$ convert test.jpg test1.s390x.jpg s390x$ ls -l test1.s390x.jpg -rw-r--r-- 1 linux users 715527 Jan 22 04:24 test1.s390x.jpg s390x$ For test.jpg can ...

Thanks! Sorry for this nitpicking. Maybe I am wrong, but stripping profile should not fail nor issue warning even if the profile is incorrect, no? Note from Glenn: Try putting this in readpng.c, immediately before png_read_info(): #if defined(PNG_SKIP_sRGB_CHECK_PROFILE) && \ defined(PNG_SET_OPTION ...