Legacy ImageMagick Discussions Archive

Hi,

when trying to read from the clipboard an image copied from chrome, the image scrolls horizontally a few pixels.

Without more information, this is difficult to diagnose.

What version of IM? On what platform?

What software copies from Chrome? Is that a function in Chrome?

When other software reads from the clipboard (eg paste into Paint or Gimp), does this scrolling happen?

When other non-Chrome software copies image to the clipboard, and IM reads the clipboard, does this scrolling happen?

Both IM and Chrome are updated to the latest version.
IM: 7.0.8-67
Chrome 77.0.3865.90

Microsoft Paint paste ok
Adobe Photoshop paste ok
Everybody ok except IM.


IM Convert.exe also does it wrong.

If the image is copied by Internet Explorer, Firefox or another program, IM does well.

On what platform? Eg Windows 10, some version of Mac, some version of Unix.

Perhaps Chrome puts something into the clipboard that IM is ignoring. A developer would need to reproduce the problem.

Sorry, in WIndows 10.

Windows 10 has an issue with the way it handles grayscale images in its clipboard that causes alignment problems for ImageMagick. Find a description of this problem from a couple years ago at THIS LINK. Possibly this is a related issue.

The error also happens with color images.
I have tried GraphicsMagick and it does well but I don't want to change libraries.

I love ImageMagick

There seems to be at least one ImageMagick bug here. Its clipboard handler manufactures a BMP file header, but in that header it doesn't always set the bfOffBits field correctly. I'm referring to this line in coders/clipboard.c: It ought to also add the size of the color table (for paletted images), and for BMPv3 images with compression=BI_BITFIELDS, 12 for the BITFIELDS segment.

The issue with Chrome seems like it must be the BITFIELDS part of this bug. But something doesn't make sense: It looks to me like IM would be acquiring the image in CF_DIBV5 format, while only CF_DIB format would lead to the bug. At the moment, I don't know what's going on.

Thanks for your research Jason. The code now assumes that there is no colormap so that could be an issue but I will take a look at that when that situation occurs. I just pushed a patch to fixed the issue for BMP3 (CF_DIB) images where the offset should be increased by 12. It looks like this also needs to happen for the CF_DIBV5 when the bits per pixel are 32 bit but I don't understand why.

Any solution?

As stated before I have no clue why this happens so I cannot fix this at this time.