Yeah, me too -- in many cases I just wanna check do a quick check, and
seeing just the upper-left corner is good enough, so I do this with
pictures up to about 3840 x 3072 pixels (that's triple my display
size in each dimension).
That is surely an unusual usage. I think it is ok
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> it would be clearer to write this:
>
> ! If the value is an integer, it directly specifies the maximum
> ! image height and width, measured in pixels. If it is a floating
> ! point number, it specifies the maximum image height and wi
I think it makes sense for some purposes to allow max image size to be
specified in absolute pixels. Here is a patch to do that:
That is ok. But instead of this text
! If its value is an integer, it specifies the absolute maximum width
! and height, in pixels, for images. If it
The max-image-size code is checked into CVS. I've set a conservative
value of 6.0 times the frame width and height.
I am concerned that that is too large. On large displays, an Emacs
frame could be 1000 pixels in each dimension. 6000 pixels on each
side is 36 million pixels. Isn't that
2005/10/18, Stefan Monnier <[EMAIL PROTECTED]>:
> My Emacs frames are typically 80 columns of 13x6, i.e. about 500 pixel wide,
> but I often (at least once a week) watch digital photos in those frames
> and more often than not those picteures are 1600 or 2048 pixel wide.
Yeah, me too -- in many ca
David Kastrup <[EMAIL PROTECTED]> writes:
> It sounds to me like the limits should be configurable, with a
> somewhat conservative default. Applications where larger dimensions
> might be appropriate (image viewers with provisions for panning, i.e.)
> can allow them in their own buffers using buf
David Kastrup <[EMAIL PROTECTED]> writes:
>> But it definitely sounds better to scale according to display size
>> rather than frame size (but round up to minimum size e.g. 4096x4096).
>
> It sounds to me like the limits should be configurable, with a
> somewhat conservative default. Applications
[EMAIL PROTECTED] (Kim F. Storm) writes:
> RMS:
>> But I don't think this limit should be absolute. I think it should be
>> specified as a multiple of the frame height and width, and it should
>> be given as a floating point number. I'd suggest 2.0 as the default
>> for this ratio.
>
> Stefan:
>>
> From: Chong Yidong <[EMAIL PROTECTED]>
> Date: Mon, 17 Oct 2005 17:56:39 -0400
> Cc: emacs-devel@gnu.org
>
> > But I don't think this limit should be absolute. I think it should be
> > specified as a multiple of the frame height and width, and it should
> > be given as a floating point number.
RMS:
> But I don't think this limit should be absolute. I think it should be
> specified as a multiple of the frame height and width, and it should
> be given as a floating point number. I'd suggest 2.0 as the default
> for this ratio.
Stefan:
> All this to say that I think choosing the maximum
>> But I don't think this limit should be absolute. I think it should be
>> specified as a multiple of the frame height and width, and it should
>> be given as a floating point number. I'd suggest 2.0 as the default
>> for this ratio.
My Emacs frames are typically 80 columns of 13x6, i.e. about
> But I don't think this limit should be absolute. I think it should be
> specified as a multiple of the frame height and width, and it should
> be given as a floating point number. I'd suggest 2.0 as the default
> for this ratio.
What frame should we then use? The selected f
> But I don't think this limit should be absolute. I think it should be
> specified as a multiple of the frame height and width, and it should
> be given as a floating point number. I'd suggest 2.0 as the default
> for this ratio.
What frame should we then use? The selected frame?
That's not re
+ #define MAX_IMAGE_SIZE 10
+ EMACS_INT Vmax_image_size;
10 as a limit of linear dimension is too large.
A square image 10-1 on each side will be 10 billion pixels,
far too large to fit in a 32 bit machine.
Such a limit should be more like 3000. (That would allow
almost 10 mil
Ok, I figured out how to do it. This patch imposes height and width
limits based on the variable max-image-size. It should cause load_gif
and the other image loading functions to return before the third-party
libraries are called upon to load the image data, so we shouldn't get
memory-overallocat
As for libpng, the png_set_user_limits() function was only added in
version 1.0.16rc1, from 2004, so if we use that we'll lose
compatibility with older versions.
I think it is ok for the new Emacs to use a feature of libpng that
is one year old. Would you like to write the code?
Perh
> At the same time, we implement image width and height limits in
> x_create_x_image_and_pixmap, to deal with malicious images that
> specify gigantic width and height sizes, even though the file size
> isn't that big.
>
> Will that succeed in handling the problem case we got?
It w
Here's another idea. We impose a limit on the size of the image file
that Emacs is willing to read, say 50 megabytes. This should be easy
to implement and independent of image type.
That might be a good idea, but it won't address this problem.
In this problem case, the file itself is
> If we handle them one by one, it won't be terribly tricky.
> We could have one limit for memory size of an image, and another limit
> for the width and height as a ratio to those of the window.
> Then for each image type it would use whichever of those can be used.
Here's another idea. We impos
For some image types, it is a simple matter of passing to the library
the limits Emacs wants to set. For libpng, we could use
png_set_user_limits() to set our maximum width/height. (libpng also has
a built-in default limit of 1 million pixels in both dimensions.)
For other li
For some image types, it is a simple matter of passing to the library
the limits Emacs wants to set. For libpng, we could use
png_set_user_limits() to set our maximum width/height. (libpng also has
a built-in default limit of 1 million pixels in both dimensions.)
For other libraries, the applica
One place where we can set a limit is in x_create_x_image_and_pixmap,
where we malloc a pixmap to store the image contents. The data
supplied to us by the external library is copied into this pixmap. We
could signal an error if width and height are too large. However,
this se
Chong Yidong wrote:
> One place where we can set a limit is in x_create_x_image_and_pixmap,
> where we malloc a pixmap to store the image contents. The data
> supplied to us by the external library is copied into this pixmap. We
> could signal an error if width and height are too large. However
Can we get this discussion going again? From FOR-RELEASE:
Put a max-limit on the size of images, e.g. based on the display
size. This is to avoid allocating insane amounts of memory due to
bogus image size specifications. Note: rather than clipping images
that are too big (this may be n
24 matches
Mail list logo
