Wiretap (Read Only)
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

problem with 12bit unpacked, linux originated material

13 REPLIES 13
Reply
Message 1 of 14
alatteri
914 Views, 13 Replies

problem with 12bit unpacked, linux originated material

Make SMPTE 75% Bars with softness of 2 with a bit depth of 12 Unpacked. Resolution doesnt matter here.
If made on Linux the result in the Flame UI is fine, but the data wiretap is giving has artifacting (look at attachment).
Notice the artifacting at the color seams.
If i create this same file on SGI Flame 9.5.13 and access via the same tools the result is fine. If i then do a file archive of that file and load it into Linux machine, and access with the same tools, the result again is fine. We have not only tested this with our Quicktime technology, "Tether", but we have also done raw data dumps without any translation and expirienced the same results. I have tested this against multiple Linux machines, IBM and HP, Flint & Flame between several different locations. I have yet to test this with SGI 2007.
13 REPLIES 13
Message 2 of 14
alatteri
in reply to: alatteri

On SGI Flame 9.5.13 i have created 2 SMPTE 75% clips, one with Softness of 2 the other 4.
I exported each frame as a 16 Bit SGI image.
I then used my tool, Tether, to link to the stonefs clip on the mac. I brought the corresponding SGI image and tether clip into Combustion and did a difference matte between each with a 0 Tolerance setting. There was not even a 1 point difference in values on even a single pixel. Absolutely data identical. I then archive the 2 SMPTE clips to File and imported into Linux 2007.SP1. Ran same test, again not even a single pixel difference.

I then ran the same tests based off of SMPTE 75% clips that were generated from within Linux, these were also exported as 16bit SGI images for use in the difference. Here is were all the problems arise. Massive artifacting at color seams, but overall there is a luminance shift also. So not only are the resulting Linux clips being spit out from Wiretap with artifacts, but they dont even match the SGI Image export of themselves.


I have attached a zip that includes the 4 SGI Images (2 FlameSGI SMPTE and 2 FlameLINUX SMPTE) and a Flame File Archive of the corresponding stonefs clips.
Message 3 of 14
grattor
in reply to: alatteri

Hi Alan,

It turns out this is an endianness issue. Linux data bit-order is little endian and SGI data bit-order is big endian. Your image conversion process is assuming big endian all the time -- which is why data from Linux is being misinterpreted.

To be clear: the data issuing via Wiretap (SGI-Linux) is raw data passed through without *any* changes. You'll just have to ensure that the image conversion process you're feeding it into is detecting the endianness of the incoming data and react accordingly.

I must admit, I am explaining stuff I don't really understand. But your developers should be able to make sense of this.
Message 4 of 14
alatteri
in reply to: alatteri

But what is confusing me is that clips created on SGI but transfered to Linux are fine. So if it is an endian issue why wouldn't any clip that lives on a Linux stonefs have that also? There is no way to tell if a clip was created on SGI when on a Linux stonefs or vice versa.
Message 5 of 14
grattor
in reply to: alatteri

Prolly good for Dan to step in here... but I think it has something to do with the fact that the data is generated on the SGI, and a Wire transfer doesn't affect the data.

If you loaded the transferred clip to the desktop on Linux and processed a zero-value CC, *that* result would be screwy.
Message 6 of 14
alatteri
in reply to: alatteri

right. my concern is in a mixed environment, how are we going to now the origins of a clip? Is there an endianess indication embedded within a clip somewhere?
Message 7 of 14
Anonymous
in reply to: alatteri

The endianness is visible in the format tag of the WireTapClipFormat:

"rgb" and "rgb_le" denote big and little-endian respectively. If different data comes out of different servers with the SAME format tag, then we have a bug. A simple binary diff will do the trick to verify.

Aside, image export is not really a valid test/comparison since most image formats impose an endianness regardless of platform.
Message 8 of 14
alatteri
in reply to: alatteri

"If you loaded the transferred clip to the desktop on Linux and processed a zero-value CC, *that* result would be screwy."

I loaded a Linux clip into SGI Flame 2007 and ran thru CC with no values, the resulting clip is still being reported as rgb_le with your tools and exhibits the same issues as the origin of this thread.
Message 9 of 14
alatteri
in reply to: alatteri

Attached are dump frames for material created and loaded into both sgi and linux with the accompanying get_format_info.
Message 10 of 14
alatteri
in reply to: alatteri

milky-way:~ alatteri$ diff /Users/alatteri/Desktop/dumps/linux_on_linux.dump /Users/alatteri/Desktop/dumps/linux_on_sgi.dump
milky-way:~ alatteri$ diff /Users/alatteri/Desktop/dumps/linux_on_linux.dump /Users/alatteri/Desktop/dumps/linux_on_sgi_thru_cc.dump
milky-way:~ alatteri$ diff /Users/alatteri/Desktop/dumps/sgi_on_linux.dump /Users/alatteri/Desktop/dumps/sgi_on_sgi.dump
milky-way:~ alatteri$ diff /Users/alatteri/Desktop/dumps/linux_on_linux.dump /Users/alatteri/Desktop/dumps/sgi_on_linux.dump
Binary files /Users/alatteri/Desktop/dumps/linux_on_linux.dump and /Users/alatteri/Desktop/dumps/sgi_on_linux.dump differ
milky-way:~ alatteri$ diff /Users/alatteri/Desktop/dumps/linux_on_sgi.dump /Users/alatteri/Desktop/dumps/sgi_on_sgi.dump
Binary files /Users/alatteri/Desktop/dumps/linux_on_sgi.dump and /Users/alatteri/Desktop/dumps/sgi_on_sgi.dump differ
milky-way:~ alatteri$ diff
Message 11 of 14
Anonymous
in reply to: alatteri

Hi Alan,

Please just look at the format tag instead of sending us these big attachments. Much easier for all involved.

Dan
Message 12 of 14
Anonymous
in reply to: alatteri

If one clip is rgb and the other is rgb_le, and your pixel loops only handle one endianness, then you have your answer.
Message 13 of 14
grattor
in reply to: alatteri

Hmmm. So maybe I made an incorrect assumption there... sorry.
Message 14 of 14
panisset
in reply to: alatteri

Something important to keep in mind when accessing 12 bit images in Wiretap (big endian or little endian) is that Flame makes absolutely no guarantees about the contents of the 4 least significant bits of each color component. In the best case, when a processed image was read straight from the frame buffer and written to disk, it will contain a copy of the 4 most significant bits, which gives you the correct scaling from 12 to 16 bits: 0x000 maps to 0x0000, 0xfff maps to 0xffff. But in most cases, those bits could be all zero, all one, or it could encode your SSN and credit card numbers. If you are going to pass this data to an application which expects valid 16 bit components, you will need to copy the 4 most significant bits of each color component into the 4 least significant bits (this is what the flame image export code does when exporting 16 bit images).

If this is not in the Wiretap documentation, it should be...

JF

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report