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 ...

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 ...

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 ...

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 ...

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 ...

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 ...