[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

Joe Eagar joeedh at gmail.com
Sat Feb 11 04:29:54 CET 2006

GSR wrote:
> 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.
Ok I get you, you mean map between the minimum and maximum zbuf values.

You're probably right, that it wouldn't work in animations.  Maybe this 
should just be a option?


More information about the Bf-committers mailing list