XnView Software

Hi,

I am trying to load the various combinations of big and little endian, 8-bit and 10-bit, RGB, YUV4:2:2 and YUV4:4:4 files.

From what I have tested against the SMPTE 268M-2003 DPX 2.0 spec. it seems that the formats that display correctly in XnView are:-
RGB (format 50) little endian 8-bit
RGB (format 50) little endian 10-bit
RGB (format 50) big endian 10-bit
YUV4:2:2 (format 100) little endian 8-bit
YUV4:4:4 (format 102) little endian 10-bit

It seems to me that the following big endian formats work but only if you (incorrectly) create data in the little endian format (even though the header indicates big endian)
RGB (format 50) big endian 8-bit
YUV4:2:2 (format 100) big endian 8-bit
YUV4:4:4 (format 102) big endian 10-bit

And lastly, the following do not seem to work no matter how you create the data:
YUV4:2:2 (format 100) little endian 10-bit
YUV4:2:2 (format 100) big endian 10-bit
YUV4:4:4 (format 102) little endian 8-bit
YUV4:4:4 (format 102) big endian 8-bit


Is my understanding correct as to which DPX format files currently work in XnView?

If so, are there any plans to expand the combinations of DPX format files that XnView can handle? I have an example picture in each of the formats that I can provide you with if that would help at all.

Many thanks and thanks for the great tool.

Richard.

BLZbob1 wrote: If so, are there any plans to expand the combinations of DPX format files that XnView can handle? I have an example picture in each of the formats that I can provide you with if that would help at all.

Could you send me some samples, please?

Could you send me some samples, please?

Sure. But the zip file is about 20 MBytes. Do you have somewhere I can upload it to?

Thanks.

Richard.

BLZbob1 wrote:

Could you send me some samples, please?

Sure. But the zip file is about 20 MBytes. Do you have somewhere I can upload it to?

You can use Megaupload or a server like...

You can use Megaupload or a server like...

Hi Pierre,

I have uploaded the example pictures for you and sent you a link.

Let me know if you have any questions.

Thanks for looking in to this.

Richard.

BLZbob1 wrote:

You can use Megaupload or a server like...

Hi Pierre,

I have uploaded the example pictures for you and sent you a link.

Let me know if you have any questions.

Thanks for looking in to this.

Richard.

I've checked your DPX files, but some of the big endian DPX seems to have a problem. Even graphicMagick can't correctly convert them. Which software do you use to create them?

xnview wrote:

BLZbob1 wrote:

You can use Megaupload or a server like...

Hi Pierre,

I have uploaded the example pictures for you and sent you a link.

Let me know if you have any questions.

Thanks for looking in to this.

Richard.

I've checked your DPX files, but some of the big endian DPX seems to have a problem. Even graphicMagick can't correctly convert them. Which software do you use to create them?

We created the DPX files ourselves based on the spec.
Which ones did you think were wrong?

I would say though that graphicsMagick has comments in its c-code that say that for certain formats, they don't believe what they have implemented is correct but they are handling files in that way to match what the DVS framestore unit does. See the comments at the top of dpx.c file in graphicsMagick.
We are also working with DVS to try to sort out their handling of DPX images.

But please let me know which format files you think are incorrect and I'll take another look at them.

Thanks.

Richard.

BLZbob1 wrote: We created the DPX files ourselves based on the spec.
Which ones did you think were wrong?

big_rgb_8, i have not the good RGB value
and big_422_8, big_444_8

For others files, now it's good...

Hi Pierre,

We had a conversation with the maintainer of GraphicsMagick (Bob). It seems you have discussed this DPX issue in the past.

For the benefit of others reading this message board, his particularly good assessment of the state of the DPX standard can be found here:-

http://www.simplesystems.org/users/bfri ... issues.pdf

Is my understanding correct that we agree on on the formats for all the DPX files except big_rgb_8, big_422_8 and big_444_8 and the reason for the discrepancy for those ones is due to maintaining compatibility with the de-facto standard used by Thompson (Grass Valley) and Filmlight?

If so, perhaps a checkbox in the options could select either Thompson or standard mode.

Thanks.

Richard.

BLZbob1 wrote:We had a conversation with the maintainer of GraphicsMagick (Bob). It seems you have discussed this DPX issue in the past.

Not for such format!

Is my understanding correct that we agree on on the formats for all the DPX files except big_rgb_8, big_422_8 and big_444_8 and the reason for the discrepancy for those ones is due to maintaining compatibility with the de-facto standard used by Thompson (Grass Valley) and Filmlight?

But what is the difference between big_rgb_8 & little_rgb_8????? Why i have one byte before RGB value?

Hi Pierre,

This is Q. I work with Richard (a.k.a BLZbob1). You have some questions on our big_rgb_8.dpx file format. Since I created these files, Richard asked me to write to you.

I have a document that tabulates the memory storage of the big_rgb_8.dpx format. I will send you the pdf file to the email that you gave to Richard.

But in summary, this is what we believe how to 8-bit is packed, according to DPX spec SMPTE 268M-2003. My example here is for format 50.

Step 1. Pack to 32-bit words, with earlier datum goes into lower bytes.

For rgb format 100, datum sequence is b,g,r (instead of r,g,b), therefore, in a 32-bit word, it is as follows for increasing word order.
[b1, r0, g0, b0]
[g2, b2, r1, g1]
[r3, g3, b3, r2]
...

Step 2. Write 32-bit word into memory.

In little endian, with increasing memory byte address, this is:
b0, g0, r0, b1, g1, r1, b2, g2, r2, b3, g3, r3 ...
In big endian, with increasing memory byte addree, this is:
b1, r0, g0, b0, g2, b2, r1, g1, r3, g3, b3, r2 ...

I am guessing that the extra byte you referred to in your post is b1 in front of r0, g0, b0. Let me know if this is what you meant.

Hi,

Qster0 wrote: I am guessing that the extra byte you referred to in your post is b1 in front of r0, g0, b0. Let me know if this is what you meant.

Ok, perhaps i'll check.
GraphicMagick can't convert these files