Re: [Gdcm2] Buffer problem in Qt environment

[Sylvain A. <syl...@ho...>]

Hi there!

Yataaaa. I did it !!

Well, finally, I guess I'm done with it!

Sorry guys, but I actually didn't know I had to convert the buffer myself. I thought there were a solution in the API. As I haven't much experience with all of it.

I guess I'll write a few tutorials on how to use GDCM with Qt. Seems that none of the functions of images librairies allowed me to convert a buffer to what I needed.

I finally managed to extract the 16-bits words with bitwise shifts, and convert them to 8 bits and add them to a RGB 24 bits (8-8-8) buffer, format which is known by the Qt image library.

===> However, is this normal: the strongest part of the 16-bits words in the char was AFTER the lightest one. What I'm saying is, I understand that, to put the 16-bits image in a char buffer, that is in 8-bits words, you obviously have to SPLIT the words. But how comes that the left part of the 16-bits word is set AFTER the right one? Is that normal?

Anyway, thanks for all and I'm very grateful to Mathieu for his answers and his library :).

Cheers all.

Sylvain


> Date: Tue, 16 Jun 2009 12:00:06 +0200
> Subject: Re: [Gdcm2] Buffer problem in Qt environment
> From: mat...@gm...
> To: syl...@ho...
> CC: gdc...@li...
> 
> On Tue, Jun 16, 2009 at 10:45 AM, Sylvain ADAM<syl...@ho...> wrote:
> > Salut Mathieu.
> >
> > Thanks for the answers !!
> >
> > Yeah I finally got almost what I wanted by displaying my image in a QImage.
> > But as I said earlier, well, I'm still using the RGB16 format of the QImage
> > class.
> >
> > The RGB888 format doesn't work. I actually looked over the API (maybe not
> > deep enough), both from GDCM and Qt, and I still don't have any clue on how
> > to display my image correctly in Qt and how to access 16bits pixel
> > information at coordinate (x, y) on the original image!
> >
> > For now, I can just get the grayscale value on my QImage (which is actually
> > blue-green because of the format used) by calculating it using the RGB
> > value. So I get a gray value from 0 to 140, which is not the usual gray
> > value for a DICOM image in here. We usually have something from 0 to 2000
> > ~ich.
> >
> > I tried the getPhotometricInterpretation() function, to see what does this
> > return: MONOCHROME2. And that's it. The getSamplesPerPixel returns 1. I'm
> > afraid my image knowledge is a bit limited!
> >
> > As the QImage is my display image, getting information from it is not what I
> > intend to do ('cause for display reasons, we don't really need 16-bits, do
> > we?).
> >
> >
> > Another thing for now, does anyone have had this error before? This happens
> > when I'm using the buffer. This is just displayed by my application output
> > in debugging mode:
> >
> >
> > HEAP[IntensityProfileGUI.exe]:
> >
> > Invalid Address specified to RtlFreeHeap( 05080000, 04DAA558 )
> >
> > The message is displayed twice in my debugger. Well, even if I'm using two
> > or one buffer, and when I comment the buffer line, it does not appear
> > anymore.
> >
> > Thanks for helping me.
> 
> MONOCHROME2 and getSamplesPerPixel really means you only have one
> component (=grayscale) per pixel, do not try to tell Qt there are 3
> using the RGB16 format. Depending on the value from GetPixelFormat()
> you may need a 16 bits QtImage or 8bits QtImage (or even 32bits).
> 
> Check you example such as ConvertPIL.py / ConvertNumpy.py /
> ConvertMPL.py, to see how gdcm can be used to pass the raw byte buffer
> to 3rd party library.
> 
> HTH
> -- 
> Mathieu

_________________________________________________________________
Découvrez toutes les possibilités de communication avec vos proches
http://www.microsoft.com/windows/windowslive/default.aspx