Two screenshot problems

[snibgo]

An old version of Gimp (2.6.8, 2008) doesn't give me the option to ignore the offsets; it just warns me about them. But it seems to process them correctly: I can zoom out or "Image | Fit canvas to layers".

So your file is usable in Gimp 2.6.8 and 2.8.2. Perhaps it is unusable in older versions of Gimp. If so, the solution would be to upgrade.

[aeb]

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.

Yes. You have to either ignore offsets or to fit canvas to layers. In other words, you have to get rid of the offsets that import added. It would have been better had import never added them.

[snibgo]

So, if I understand correctly, there is no offset bug in either IM or Gimp, but you want to change the default behaviour to save yourself the effort of "+repage", even though this can break many existing scripts?

I can see the point in, for example, an environment variable that tells IM never to add offsets. That wouldn't create problems for existing users. But changing the default behaviour shouldn't be done lightly.

[aeb]

So, if I understand correctly, there is no offset bug in either IM or Gimp, but you want to change the default behaviour to save yourself ...

You do not understand correctly. (And ad hominem talk is never fruitful.)
Gimp is broken. (The old gimp was just broken - it creates a layer and places the image outside. The new gimp has a dialog that asks whether one wants the broken behavior, and one can answer no. In noninteractive use gimp is always broken.)
IM itself is not broken here. It adds nonstandard (vpAg) and semistandard (oFFs) chunks to its PNG output, and that should be ok, since the theory is that utilities that do not understand such chunks ignore them. But gimp does not understand them and does not ignore them either. That makes it unfortunate that import adds these fields.
There is also the unexpected effect that a screenshot saved as JPG should have very different visual content from the same screenshot saved as PNG.

[snibgo]

My apologies -- I'm not trying to attack anyone. I am trying to understand why you want this change, and why "+repage" doesn't solve the problem.

As far as I can see, "+repage" does what you want. I understand that you would like this to be the default. Can you see what problems this would cause?

[aeb]

Can you see what problems this would cause?

Yes, things would work out-of-the-box. Unheard of.

[More seriously - one can discuss usability versus compatibility with previous mistakes.
There is no clearcut answer. "Foo --avoid-bug1 --avoid-bug2" is acceptable in Makefiles
or other contexts where humans do not have to type this. For direct human command-line use
one hopes that the defaults work well.]

(I mentioned two problems: a major one: import output is often totally unusable because of black rectangles over the image,
and a minor one: when saved as PNG there is an unfortunate offset. The advantage of the major problem is that nobody
who encounters this same problem will have scripts using import.
As a side remark: if I set ximage_info->descend = 0 in xwindow.c:XImportImage, the black rectangles disappear. Will investigate further.)

[aeb]

Will investigate further.

OK. For me the following diff

--- ImageMagick-6.8.0-6/wand/import.c 2011-12-19 02:54:26.000000000 +0100
+++ ImageMagick-6.8.0-6a/wand/import.c 2013-01-10 00:21:19.000000000 +0100
@@ -381,7 +381,7 @@
image_info->density=XGetResourceInstance(resource_database,GetClientName(),
"density",(char *) NULL);
resource_value=XGetResourceInstance(resource_database,GetClientName(),
- "descend","True");
+ "descend","False");
ximage_info.descend=IsMagickTrue(resource_value);
resource_value=XGetResourceInstance(resource_database,GetClientName(),
"frame","False");
[sorry - whitespace is lost here]

solves the problem of black rectangles over the screenshot. This is the enquiry of the XResources
about whether a recursive descent is needed, and this tiny patch changes the default from Yes to No.
Later XImportImage is called, and it will change this to Yes in the cases where it determines that the descent is actually needed.
The screendump is from XGetWindowImage, but it does not always correctly determine which window is on top,
so it is better to avoid the descent if possible.
The stacking order comes from XQueryTree. I have not investigated why/when that gives incorrect information.

[aeb]

The screendump is from XGetWindowImage, but it does not always correctly determine which window is on top,

Fixed that. For the patch, see the webpage mentioned in the first post of this thread.

[magick]

We'll get the patch into the next point release of ImageMagick. Thanks.

[anthony]

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.

From a non-PNG (or other specific format) point of view...

Imagemagick does not limit offsets or virtual canvas to any specific relationships. To do so would limit image processing. It does not happen often, in the normal processing of images unless uses are doing 'interesting things' with offsets. But it is left up to the user to ensure that the offsets are what is expected by other programs, in the FINAL image generated.

Specifically....

Virtual Canvas go from the origin (0,0) to the size specified. However offsets can be any value within IM. Including negative values.
As such images can be placed far outside any virtual canvas. But for image with negative offsets, the virtual canvas can not be expanded to even cover the images position, as it is limited to always starting from 0,0.

I myself make use of negative offsets, and have even added "-layers merge" to allow the merger of layer images that contain negative offsets to create a new layer image, with a negative offset!!!! It makes it a lot easier to do programmed positioning of images, but as I mention often in examples, in the end you much 'fix' the negative offset for the final result (either by cropping, repositioning, or removing the offset).

See IM Examples, Layering Images, Merging Images
http://www.imagemagick.org/Usage/layers/#merge


However on further reading it is clear that the problem is with the source of negative offsets. Screen Capture.
I would be interested in why they were generated in the first place.

[anthony]

Refering back to the original web page link...
http://www.win.tue.nl/~aeb/linux/misc/i ... nshot.html

The way I myself take interactive screen shots is using XV.

Yes XV is a very old program and difficult to find with all the patches applied (including a couple I myself created), but I still find it more useful than a lot of the more modern image viewers.

[aeb]

The way I myself take interactive screen shots is using XV.

Bad for you - xv is commercial, unmaintained since 1995 or so, has hundreds of patches found all over the net, and nothing happens because of license problems. On the other hand, IM has its own interactive screenshot tool, called import. It has its problems, but these can be fixed.
The fact that import with mouse selected rectangle produces a PNG image that is handled badly by GIMP is fixed by

Code: Select all

diff -ur ImageMagick-6.8.1-9/magick/xwindow.c ImageMagick-6.8.1-9a/magick/xwindow.c
--- ImageMagick-6.8.1-9/magick/xwindow.c        2012-12-07 14:14:16.000000000 +0100
+++ ImageMagick-6.8.1-9a/magick/xwindow.c       2013-01-11 15:39:45.000000000 +0100
@@ -5071,6 +5061,12 @@
               (size_t) window_name.nitems+1);
           (void) XFree((void *) window_name.value);
         }
+      if (image != (Image *) NULL)
+        {
+          /* forget that this was part of a larger image */
+          image->page.width = image->page.height = 0;
+          image->page.x = image->page.y = 0;
+        }
     }
   if (ximage_info->silent == MagickFalse)
     {

(Your line numbers may differ.)

[anthony]

Do you really want to forget where the PNG was cropped from?

[magick]

ImageMagick requires the image offset for virtual canvases. In the mean-time, if a user does not want it, they can use +repage.

[aeb]

Do you really want to forget where the PNG was cropped from?

Yes. That that information is present is more or less an artifact of the present code. For example, a screenshot of a window does not have the offset information, that info is present only for handselected rectangles. It follows that there are no scripts that can use that information - often it is absent. Additional information that nobody asked for may be useful in unknown unanticipated circumstances. But now that it is known that it causes problems, that it harms the usability of the import utility, it is clear that it would be better for import not to write this nonstandard information into the PNG file.