[Tig] Scanity in 16bit

Carl Skaff carl at stopp.se
Mon Nov 10 15:40:36 GMT 2014


yepp, this seems to be the issue

In resolve it looked wrong, but in Flame it looks correct.
And if Flame outputs a 16bit DPX is looks correct in Resolve.
So it seems as Resolve is reading the Scanity-16bit-DPX incorrectly.

/carl






--
CARL SKAFF
 COLORIST STOPP/POST PRODUCTION

 STOPP/STHLM
 ODENGATAN 104
 113 22 STOCKHOLM
 OFFICE +46 8 507 035 00

 STHLM | NYC | LA
 WWW.STOPP.SE

follow me on Instagram @colorist_carlskaff

On Mon, Nov 10, 2014 at 4:32 PM, Bob Friesenhahn <
bfriesen at simple.dallas.tx.us> wrote:

> On Mon, 10 Nov 2014, Carl Skaff via Tig wrote:
>
>>
>> Hi all
>>
>> Maybe this forum is a faster way to get support:
>>
>> I'm trying to scan in 16bit on my Scanity... but the DPX comes out in the
>> wrong "channel order".
>> Instead of the normal RGB it seems as it is BGR, I need to swap Red and
>> Blue to make it look correct.
>>
>> Any ideas?
>>
>
> The DPX 2.0 specification (SMPTE 268M-2003) is a bit unclear/ambigious and
> vendors have accidentally or intentionally produced formats which result in
> wrong channel order as compared with the DPX 1.0 specification and original
> Cineon system.
>
> Original DPX put all data in 32-bit words so the 16-bit samples would be
> packed into 32-bit words which might be big/little endian.  Due to
> interpretation (and likely influence from TIFF), Filmlight decided to
> output 16-bit DPX as a linear array of 16-bit samples rather than packed
> into 32-bit words.  This changes the apparent order.  While 16-bit DPX
> dates from the original Cineon system, a Filmlight scanner was used to
> produce the original STEM scans used as basis for DCI development, and
> 16-bit was not common before that time so Filmlight's approach has become
> the common way to store the data.
>
> I paper I wrote about the DPX 2.0 specification confusion may be found at "
> http://www.simplesystems.org/users/bfriesen/dpx/dpx-issues.pdf".
>
> Unless you can cause your scanner to output samples differently, you are
> faced with post-processing all the files (e.g. GraphicsMagick can do that)
> or hopefully telling the DPX reader to re-order the samples.
>
> Bob
> --
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>


More information about the Tig mailing list