How would I deal with 10-bit-integer?
-
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
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
Bytearray.2+2=5 for very large amounts of 2 (always loved that one hehe!)
-
Hello everybody, within an otherwise more simple project I have to deal with something that goes far beyond my knowledge so far. Probably someone of you can help with hints or a snippet? The goal is to display a picture format which isn't supported from gdi+ on a form. So I already had to go through a lot of advanced stuff with GCHandle etc., but meanwhile I'm far enough that something (coming from the picture file at least) shows on the screen... unfortunately it's only a mixture of colored pixels :doh: . Considering the picture specification (if you're interested you find it here[^]) each pixel is represented by a 32-bit word, that is (in my particular case) divided into three 10-bit-integers (RGB) and two padding bits (zero). With the code below I create an array of 32-bit-integers from the image information in the file, which are supposed to represent the pixels. But how can I access the RGB information? I.e., how would I be able to derive 10-bit-integers from a 32-bit word? Or am I running into a dead-end with the whole concept? Thanks for any help and advice! Please keep it a bit simple, since for me there seem to be several completely new issues hidden... Michael The main code I use is:
Public Sub DisplayImage(ByVal PicFile As FileInfo) Dim W As UInteger = 200 Dim H As UInteger = 154 Dim stride As UInteger = 4 \* W Dim arrayImage() As UInt32 = MakePixelArray(PicFile) Dim gch As GCHandle = GCHandle.Alloc(arrayImage, GCHandleType.Pinned) Dim pBuf As IntPtr = gch.AddrOfPinnedObject PictureBox1.Width = W PictureBox1.Height = H PictureBox1.SizeMode = PictureBoxSizeMode.StretchImage PictureBox1.Image = New Bitmap(W, H, stride, Imaging.PixelFormat.Format32bppRgb, pBuf) gch.Free() End SubDespite my picture (and the resulting array - see next snippet) is 2048 wide and 1536 high, I still have to set W and H to lower values in order to avoid an AccessViolationExcepiton. But that's another issue... My actual problem seems to be in the 'MakePixelArray' function, because I can't retrieve the 10-bit-Integers needed for RGB from the DWORD. Here's what I have:
Private Function MakePixelArray(ByVal PicFile As FileInfo) As Array
Dim ft As FileStream = New FileStream(PicFile.FullName, FileMode.Open)
Dim brh AsHello 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
-
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
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
-
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
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
-
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
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
-
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
-
Hi Mick, would not try to go into the sources, just use ImageMagick in VB.NET[^] should be enough. Regards: Didi
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
-
Hi Mick, would not try to go into the sources, just use ImageMagick in VB.NET[^] should be enough. Regards: Didi
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
-
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
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...
-
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...
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
-
Hello everybody, within an otherwise more simple project I have to deal with something that goes far beyond my knowledge so far. Probably someone of you can help with hints or a snippet? The goal is to display a picture format which isn't supported from gdi+ on a form. So I already had to go through a lot of advanced stuff with GCHandle etc., but meanwhile I'm far enough that something (coming from the picture file at least) shows on the screen... unfortunately it's only a mixture of colored pixels :doh: . Considering the picture specification (if you're interested you find it here[^]) each pixel is represented by a 32-bit word, that is (in my particular case) divided into three 10-bit-integers (RGB) and two padding bits (zero). With the code below I create an array of 32-bit-integers from the image information in the file, which are supposed to represent the pixels. But how can I access the RGB information? I.e., how would I be able to derive 10-bit-integers from a 32-bit word? Or am I running into a dead-end with the whole concept? Thanks for any help and advice! Please keep it a bit simple, since for me there seem to be several completely new issues hidden... Michael The main code I use is:
Public Sub DisplayImage(ByVal PicFile As FileInfo) Dim W As UInteger = 200 Dim H As UInteger = 154 Dim stride As UInteger = 4 \* W Dim arrayImage() As UInt32 = MakePixelArray(PicFile) Dim gch As GCHandle = GCHandle.Alloc(arrayImage, GCHandleType.Pinned) Dim pBuf As IntPtr = gch.AddrOfPinnedObject PictureBox1.Width = W PictureBox1.Height = H PictureBox1.SizeMode = PictureBoxSizeMode.StretchImage PictureBox1.Image = New Bitmap(W, H, stride, Imaging.PixelFormat.Format32bppRgb, pBuf) gch.Free() End SubDespite my picture (and the resulting array - see next snippet) is 2048 wide and 1536 high, I still have to set W and H to lower values in order to avoid an AccessViolationExcepiton. But that's another issue... My actual problem seems to be in the 'MakePixelArray' function, because I can't retrieve the 10-bit-Integers needed for RGB from the DWORD. Here's what I have:
Private Function MakePixelArray(ByVal PicFile As FileInfo) As Array
Dim ft As FileStream = New FileStream(PicFile.FullName, FileMode.Open)
Dim brh AsWith 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.AddrOfPinnedObjectPictureBox1.SizeMode = PictureBoxSizeMode.Zoom PictureBox1.Image = New Bitmap(Width, Height, 3 \* Width, Imaging.PixelFormat.Format24bppRgb, pBuf) <--- changed pixel format gch.Free() End IfEnd 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 RGBArrayEnd Function
Maybe it helps someone else. Special thanks to Moreno for the basic idea and perfect offline support! :thumbsup: