[Qt-interest] 16-bit grayscale images

Andreas Steinel a.steinel at googlemail.com
Mon Apr 27 20:41:10 CEST 2009


Hi Judy,

On Mon, Apr 27, 2009 at 5:41 PM, Judy Duncan <jduncan at duncanimaging.com>wrote:

>  Thanks Andreas.
>
>  Just to clarify that I am understanding you correctly…
>
> You are suggesting that I do something like have the derived class inherit
> all of QImage and then add an additional member which is a buffer for the
> high bit-depth data where it can be manipulated as needed.  Then, as you
> have said, before doing any display, that I use a function like you’ve shown
> below to copy the 8-bit version of each pixel into the normal QImage
> buffer.  So I end up keeping a 16-bit copy of my data along with an 8-bit
> version (which really becomes 4X the 8-bit data because of the RGB and
> Alpha channels)?
>

I did it this way and it works for me, yes. Internally I use float to
represent my data. Yet you describe what wannted to say. Wrap the image and
dynamic cast it if needed.

Another project which has to use such kind of setup your describe is pfsview
from the pfs-tools (both open-source HDR processing and viewing). I haven't
looked in their code, but they had definitely something to convert HDR data
to 8-bit displayable data.



> It looks like  all of the supported QImage formats other than the 1-bit
> formats are color – so the grayscale has to be created by putting an
> identical value into the RGB color planes?
>

That could be right. I only use RGB images so I cannot tell if there is
anything simpler. Actually, I use my own multispectral image class (which
growed over the last years) as internal storage in my class and only copy
the raw image data to the QImage for display purpose.

I hope this information is useful.


> Thanks,
>
> Judy
>
>
>
>
>
> *From:* a.steinel at googlemail.com [mailto:a.steinel at googlemail.com] *On
> Behalf Of *Andreas Steinel
> *Sent:* Sunday, April 26, 2009 3:54 PM
> *To:* Judy Duncan; qt-interest at trolltech.com
> *Subject:* Re: [Qt-interest] 16-bit grayscale images
>
>
>
> Hi Judy,
>
> I recently programed a simple wrapper for that purpose. It works straight
> forward if you inherit QImage. Afterwards, you can easily use your class
> with the normal QT stuff, if you 'flush' the raw data, to the real image
> stored in the inherited QImage class.
>
> I achieve this by using something like this for writing back the data (if
> the QImage is already set up correctly: size, bit-format, depth, etc.). The
> method is called explicitly before a QImage action with a raw-image.
>
>
>     uchar *pixeldata = bits();
>
>     unsigned int pos = 0, pos4 = 0;
>     for (unsigned int y=0; y < h; y++)
>         for(unsigned int x=0; x < w; x++)
>         {
>             // current position
>             pos  = x + y*w;
>             pos4 = pos << 2;
>
>             // alpha is stores at pixeldata[pos4]
>             // you can do your tone-mapping here.
>             pixeldata[pos4 + 2 ] = (uchar) red(x,y);
>             pixeldata[pos4 + 1 ] = (uchar) green(x,y);
>             pixeldata[pos4 + 0 ] = (uchar) blue(x,y);
>         }
>
> Best regards,
> Andreas
>
> On Sun, Apr 26, 2009 at 7:50 PM, Judy Duncan <jduncan at duncanimaging.com>
> wrote:
>
> I need to manipulate and display 16-bit grayscale images in an application…
> something fairly common with scientific data.  I have been studying QImage,
> QPixMap, and other graphics support in Qt and am not finding (or perhaps
> just not recognizing) what I need.  None of the supported image formats I
> see in the documentation will support high-bit depth, single channel
> images.
>
>
>
> Displaying high-bit depth data is always sticky because you have to settle
> on some mapping of the high-depth data to the (usually 8-bit) depth of the
> screen.  Based on what I’ve seen in the docs I’m thinking I may have to
> create my own data buffer and then map the pixels into an 8-bit grayscale
> image.  Any suggestions, or easiest Qt approach for doing this?  As an
> alternative, does anyone recommend a particular 3rd party plug-in? I’m
> hesitant to go the 3rd party direction due to deadlines and the risks of
> an unknown package – but if it comes with recommendations, it could save
> some time.
>
>
>
> Thanks in advance to all you incredibly helpful people…
>
>
>
> Judy
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090427/dd2fc7c4/attachment.html 


More information about the Qt-interest-old mailing list