[Bf-committers] Re: Re: [Bf-blender-cvs] CVS commit: blender/source/blender/imbuf IMB_imbuf.h blender/source/blender/include BIF_writeimage.h blender/source/blender/src header_info.c toets.c writeimage.c

[GSR]

Hi,
joeedh at gmail.com (2006-02-10 at 1956.43 -0700):
> GSR wrote:
> > Hi,
> > jesterking at letwory.net (2006-02-11 at 0308.25 +0200):
> >   
> >> The patch searches first for second highest float (= geom pixel farthest
> >> away). Then uses that to convert other float values of zbuf to nice 0-255
> >> range. Changes only writeimage.c
> >>     
> >
> > Why only max to 255 and not also min to 0, or is that given by how
> > zbuf works now? I guess that in any case the idea is for single stills
> > only, not anims.
> >   
> He means conversion to max 255 for saving as 8-bit per channel.  Does 
> anything standard like jpg or bmp or something support 16/32-bit per 
> channel floats?  I would guess not. . .

You missed the point, which is that if the zbuf for a given image has
al values in range 0.5 to 0.75 and you map 0.0 to 0, and 0.75 to 255,
you have 2/3 of the resolution wasted. That is the reason I ask if
zbuf will always have min at 0.0 or then why not map min to 0 of the
0-255. Also if the max (and maybe min) varies, it will not be so
useful for anims or 2+ picture composition, as you will have serious
headaches making things match later... or I am missing some detail
that makes the trick work for those cases too.

TIFF can do floats and PNG can do 16 bits ints.

GSR