[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]

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.
>
> GSR
>  
>   
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?

joeedh