ICML Writer: Image object does not fit to frame

[ksesong]

Given an image set up using the following markdown string ![](./test.png){width=15cm}, the resulting icml file does not create an image object that fits to the frame, here is a screenshot in InDesign:

(The brown rectangle corresponds to the image object, and the blue one to the image frame.)

I have copied the test files onto a dedicated repository ksesong/pandoc-image-fitting, with the icml file compiled from pandoc 2.11.2. The problem is not specific to this particular image file, and I've tried various width units for the same effect.

[jgm]

I see, so the dimensions are applied to the frame, but the image itself is not changed?
@mb21 may be able to comment.

[ksesong]

Yes, the scaling of the image does not fit the frame, sometimes the image is smaller than the frame (as in the example), sometimes it is bigger, but I haven't managed to identify a pattern.

[mb21]

@ksesong I think I've fixed this with #6946... testing certainly welcome...

@jgm seems he needs to build from source, or wait until we merge it and test the nightly build? as https://github.com/jgm/pandoc/actions/runs/417415033 doesn't have any artifacts...

[jgm]

I've merged, so there should be a nightly available tomorrow.

[ksesong]

I have tried the master version, and it mostly works. Some rare images of my set remain problematic. I've tried to find out why most images did fit properly and some don't, but I couldn't find a reason.

I thought these images were invalid, but pandoc hasn't raised any warning, and jpeginfo hasn't detected any anomaly, and they could be opened as normal with an image editor. I finally tried to re-save these images, and this solved the fitting. I have included one problematic image in the repository, so you may want to have a look.

[jgm]

I don't see what could be problematic about this image.
Pandoc calculates the following size for it: if this is wrong, that may be the issue.

ImageSize {pxX = 850, pxY = 1026, dpiX = 143, dpiY = 143}

The dpi of 143 is a bit odd. Interestingly, macos Preview says the dpi for this image is 144. So maybe pandoc has an off-by-one-error?

[ksesong]

The invalid image is this one, not the screenshot that I included in the comment (which is valid). Sorry for the confusion.

[mb21]

The problem seems indeed to be in jpegSize:

for test-2:

ImageSize {pxX = 72, pxY = 72, dpiX = 72, dpiY = 72}

for test-2-resave.jpg (which is after resaving the file in Photoshop and which seems correct):

ImageSize {pxX = 2189, pxY = 1247, dpiX = 72, dpiY = 72}

[jgm]

Wait, I thought the problematic image was the one displayed above -- which is a png.

[jgm]

But I can confirm the results you're seeing for image-size on the jpg from test-2.
That is wrong.

[jgm]

This is an exif file. exifHeader in ImageSize returns a default size when the exif header doesn't contain ExifImageWidth or ExifImageHeight entries. That is what is happening here -- there may be a bug in this function.

[jgm]

numentries is 0 in this header (the way we're parsing it).

[jgm]

Since we depend on JuicyPixels anyway, I'm going to try changing ImageSize to use its metadata parsing instead of doing my own binary parsing.

[ksesong]

All my images now work with the master version, thanks for the fixes.

[ksesong]

I have reviewed more images, and I have identified one regression, an image that fitted correctly after #6946, and no longer fits now. Re-saving the image did not solve the issue however.

The image is question is test-3.jpg.

[jgm]

For test-3.jpg, pandoc's imageSize calculates

ImageSize {pxX = 4608, pxY = 3456, dpiX = 350, dpiY = 350}

Is this incorrect?
Apple's preview Inspector says: 4537x2539 pixels with a dpi 350. The small discrepancy is odd.

[ksesong]

pandoc's imageSize is incorrect. Apple's Preview Inspector, Photoshop, Firefox, or Chrome all say 4537x2539. (I don't know how to compute the dpi.)

[mb21]

hm... even:

jpeginfo test-3.jpg 
test-3.jpg 4537 x 2539 24bit Exif  N 6625100 

[jgm]

Prior to the change to using JuicyPixels, with our old hand-band bit twiddling, we got:

Right (ImageSize {pxX = 4537, pxY = 2539, dpiX = 350, dpiY = 350})

So this is indeed a regression, and possibly a bug in JuicyPixels.
Before reporting it, it would be good to look carefully at the file to see what is going on.

[jgm]

Here is the full metadata as returned by JuicyPixels:

[Exif TagOrientation :=> ExifShort 1,Description :=> "OLYMPUS DIGITAL CAMERA\NUL"
,Exif TagModel :=> ExifString "E-M5            \NUL"
,Exif TagLightSource :=> ExifShort 0
,Exif (TagUnknown 41985) :=> ExifShort 0
,Exif (TagUnknown 41986) :=> ExifShort 0
,Exif (TagUnknown 41987) :=> ExifShort 0
,Exif (TagUnknown 41990) :=> ExifShort 0
,Exif (TagUnknown 41991) :=> ExifShort 0
,Exif (TagUnknown 41992) :=> ExifShort 0
,Exif (TagUnknown 41993) :=> ExifShort 0
,Exif (TagUnknown 41994) :=> ExifShort 0
,Exif (TagUnknown 34864) :=> ExifShort 1
,Exif (TagUnknown 40961) :=> ExifShort 1
,Exif (TagUnknown 34850) :=> ExifShort 2
,Exif (TagUnknown 41728) :=> ExifUndefined "\ETX"
,Exif (TagUnknown 37383) :=> ExifShort 5
,Exif TagFlash :=> ExifShort 24
,Exif (TagUnknown 41989) :=> ExifShort 24
,Exif (TagUnknown 34855) :=> ExifShort 200
,Exif (TagUnknown 33434) :=> ExifRational 1 160
,Exif (TagUnknown 33437) :=> ExifRational 50 10
,Exif (TagUnknown 36867) :=> ExifString "2013:06:11 14:57:49\NUL"
,Exif (TagUnknown 36868) :=> ExifString "2013:06:11 14:57:49\NUL"
,Exif (TagUnknown 37377) :=> ExifSignedRational 7321928 1000000
,Exif (TagUnknown 37378) :=> ExifRational 4643856 1000000
,Exif (TagUnknown 37380) :=> ExifSignedRational 0 10
,Exif (TagUnknown 37381) :=> ExifRational 925 256
,Exif (TagUnknown 37386) :=> ExifRational 12 1
,Exif (TagUnknown 37510) :=> ExifUndefined "\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL                                                                                                                     "
,Exif (TagUnknown 41988) :=> ExifRational 100 100
,Exif (TagUnknown 42034) :=> ExifNone
,Exif (TagUnknown 42036) :=> ExifString "OLYMPUS M.12-50mm F3.5-6.3\NUL\NUL\NUL\NUL\NUL\NUL"
,Exif (TagUnknown 40965) :=> ExifLong 1616
,Exif (TagUnknown 40963) :=> ExifLong 2539
,Exif (TagUnknown 40962) :=> ExifLong 4537
,Exif (TagUnknown 37121) :=> ExifUndefined "\SOH\SOH\SOH\SOH"
,Exif (TagUnknown 40960) :=> ExifUndefined "0000"
,Exif (TagUnknown 36864) :=> ExifUndefined "0000",Width :=> 4608,Height :=> 3456
,Exif (TagUnknown 50341) :=> ExifUndefined "PrintIM\NUL0300\NUL\NUL%\NUL\SOH\NUL\DC4\NUL\DC4\NUL\STX\NUL\SOH\NUL\NUL\NUL\ETX\NUL\240\NUL\NUL\NUL\a\NUL\NUL\NUL\NUL\NUL\b\NUL\NUL\NUL\NUL\NUL\t\NUL\NUL\NUL\NUL\NUL\n\NUL\NUL\NUL\NUL\NUL\v\NUL8\SOH\NUL\NUL\f\NUL\NUL\NUL\NUL\NUL\r\NUL\NUL\NUL\NUL\NUL\SO\NULP\SOH\NUL\NUL\DLE\NUL`\SOH\NUL\NUL \NUL\180\SOH\NUL\NUL\NUL\SOH\ETX\NUL\NUL\NUL\SOH\SOH\255\NUL\NUL\NUL\STX\SOH\131\NUL\NUL\NUL\ETX\SOH\131\NUL\NUL\NUL\EOT\SOH\131\NUL\NUL\NUL\ENQ\SOH\131\NUL\NUL\NUL\ACK\SOH\131\NUL\NUL\NUL\a\SOH\128\128\128\NUL\DLE\SOH\129\NUL\NUL\NUL\NUL\STX\NUL\NUL\NUL\NUL\a\STX\NUL\NUL\NUL\NUL\b\STX\NUL\NUL\NUL\NUL\t\STX\NUL\NUL\NUL\NUL\n\STX\NUL\NUL\NUL\NUL\v\STX\248\SOH\NUL\NUL\r\STX\NUL\NUL\NUL\NUL \STX\214\SOH\NUL\NUL\NUL\ETX\ETX\NUL\NUL\NUL\SOH\ETX\255\NUL\NUL\NUL\STX\ETX\131\NUL\NUL\NUL\ETX\ETX\131\NUL\NUL\NUL\ACK\ETX\131\NUL\NUL\NUL\DLE\ETX\129\NUL\NUL\NUL\NUL\EOT\NUL\NUL\NUL\NUL\NUL\NUL\t\DC1\NUL\NUL\DLE'\NUL\NUL\v\SI\NUL\NUL\DLE'\NUL\NUL\151\ENQ\NUL\NUL\DLE'\NUL\NUL\176\b\NUL\NUL\DLE'\NUL\NUL\SOH\FS\NUL\NUL\DLE'\NUL\NUL^\STX\NUL\NUL\DLE'\NUL\NUL\139\NUL\NUL\NUL\DLE'\NUL\NUL\203\ETX\NUL\NUL\DLE'\NUL\NUL\229\ESC\NUL\NUL\DLE'\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\EOT\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\ENQ\ENQ\ENQ\NUL\NUL\NUL@@\128\128\192\192\255\255\NUL\NUL@@\128\128\192\192\255\255\NUL\NUL@@\128\128\192\192\255\255\ENQ\ENQ\ENQ\NUL\NUL\NUL@@\128\128\192\192\255\255\NUL\NUL@@\128\128\192\192\255\255\NUL\NUL@@\128\128\192\192\255\255\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL",Software :=> "Adobe Photoshop CC (Macintosh)\NUL"
,Exif TagMake :=> ExifString "OLYMPUS IMAGING CORP.  \NUL",Format :=> SourceTiff,DpiX :=> 350,DpiY :=> 350

[jgm]

We can see the correct width and height here:

,Exif (TagUnknown 40963) :=> ExifLong 2539
,Exif (TagUnknown 40962) :=> ExifLong 4537

and the one we are getting comes from

Width :=> 4608,
Height :=> 3456

Looking up the exif tag codes:

40963 = 0xA003 = ExifImageHeight
40962 = 0xA002 = ExifImageWidth

[jgm]

Clearly in this case need to be using the ExifImageHeight/Width instead of the things JuicyPixel identifies as Width and Height. (But where are those numbers coming from?)

[jgm]

OK, though I'm still not sure where the Width and Height identified by JuicyPixels are coming from, I've worked around this, by checking first for the Exif tags. I think this should work fine for both exif and other images, but of course further testing is welcome!

[ksesong]

I confirm that this is now working for all the images I have in hand.

[ksesong]

I have another edge case.

When using .svg files that do not have an explicit width and height attribute, but a defined viewBox, the fitting is incorrect with the error: [WARNING] Could not determine image size for './test-5.svg': could not determine SVG size.

This example image was created using Adobe Illustrator's "Export for Screens..." function, so this is a relatively frequent situation.

[jgm]

@ksesong why don't you open a new issue for this.
The issue can note that the imageSize function from Text.Pandoc.ImageSize fails in this case, and link to the svg.