Re: dpx file length assertion

--- Bob Friesenhahn <[email protected]>
wrote:

> Thanks for the report.  There is an issue with
> 10-bit gray DPX files 
> when the width is not evenly divisible by three. 
> The problem is that 
> the DPX specification implies that a row could then
> be split across 
> one 32-bit storage word because one 32-bit word may
> contain three luma 
> samples and one or two of them may belong to the
> next row.  Currently 
> GM cheats and pads the row out to the next 32-bit
> word.

Would this affect other formats, like rgba?

> Likewise, for 16-bit DPX, for best compatibility, it
> is advisable that 
> the width be evenly divisible by 2, and for 8-bit
> DPX, the width is 
> best evenly divisible by 4.

Scary. I assume it's easier to work in scanlines and
words though, so would it be safe to say the industry
consensus is for 32-bit alignment?

I had thought that's what the "line padding" variable
in the dpx image header was for, but it looks like
it's measured in bytes, which probably doesn't help
for the 10-bit case.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642