Package graphics error division by 0

fmw42 wrote:identify -verbose says

Image: wizard.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 265×352+0+0
Resolution: 118×118
Print size: 2.24576×2.98305
Units: PixelsPerCentimeter

Ummm… I’m not sure how this ‘wizard.jpg’ file now entered the discussion? The filenames I used where only these two (plus the built-in ‘wizard:’):

fmw42 wrote:Image: wiz-300densi.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 480×640+0+0
Resolution: 300×300
Print size: 1.6×2.13333
Units: Undefined

Image: wiz-standard.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 480×640+0+0
Units: Undefined

Note that for both output images, units get undefine from pixelspercentimeter, which is odd.

As I said: a ‘wizard.jpg’ with defined pixelspercentimeter is not mine and cannot be used as the basis of an argument… However, there are still some weird facts in this story. See my more detailed results further down.

fmw42 wrote:Also the image size (Geometry) gets changed.

No, it doesn’t! Because I never used ‘wizard.jpg’ in this context.

fmw42 wrote:That should not happen, in my opinion. So something is strange here or a bug.

It must be a misunderstanding, somehow. I always used (during these tests) the built-in ‘wizard:’ image as original.

fmw42 wrote:exiftool -s -ee -g1 -u -n -D wizard.jpg
shows

— ImageWidth : 265
— ImageHeight : 352
2 ResolutionUnit : 2
3 XResolution : 118
5 YResolution : 118

This matches IM

See above about ‘wizard.jpg’…

fmw42 wrote:exiftool -s -ee -g1 -u -n -D wiz-300densi.jpg

— ImageWidth : 480
— ImageHeight : 640
2 ResolutionUnit : 0
3 XResolution : 300
5 YResolution : 300

This matches IM

Yes.

fmw42 wrote:exiftool -s -ee -g1 -u -n -D wiz-standard.jpg
shows

— ImageWidth : 480
— ImageHeight : 640
2 ResolutionUnit : 1
3 XResolution : 1
5 YResolution : 1

This does not match IM. IM identify -verbose is missing the Resolution and undefined units, which should be 0 in exiftool. So this may be where the issue comes from in addition to the size/geometry change.

It matches IM, yes. But please don’t compare to a ‘wizard.jpg’ and conclude a size/geometry change from it — see above about ‘wizard.jpg’…

fmw42 wrote:Perhaps wizard.jpg has erroneous values in it, especially with regard to the image size.

I believe IM convert or wizard.jpg has a bug/problem!

Sorry I do not have LaTex.

I created a table about the results of a series of

 'convert wizard: -density $Xx$Y wiz-$X-$Y.jpg'

with variations of values for X and Y.

But for preparation, I first looked up the JFIF documentation ( http://www.w3.org/Graphics/JPEG/jfif3.pdf ) and found on page 5 the description of these three fields in the header:

• At byte offset `0x0d` the «Units» field. This field has a 1 byte length. It can hold 3 values. The values describe *»Units of the X and Y densities»*.
  • `0`, means: «no units, X and Y describe the pixel aspect ratios».
  • `1`, means: «X and Y are dots per inch»;
  • `2`, means: «X and Y are dots per cm».
• At byte offset `0x0e` the «XDensity» field. This field has 2 bytes length. It describes the «Horizontal pixel density».
• At byte offset `0x10` the «YDensity» field. Its length is 2 bytes. It describes the «Vertical pixel density».

    +---------------+---------+-----------------+---------------------+
    |   Byte-Offset |   0x0d  |        0x0e     |        0x10         |
    +---------------+---------+-----------------+---------------------+
    |    Field-Name | "Units" |   "XDensity"    |   "YDensity"        |
    +---------------+---------+-----------------+---------------------+
    | Value/Meaning |      0  | "X and Y describe pixel aspect ratio" |
    +---------------+---------+-----------------+---------------------+
    | Value/Meaning |      1  |     "X and Y are dots per inch"       |
    +---------------+---------+-----------------+---------------------+
    | Value/Meaning |      1  |      "X and Y are dots per cm"        |
    +---------------+---------+-----------------+---------------------+

My tests involved looking at the byte values with a hex editor too, not just relying on `identify -verbose` or `exiftool`. Additionally, I also employed `file` to see what this little tool reported.

So finally, here are the results of my ‘convert wizard: -density $Xx$Y wiz-$X-$Y.jpg’ commands with variations in X and Y values. Note, I also used «odd» and maybe «illegal» values like `000`, `0.2` and `1.5` instead of only «sane» integer numbers for the density (because even for basic testing, it can never be wrong to introduce some fuzzing as well):

These results seem to suggest first of all a potential improvement for the `identify` tool:

• Change the output reported for the «Units:» field.
• Instead of reporting «Undefined» if the JFIF field in fact contains a `0`, it should report something like «0 (means: X and Y Resolution values describe pixel aspect ratio)». See also what the `file` utility reports.
• However, even if developers are not willing to improve identify’s output here and change it: at the same time there is also a bug involved. Because *sometimes* this «Undefined» is wrong: whenever `file` reports «aspect ratio» (that is, the value of JFIF header field «Units» is either `1` {dots per inch} or `2` {dots per cm}).

Some of the other results are also remarkable:

• In every single case my hex editor double checking confirmed that Exiftool’s and `file`‘s reporting and of the values are correct.
• `identify` reported nothing for the «Resolution:» of the results from those `convert` commands where I had used `-density 0.2|0.5|0.8|1.2|000|001` to create the JPEG.
• `convert -density 0.2` created a JPEG where Exiftool and hex editor see a `0x0` resolution with the real meaning of «dots per inch»), while `convert -density 0|000` created a JPEG where the same value becomes `1×1`.
• `convert -density 000` created a JPEG where Exiftool see resolution unit «inches», but for `convert -density 000×000` Exiftool sees resolution unit «None»

You can download the script here:

• https://drive.google.com/file/d/0B-hdTU … sp=sharing

It is only ~60 lines of Bash code. In the tarball included are also the log files of the script (from which I extracted above table). So if you cannot to run it yourself (you may be on Windows), then you can still look at its results.