[Bf-committers] A contribution

Sat, 03 Jul 2004 09:44:24 +1000

See inline comment-

Dan Brown wrote:

> I can only find reference to 2 common file formats used solely for 
> depth buffers.
>
> .zpic - Output by softImage from what I can tell and importable into 
> AfterEffects, Combustion, and Photoshop. This is just a headerless 
> file of floats, 1 per pixel. I didn't find any more info than that 
> such as the range used and orientation but I will keep looking.

This format sounds cool :) very easy to impliment, could probably Make a 
cinepaint plugin in no time as well as the existing support you mention.

> .eiz - Output by ElectricImage and importable into the same apps as 
> above with plugins. I couldn't find any info at all on the file format 
> for this except that it can support multiple images for animations.
>
> The Maya (.iff) and 3ds max (.rla superceded by .rpf) formats save the 
> depth internally along with image and alpha data.
>
> That is all from Google, so it may not be 100% correct.
>
> I haven't got access to any of these apps though, so I can't try and 
> work out exactly how they work. I did fid plugins for photoshop and 
> viewers that I can use though if anyone does have one of these files 
> lying around.
>
> I will carry on looking for any specifications for both of them.
>
> For integrating into Blender, I now think that a toggleable 'save 
> zbuf' button in the Render panel would be better than adding it as a 
> new image file format that just saves the depth component. Mainly 
> because if you render an animation that takes several minutes/hours, 
> you will only need to render it once that way.

If this is the case then I think you'll need a NONE image format bacause 
it IS possible youll have a rendered animation (from a prev version pf 
blender for instance) and youll want just to render the Zbufer.
- Cam

> Dan
>
> Ton Roosendaal wrote:
>
>> Hi,
>>
>> While rendering with Blender, only the zbuffer values of  
>> non-transparent objects are stored. Also halos don't get into the  
>> zbuffer. The unified render even doesn't store a zbuffer at all.
>>
>> Further, the internal storage is with unsigned int. Converting that 
>> to  a floating point value will only lower the resolution.
>>
>> So, it's not about the best method to export, it just depends on the  
>> program that accepts zbuffer images as input. To be added to a 
>> Blender  release, we therefore best choose the format as Gimp or 
>> Photoshop or  another compositing package accepts. So what's common 
>> here?
>>
>> BTW: The IriZ format is an own invention used in NeoGeo days, to 
>> allow  usage in sequence effects. Afaik no other program uses it.
>>
>> -Ton-
>>
>>
>> On Wednesday, Jun 30, 2004, at 20:53 Europe/Amsterdam, Dan Brown wrote:
>>
>>> TIFF is just a container format, much like a .zip file but not  
>>> neccesarily compressed. It has an internal directory pointing to  
>>> 'files' inside the tiff, and one of these can be a array of 32-bit 
>>> or  64-bit floats if it is required. But it is up to the viewing  
>>> application as to what it does with those 'files' and I couldn't 
>>> find  any mention of any common software using floats or even 32-bit 
>>> per  component integers for images, only high-end apps like 
>>> Combustion. If  we can find specs for a float image file format 
>>> inside a tiff then it  is an option, otherwise it would be 
>>> proprietry to Blender as we would  need to know where it stores 
>>> things like width and height of that  buffer before other peoples 
>>> software could use it.
>>>
>>> There is no reason why a tiff handler couldn't be added to save the  
>>> depth buffer as well/instead of a seperate raw file, like the  
>>> Iris-zbuf format does now, then people have the option to use a  
>>> straight float/32-bit int file or include it in the tiff.
>>>
>>> Dan
>>>
>>> Jonathan Merritt wrote:
>>>
>>>> How about adding support for TIFF images to Blender?  Am I wrong 
>>>> in  thinking that TIFF can support color, alpha and depth channels 
>>>> (and  others...) simultaneously?  AFAIK, TIFF supports 32- and 
>>>> 64-bit IEEE  floating point pixel formats too!
>>>> It just seems a little odd to cobble an extra channel on to an  
>>>> existing image format in a non-standard way like this.
>>>>
>>>>> Campbell Barton wrote:
>>>>>
>>>>>> I think a 16 bit greyscale PNG would be the go-
>>>>>> Blender can load 16 bt png's (tho only as 8 bits for displaying) 
>>>>>> so  it wouldent be odd.
>>>>>> (Blender would be able to read the file it outputted)
>>>>>> - Cam
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://www.blender.org/mailman/listinfo/bf-committers
>>>
>>>
>> ------------------------------------------------------------------------ 
>> -- 
>> Ton Roosendaal  Blender Foundation ton@blender.org  
>> http://www.blender.org
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://www.blender.org/mailman/listinfo/bf-committers
>>
>>
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>

-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton@metavr.com
phone: AU (03) 5229 0241