Legacy ImageMagick Discussions Archive

Hello,

I obtained 12bit video frame and padded big endian DPX header. ( Using DVS Atomix board and their SDK )
So, if the content is in little endian, it should be displayed incorrectly.

However, ImageMagick displayed such image visually correctly while XnView displayed corrupted image.
With 10 bit DPX case, I found out that DVS's SDK manipulated "method A" and "method B" case wrongly. I mean, they define a macro for method B, but it was actually method A.
So, I think there is a possibility that they also did mistake for 12bit little endian and big endian format.
In other words, although I used "little endian" data with big endian header, if how ImageMagick displays is right, the data is actually in "big endian" format. Then, ImageMagick is right, DVS is wrong and XnView is wrong.

I would like to provide a screenshot, but this message board doesn't allow uploading an image files. Is there a way for me to upload the images and embed here?

OK. I just put a link to my picasaweb photo album

https://picasaweb.google.com/1081215374 ... 011082602#

You will have to find a free image hosting web site (there are plenty of them --- search Google). Upload your image to the free site. Then put a link to your image here in this forum.

Thank you for having interest in this issue.

I uploaded file to FileFactory.

The link is : http://www.filefactory.com/file/cd5c6b3 ... images.zip

If you scroll down, you will find "Slow download". If you click that and provide some captcha code, after a few seconds, it will display a download button.

The 12bit DPX images are all in "packed" format not "method A" or "method B".

Thank you.

We're using ImageMagick 6.7.2-1 and SV_MODE_NBIT_12BDPXLE___SV_MODE_COLOR_RGB_RGB.dpx (1) appears to render properly. ImageMagick reads the SV_MODE_NBIT_12B___SV_MODE_COLOR_RGB_BGR.dpx (2) header properly and it has the same values as (1). However, the pixel data appears corrupt for (2). We follow the DPX standard as closely as possible although it includes ambiguous sections regarding endian rules. Our current understanding is that (2) does not follow the DPX standard. If you can prove otherwise we will investigate further.

Thank you for the investigation.

Yesterday DVS people said that 12BDPXLE ( for little endian ) was wrong and it actually generates DPX files in big endian format. They provided updated SDK.
So, the one named as 12BDPXLE is actually in big endian format.

Thanks for checking it.
I also contacted XnView developer. He said that people can interpret the standard differently.
Anyway, things are a little clearer. At least I found bugs in DVS's SDK and their behavior.

Thank you.