Two screenshot problems

[aeb]

The ImageMagick utility import can be used to make screenshots of part of the screen.
Problem 1: Very often this fails and produces a garbage picture, with black rectangles obscuring parts of the content.
Problem 2: When a PNG picture is successfully made, it does not satisfy the PNG standard, and gimp complains
"The PNG file specifies an offset that caused the layer to be positioned outside the image."
Screenshots and more detail on http://www.win.tue.nl/~aeb/linux/misc/i ... nshot.html

[snibgo]

I don't use import, and can't help with (1).

For (2), I expect "+repage" would solve it. Put this between the input and output files thus:

Code: Select all

convert captured.png +repage fixed.png

[snibgo]

I don't use import, and can't help with (1).

For (2), I expect "+repage" would solve it. Put this between the input and output files thus:

Code: Select all

convert captured.png +repage fixed.png

EDIT: Or, maybe, put the "+repage" in the import command instead of an explicit "convert".

[glennrp]

The ImageMagick utility import can be used to make screenshots of part of the screen.
Problem 2: When a PNG picture is successfully made, it does not satisfy the PNG standard, and gimp complains
"The PNG file specifies an offset that caused the layer to be positioned outside the image."

The oFFs chunk is not part of the PNG specification. Instead, it is specified in the PNG extensions
document, which says, "Although oFFs can specify an image placement that is partially or wholly outside the
page boundaries, the result of such placement is application-dependent."
See ftp://ftp.simplesystems.org/pub/png/doc ... 0-pdg.html

[aeb]

Thanks for the reply. (I made the same two remarks on the page linked to.)
This was not a help request. Two old bugs were reported in the hope that some
developer who knows this code actually fixes the problem, instead of posting a workaround.
I would have sent it to a bugzilla, but perhaps there is none.

[aeb]

To glennrp: clearly, it is a bug if imagemagick produces PNG images with strange offsets that gimp (and other utilities) cannot handle.
There is no motivation for these strange offsets.

[glennrp]

To glennrp: clearly, it is a bug if imagemagick produces PNG images with strange offsets that gimp (and other utilities) cannot handle.
There is no motivation for these strange offsets.

Yes of course it's a bug. But my point was that the strange offsets are compliant with the PNG specification even if they are the wrong offsets.

[aeb]

The oFFs chunk is not part of the PNG specification. Instead, it is specified in the PNG extensions
document, which says, "Although oFFs can specify an image placement that is partially or wholly outside the
page boundaries, the result of such placement is application-dependent."

Yes of course it's a bug. But my point was that the strange offsets are compliant with the PNG specification even if they are the wrong offsets.

Roughly speaking we agree. However: (i) In this case the oFFs produced by import do not specify placement outside the page boundaries (they indicate where on the original screen the selected rectangle was found), but are misunderstood by gimp. This is a gimp bug, in the sense that gimp handles PNG, as specified in the PNG specification, correctly, but is buggy w.r.t. the PNG extensions. (ii) The possibility that this might happen was perhaps not envisaged by the authors of the PNG specs, who seem to assume that chunks that are defined in an extension are either ignored or handled correctly. In the current case a major tool that correctly follows the PNG spec cannot handle PNGs with a particular type of extension chunk. As long as this is the case, other tools must avoid adding such chunks by default, doing so only when an option like +withpngoffs is given.

[glennrp]

The oFFs chunk is not part of the PNG specification. Instead, it is specified in the PNG extensions
document, which says, "Although oFFs can specify an image placement that is partially or wholly outside the
page boundaries, the result of such placement is application-dependent."

Yes of course it's a bug. But my point was that the strange offsets are compliant with the PNG specification even if they are the wrong offsets.

Roughly speaking we agree. However: (i) In this case the oFFs produced by import do not specify placement outside the page boundaries (they indicate where on the original screen the selected rectangle was found), but are misunderstood by gimp. This is a gimp bug, in the sense that gimp handles PNG, as specified in the PNG specification, correctly, but is buggy w.r.t. the PNG extensions. (ii) The possibility that this might happen was perhaps not envisaged by the authors of the PNG specs, who seem to assume that chunks that are defined in an extension are either ignored or handled correctly. In the current case a major tool that correctly follows the PNG spec cannot handle PNGs with a particular type of extension chunk. As long as this is the case, other tools must avoid adding such chunks by default, doing so only when an option like +withpngoffs is given.

The PNG encoder assumes that if "page" information is present it should be written in oFFs/vpAg chunks. It really has no way of knowing that the caller has defined them wrong and doesn't really want them. The default is *not* to write the oFFs chunk; it only writes one if one or both offsets are set nonzero. To stop writing the oFFs chunk now would lead to surprises for people who are using oFFs/vpAg to reassemble tiles, for example.

[aeb]

The PNG encoder assumes that if "page" information is present it should be written in oFFs/vpAg chunks. It really has no way of knowing that the caller has defined them wrong and doesn't really want them. The default is *not* to write the oFFs chunk; it only writes one if one or both offsets are set nonzero. To stop writing the oFFs chunk now would lead to surprises for people who are using oFFs/vpAg to reassemble tiles, for example.

In this particular case the caller (import) has not done anything wrong: its oFFs/vpAg values are correct, but including them in the picture makes the result unusable with gimp. That is why import should feed the PNG encoder with these values only when the user has asked for them.

[snibgo]

If I understand correctly, this is pretty much what happens: if the user wants the offsets, don't "+repage"; if the user does want the offsets, don't "+repage".

[aeb]

If I understand correctly, this is pretty much what happens: if the user wants the offsets, don't "+repage"; if the user doesnt want the offsets, use "+repage".

Yes, but the default is wrong. By default the user gets a picture that is unusable (in gimp). That is a bug.
Import should write (the nonstandard) oFFs and vpAg only when there is an option asking for it.

[snibgo]

When Gimp (v2.8.2 on Windows 7) opens a PNG with offsets, it gives me the option to apply them or ignore them. As far as I can see, applying them works fine.

Can you post a PNG that Gimp doesn't handle properly?

[aeb]

Can you post a PNG that Gimp doesn't handle properly?

Try http://www.win.tue.nl/~aeb/linux/misc/import/ss0.png (from the page linked to in the first post above).

[snibgo]

With that file, Gimp gives me the option to ignore or apply the offsets.

If I ignore offsets, I can see the image pixels immediately.

If I apply offsets, I see a transparent image, due to the offsets. Zooming out shows me where the real pixels are. If I then "Image | Fit canvas to layers", I can see them.

This seems reasonable behaviour. I'm struggling to see what problem you are trying to solve.

I can see that changing IM's default behaviour would save the user from either specifying "+repage" or telling Gimp to ignore offsets. But it would also break existing scripts.