[ptx] Re: [PanoTools-devel] Further updates to panotools for 64 bit platforms

[douglas wilkins]

--- Fulvio Senore <mailing at fsoft.it> wrote:
> 
> 
> douglas wilkins ha scritto:
> 
> >The only other change that I wanted to make was to
> >convert from signed to unsigned data types for
> image
> >dimensions i.e. increase maximum pixel dimensions
> from
> >~32000 to ~64000
> >Unfortunately that would have meant breaking binary
> >compatibility, especially on the windows platform
> >where most people merely install the pano12.dll.
> Any
> >suggestions? Leave as is? Create pano13.dll?
> anything
> >else?
> >
> >All comments welcome :-)
> >  
> >
> Douglas,
> 
> moving to unsigned ints seems to me a very
> short-term improvement: I am not sure that it is
> worth doing it, since you will need to add a new 
> api set.
> Maybe it is better to think about moving image
> dimensions to long integers. It will surely require 
> more work, but it seems to me a long term solution.
> 
> Fulvio Senore

Hi there,
First off I must make a big apology. I wasn't thinking
clearly: 
INT32_MAX  = 2147483647
UINT32_MAX = 4294967295

So pixel dimensions are not the issue (he says, very
embarrassed)

The issue is offsets into files. I am thinking
specifically about TIFF, but JPEG and PNG as far as I
know have the same issue. Using signed 32bit offsets
means that the max TIFF Size is 2 Gb, while unsigned
would mean a max size of 4 Gb. At 4 Gb, image
dimensions for a 24 bit color depth would be
~38000x38000 for a 1:1 image or ~60000x20000 for a 2:1
image which would still be reasonable for a while to
come. Note that the spec for TIFF uses unsigned 32 bit
quantities for offsets

Now, popular image formats such as jpeg, tiff and png
all use a 32bit based image format. Moving to 64 bit
would mean using non-standard extensions such as
TIFFBIG ( which is currently unimplemented but see
http://www.awaresystems.be/imaging/tiff/bigtiff.html)
or the VIPS format which is 64 bit based, but little
used outside of VIPS.

Based on the above, I thought the best improvement for
the least effort would be to go to unsigned 32 bit for
image dimensions. It would give us an immediate
doubling of maximum image size, and then as formats
such as TIFFBIG become more widely available, we would
be able to go to a max image size of 16 Tb (!!!) i.e.
32bit dimensions with 64bit offsets, without changing
the API. In fact, since memory allocations and offsets
in the code are already 64 bit, there should not be
any need to change it

Does this all make sense or am I jut rambling ? :-)))

regards,
Doug



		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com