Re: Long types in GraphicsMagick

On Thu, 4 Oct 2007, Glenn Randers-Pehrson wrote:

> At 12:29 PM 10/3/2007 -0500, Bob Friesenhahn wrote:
>>  When compiled for
>> 64-bits, the current API supports images with dimensions
>> 9,223,372,036,854,775,807 by 9,223,372,036,854,775,807, which is more
>> than most people need at the moment.
>
> Careful: an RGBA image with 32-bit samples would only have maximum
> width 1/16 of that.

In case it is not clear, the discussion is about changing the storage 
type for 'columns' and 'rows' in the Image structure, and applying 
similar updates to 'x' and 'y' parameters used for scanning rows and 
columns throughout the code.  Other than by limiting the maximum image 
dimensions (to a max of 2,147,483,647, or 4,611,686,014,132,420,609 
total pixels) there would be no other additional limitation applied. 
Since the 64-bit file offset only supports a max of 
9,223,372,036,854,775,807, constraining the dimensions does not 
actually reduce the maximally sized image which can be processed.

I don't think that properly-written user application code should care 
about this change unless there is an API function which returns a 
dimension via a user-supplied pointer.  I can't think of any such 
function at the moment.

As suggested by someone privately, the update would be handled via 
suitably named typedefs such as magick_dimension_t (unsigned dimension 
type) and magick_sdimension_t (signed dimension type).

Bob
======================================
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/