How would I deal with 10-bit-integer?

[Sonhospa]

Ciao Moreno, thanks for your support:thumbsup:. I've just sent you some stuff to the address at stasnc, hoping that's correct. The code and link to the file specification is also part of my original post. I'm really looking forward to hearing from you! Regards Michael

[Moreno Airoldi]

Hi Michael, Getting your stuff just now, I'll have a look at the code and will let you know. :)

2+2=5 for very large amounts of 2 (always loved that one hehe!)

[Moreno Airoldi]

I had a first look at the stuff, and I sure see one problem, which as you thought is related to the Format24bppRgb format. This format requires three Bytes for each pixel (red, green, blue), while you provide three UInt32. Try to make your RGBArray a Byte array, and you'll probably be done. I'll have a deeper look anyway, and see if what I said is ok and if there's anything else to fix. :)

2+2=5 for very large amounts of 2 (always loved that one hehe!)

modified on Friday, August 7, 2009 6:16 AM

[Sonhospa]

Thanks for looking - I just came home from work and changed what you suggest. :thumbsup: The result is an overflow exception in the lines "RGBArray(i) = (buff And &H3FF)" etc., in which I then try to put a 10-bit value (held in buff which is UInt32, right?) into a single byte (8 bits). How would I correctly downconvert the result of the line into a byte? My silly approach to return 8/10th of course lead to an overflow exception, too... BTW: I hope you had enough other stuff to do today and didn't drown in all the possibilities to fix

[Moreno Airoldi]

In order to convert your 10 bits values to 8 bits, you must simply lose the two least significant bits (which is the same as dividing the value by 4):

RGBArray(i) = (buff And &H3FF) >> 2;
RGBArray(i + 1) = (buff And &HFFC00) >> 12;
RGBArray(i + 2) = (buff And &H3FF00000) >> 22;

Try this and you should be doing fine with a Byte array.

2+2=5 for very large amounts of 2 (always loved that one hehe!)

[DidiKunz]

Hello Michael, I did not read the whole document about the Cineon File Format, but did a similar research about a image format of a vision mixer's still store (Kahuna) recently. There where the colors also 10 bit (this is common in broadcasting video) but the color was not in RGB but in YUV-format. If you have strange colors, when you are done, start investigating in this direction. By the way: you should not open your cineon file as a bitmap, but as a byte-array (as suggested), then you could get the three 10-bits out of the 32-bit integer, without GDI+ confuses you. Then alocate a 24-Bit (RGB) Bitmap and use something like setpixel (for testing only, is very slow) to write your converted RGB-values to the bitmap. To get around the slow setpixel look for articles about manipulating bitmap directly using 'dirty-buffers', but not before you see a picture with the slow method... Hope to help you find your way, good luck: Didi

[Sonhospa]

Thank you, Didi! I could't open dpx as bitmap anyway, so creating a byte array was my only solution. I had some strong support from Moreno (off-forum) explaining me how to extract the bits in the right way. When allocating 24-Bit RGB Bitmap, as you suggest, a somehow recognizable picture shows up at least... Here's where we're stuck at the moment. The resulting RGB values make sense in some way (a certain pixel we analyzed e.g. has 132/176/134 while correct RGB values are supposed to be 33/44/33), but the picture shown is completely false colored... a bit like taken by a thermal sensor but heavily green in addition :(. DPX has so many different possibilities to hold a bitmap: it could be YUV, RGB, LIN, LOG and much more... Obviously the Cintel scanner puts 'transfer = 3' (meaning LOG) into the header despite the operators SWEAR it can only be a linear RGB in the data, coz they didn't even install the hardware needed to scan LOG format. Confusion :confused: is resulting about the proper interpretation of the data. Moreno thinks I'll have to take it as a fact that it's LOG data and go compute a LUT. I still wish I could avoid it, believing the operators... because doing that I might have to dig into C++ which scares me a bit - all I want to do is convert a particular source picture, finally, and not analyze all the different kinds of DPX. Did you probably find a way in your project how to erase that kind of doubts and clearly determine which colorspace and type the dpx is? Regards Mick

[DidiKunz]

Hi Mick, my project was not DPX, but a internal format of a Vison mixer, but it used also 10 bit... I looked at google to see, if there is an open source library to read DPX files and found GraphicsMagick[^] probably this could be a solution, there are different bindings including a COM object, that you should be able to use from VB.NET. Regards: Didi

[Sonhospa]

Hi Didi, yeah, I'm trying with the GM Source also - the problem is a) it's C++ which I'm fully unable to understand and b) in the needed conversion function it's considering so many details like e.g. all the different formats and colorspaces that even for understanding I have to jump from one function to the other trying to read it --> problem a :( Thank you still, and have a nice day Mick

[DidiKunz]

Hi Mick, would not try to go into the sources, just use ImageMagick in VB.NET[^] should be enough. Regards: Didi

[Sonhospa]

Hi Didi, I had played around with that one some time ago (before trying to convert the file data myself) and gave up after a while because I didn't get the source compiled. Now I see they obviously added the DLLs, so probably I'll use it (i.e. try again). At least much more realistic to get a grip on than starting C++ studies ;P and that makes me happy :-D Thanks for the reminder, anyway! Have a nice weekend Mick

[Sonhospa]

Hi again, Didi! Stepping through the instructions I managed to build the dll and have the path to the other dll's corrected, so an image is shown in my picturebox. Unfortunately, after approx. 30 seconds, the solution throws an 'OutOfMemoryException' :sigh: without any additional hint where exactly it would happen. The same effect occurs running the sample solution included with the article, so I figure it happens somewhere in the wrapper dll. I found a respective question from 2008 in the posts of the article, but it remained unanswered. Did you by any chance solve that problem OR successfully update the wrapper as described with a subsequent version of ImageMagick? It might be an older bug of IM that's been erased for a long time, but despite of many attempts I didn't manage to compile with an updated source. Thanks for now, Mick EDIT: After some experiments I found that this error doesn't happen loading standard size (1920 * 1080) DPX files, only when loading 2k-DPX (2048 * 1536 or 2048 * 1556)!

modified on Sunday, August 16, 2009 4:51 AM

[DidiKunz]

Hi Mick, actualy I must say, that I did no use the library myself, just googled it for you as an idea to easier find your way... Probably you can try the .NET bindngs here[^] it says, that it is a continuation of the work on code project... Good luck: Didi P.S. Wo in Deutschland wohnst Du? Ich bin aus der Schweiz...

[Sonhospa]

Servus Didi, thanks :rose: again for the link - this might be extremely helpful :thumbsup: since at least it's updated to the latest version of IM. I already downloaded it, let's see if the 2k-bug is gone then. p.s.: Arg weit weg bin ich nicht - München. Aber wie Du vielleicht am Namen erkennst kommt meine Familie aus dem Badischen, wo man ganz ähnlich spricht wie Ihr :laugh: ------------------------ EDIT: The download isn't a recent version of the wrapper, it just contains a newer set of binaries. This might be useful for someone who knows how to build from C++. I think my problem is that I can't figure out the proper directory structure to re-build that wrapper - with the new binaries I still face several hundred errors but no result :mad: so it's just the same as following the instructions in the article.

modified on Sunday, August 16, 2009 12:23 PM

[Sonhospa]

With some strong support I figured out the necessary changes. Here they are for others who might be interested: 1. The displayImage function has to be slightly changed: The former function 'MakePixelArray' has been replaced by a function that returns a byte array, holding 3 bytes for each pixel (RGB). As a consequence, the PixelFormat has to be adapted:

Public Sub DisplayImage(ByVal PicFile As FileInfo, ByVal ImageOffset As UInteger, ByVal Width As UInteger, ByVal Height As UInteger)
Dim arrayImage() As Byte = MakeRGBArray(PicFile, ImageOffset) <--- changed routine
Dim gch As GCHandle = GCHandle.Alloc(arrayImage, GCHandleType.Pinned)
Dim pBuf As IntPtr = gch.AddrOfPinnedObject

    PictureBox1.SizeMode = PictureBoxSizeMode.Zoom
    PictureBox1.Image = New Bitmap(Width, Height, 3 \* Width, Imaging.PixelFormat.Format24bppRgb, pBuf)      <--- changed pixel format
    gch.Free()
End If

End Sub

2. MakeRGBArray reads a UInteger for each Pixel and swaps the bytes first. With a bit-mask and a bit-shifting operation, the padding of the Uinteger (32 bits for 3 * 10 bits RGB) is eliminated, the 10-bit-values read and converted to 8-bit:

Private Function MakeRGBArray(ByVal PicFile As FileInfo, ByVal ImageOffset As UInteger) As Array
Dim ft As FileStream = New FileStream(PicFile.FullName, FileMode.Open)
Dim brh As BinaryReader = New BinaryReader(ft)

ft.Position = ImageOffset          ' start with first pixel after the header

Dim RGBArray(CInt((PicFile.Length - ft.Position) / 4 \* 3) - 1) As Byte
For i = 0 To (RGBArray.Length - 1) Step 3
    Dim buff As UInt32 = SwapDWORD(brh.ReadUInt32)
    ' bit-shifting operation
    RGBArray(i) = (buff And &HFFC) >> 4
    RGBArray(i + 1) = (buff And &H3FFFFC) >> 14
    RGBArray(i + 2) = (buff And &HFFFFFFFC) >> 24
Next i

ft.Close()
brh = Nothing
ft = Nothing

Return RGBArray

End Function

Maybe it helps someone else. Special thanks to Moreno for the basic idea and perfect offline support! :thumbsup: