| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
hi,
I've written a small widget which displays a QImage like this:
void QMonitor::paintEvent(QPaintEvent */*event*/){
QPainter painter(this);
QRectF target(0.0, 0.0, 480.0, 640.0);
painter.setWindow(0,0,480,640);
painter.drawImage(target,*m_image);
}
when the QImage drawn on the screen is loaded like this:
QImage *m_image = new QImage(":/images/testje.png");
it all works!
however, I actually need to create the QImage from a uchar buffer not from an image file on disk,
which I did like this:
QImage *m_image = new QImage(frame->image, width, height, QImage::Format_ARGB32);
this seems to work flawlessy because isNull returns FALSE, and I can write my image to a PNG without problems:
qDebug() << m_image->isNull();
qDebug() << m_image->save("testje.png","PNG");
now here comes my problem, when passing this new m_image created from the uchar frame->image to my widget that paints,
the line:
"painter.drawImage(target,*m_image);"
segfaults during runtime. Any ideas? Whats the difference between a QImage from disk and a QImage created from a uchar?
with kind regards,
Jasper
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
hi,I've written a small widget which displays a QImage like this:void QMonitor::paintEvent(QPaintEvent */*event*/){ QPainter painter(this); QRectF target(0.0, 0.0, 480.0, 640.0); painter.setWindow(0,0,480,640); painter.drawImage(target,*m_image);}when the QImage drawn on the screen is loaded like this:QImage *m_image = new QImage(":/images/testje.png");it all works!however, I actually need to create the QImage from a uchar buffer not from an image file on disk,which I did like this: QImage *m_image = new QImage(frame->image, width, height, QImage::Format_RGB32);
(the image->frame comes from firewire capture via libdc1394 http://damien.douxchamps.net/ieee1394/libdc1394/ for those who are interested) this seems to work partially because isNull returns FALSE, and I can write my image to a PNG: qDebug() << m_image->isNull(); qDebug() << m_image->save("image.png","PNG");
however this is the result (compared with writing the buffer directly to a pixmap file):
http://home.scarlet.be/sir/qimage/qimage.html
Maybe I have to write a format conversion function which converts the frame->image buffer to Qt's internal RGB format?
and a bigger problem, when passing this new m_image created from the uchar frame->image to my widget that paints,the line:"painter.drawImage(target,*m_image);"segfaults during runtime. Any ideas? Whats the difference between a QImage from disk and a QImage created from a uchar?with kind regards,Jasper
ps: I added the medtech mailinglist too, since i'm writing a microscopy application and others there may have used libdc1394 in the past.
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
On 11/7/07, Jasper Leemans <j_leemans@xxxxxxxxxxx> wrote: > Whats the difference between a QImage from disk and a QImage created from a > uchar? Mainly, reading from a file can use the various image-format decoders (JPEG, PNG, BMP, etc.). Using the QImage(uchar*,width,height,format) constructor expects a raw bitmap array of pixels (with number of pits per pixel depending on the Format argument). Looking at your example images, I'd say your bits per pixel is wrong. Possibly the camera is storing data as 0xRRGGBB (24bpp, no padding) but Format_RGB32 expects 0xffRRGGBB (24 bits stored in a 32-bit word, first 8 bits ignored). Check the camera/library docs to see exactly what it's providing. You may be able to tell the library to supply data in a format Qt can handle, or you might have to manually unpack the frames. > and a bigger problem, when passing this new m_image created from the uchar > frame->image to my widget that paints, > the line: > > "painter.drawImage(target,*m_image);" > > segfaults during runtime. Does the source buffer get deleted before the drawImage call? Note from the documentation: "The buffer must remain valid throughout the life of the QImage. The image does not delete the buffer at destruction." -- [ signature omitted ]
On 11/7/07, Andrew Medico <a.medico@xxxxxxxxx> wrote:
> On 11/7/07, Jasper Leemans <j_leemans@xxxxxxxxxxx> wrote:
>
> > Whats the difference between a QImage from disk and a QImage created from a
> > uchar?
>
> Mainly, reading from a file can use the various image-format decoders
> (JPEG, PNG, BMP, etc.). Using the QImage(uchar*,width,height,format)
> constructor expects a raw bitmap array of pixels (with number of pits
> per pixel depending on the Format argument).
>
> Looking at your example images, I'd say your bits per pixel is wrong.
> Possibly the camera is storing data as 0xRRGGBB (24bpp, no padding)
> but Format_RGB32 expects 0xffRRGGBB (24 bits stored in a 32-bit word,
> first 8 bits ignored). Check the camera/library docs to see exactly
> what it's providing. You may be able to tell the library to supply
> data in a format Qt can handle, or you might have to manually unpack
> the frames.
For what it's worth, I have some code that captures video from cameras
(including the MacBook's internal iSight) using Intel's OpenCV
library. If I just pass the raw frame (24bpp, no padding) into a
QImage, I get an effect almost identical to your captures (grayscale,
4 shifted copies of the image). The unpacking routine is very simple
(not optimized, just enough to work):
unsigned char* in = /* pointer from OpenCV */;
unsigned char* out = /* my buffer to be passed into a QImage with
format QImage::Format_RGB32*/;
for (int i=0; i< width() * height(); i++)
{
out[i*4+0] = in[i*3+0]; // blue
out[i*4+1] = in[i*3+1]; // green
out[i*4+2] = in[i*3+2]; // red
out[i*4+3] = 0; // alpha (not provided by OpenCV)
}
--
[ signature omitted ]
El Miércoles 07 Noviembre 2007, Andrew Medico escribió:
> On 11/7/07, Andrew Medico <a.medico@xxxxxxxxx> wrote:
> > On 11/7/07, Jasper Leemans <j_leemans@xxxxxxxxxxx> wrote:
> > > Whats the difference between a QImage from disk and a QImage created
> > > from a uchar?
> >
> > Mainly, reading from a file can use the various image-format decoders
> > (JPEG, PNG, BMP, etc.). Using the QImage(uchar*,width,height,format)
> > constructor expects a raw bitmap array of pixels (with number of pits
> > per pixel depending on the Format argument).
> >
> > Looking at your example images, I'd say your bits per pixel is wrong.
> > Possibly the camera is storing data as 0xRRGGBB (24bpp, no padding)
> > but Format_RGB32 expects 0xffRRGGBB (24 bits stored in a 32-bit word,
> > first 8 bits ignored). Check the camera/library docs to see exactly
> > what it's providing. You may be able to tell the library to supply
> > data in a format Qt can handle, or you might have to manually unpack
> > the frames.
>
> For what it's worth, I have some code that captures video from cameras
> (including the MacBook's internal iSight) using Intel's OpenCV
> library. If I just pass the raw frame (24bpp, no padding) into a
> QImage, I get an effect almost identical to your captures (grayscale,
> 4 shifted copies of the image). The unpacking routine is very simple
> (not optimized, just enough to work):
>
> unsigned char* in = /* pointer from OpenCV */;
> unsigned char* out = /* my buffer to be passed into a QImage with
> format QImage::Format_RGB32*/;
> for (int i=0; i< width() * height(); i++)
> {
> out[i*4+0] = in[i*3+0]; // blue
> out[i*4+1] = in[i*3+1]; // green
> out[i*4+2] = in[i*3+2]; // red
> out[i*4+3] = 0; // alpha (not provided by OpenCV)
> }
Shouldn't alpha be 255? Or you need it different?
--
[ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On 11/7/07, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@xxxxxxxxx> wrote:
> El Miércoles 07 Noviembre 2007, Andrew Medico escribió:
> > On 11/7/07, Andrew Medico <a.medico@xxxxxxxxx> wrote:
> > > On 11/7/07, Jasper Leemans <j_leemans@xxxxxxxxxxx> wrote:
> > > > Whats the difference between a QImage from disk and a QImage created
> > > > from a uchar?
> > >
> > > Mainly, reading from a file can use the various image-format decoders
> > > (JPEG, PNG, BMP, etc.). Using the QImage(uchar*,width,height,format)
> > > constructor expects a raw bitmap array of pixels (with number of pits
> > > per pixel depending on the Format argument).
> > >
> > > Looking at your example images, I'd say your bits per pixel is wrong.
> > > Possibly the camera is storing data as 0xRRGGBB (24bpp, no padding)
> > > but Format_RGB32 expects 0xffRRGGBB (24 bits stored in a 32-bit word,
> > > first 8 bits ignored). Check the camera/library docs to see exactly
> > > what it's providing. You may be able to tell the library to supply
> > > data in a format Qt can handle, or you might have to manually unpack
> > > the frames.
> >
> > For what it's worth, I have some code that captures video from cameras
> > (including the MacBook's internal iSight) using Intel's OpenCV
> > library. If I just pass the raw frame (24bpp, no padding) into a
> > QImage, I get an effect almost identical to your captures (grayscale,
> > 4 shifted copies of the image). The unpacking routine is very simple
> > (not optimized, just enough to work):
> >
> > unsigned char* in = /* pointer from OpenCV */;
> > unsigned char* out = /* my buffer to be passed into a QImage with
> > format QImage::Format_RGB32*/;
> > for (int i=0; i< width() * height(); i++)
> > {
> > out[i*4+0] = in[i*3+0]; // blue
> > out[i*4+1] = in[i*3+1]; // green
> > out[i*4+2] = in[i*3+2]; // red
> > out[i*4+3] = 0; // alpha (not provided by OpenCV)
> > }
>
> Shouldn't alpha be 255? Or you need it different?
In this case, the alpha value doesn't matter because I put the data
into the QImage with Format_RGB32 (which ignores the alpha values). If
I were putting the data into QImage with Format_ARGB32, then the alpha
value would need to be set appropriately (most likely to 255, as you
say).
So in my application, that line is unnecessary. It could be removed
for a small speedup.
--
[ signature omitted ]
El Miércoles 07 Noviembre 2007, Andrew Medico escribió:
> On 11/7/07, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@xxxxxxxxx>
wrote:
> > El Miércoles 07 Noviembre 2007, Andrew Medico escribió:
> > > On 11/7/07, Andrew Medico <a.medico@xxxxxxxxx> wrote:
> > > > On 11/7/07, Jasper Leemans <j_leemans@xxxxxxxxxxx> wrote:
> > > > > Whats the difference between a QImage from disk and a QImage
> > > > > created from a uchar?
> > > >
> > > > Mainly, reading from a file can use the various image-format decoders
> > > > (JPEG, PNG, BMP, etc.). Using the QImage(uchar*,width,height,format)
> > > > constructor expects a raw bitmap array of pixels (with number of pits
> > > > per pixel depending on the Format argument).
> > > >
> > > > Looking at your example images, I'd say your bits per pixel is wrong.
> > > > Possibly the camera is storing data as 0xRRGGBB (24bpp, no padding)
> > > > but Format_RGB32 expects 0xffRRGGBB (24 bits stored in a 32-bit word,
> > > > first 8 bits ignored). Check the camera/library docs to see exactly
> > > > what it's providing. You may be able to tell the library to supply
> > > > data in a format Qt can handle, or you might have to manually unpack
> > > > the frames.
> > >
> > > For what it's worth, I have some code that captures video from cameras
> > > (including the MacBook's internal iSight) using Intel's OpenCV
> > > library. If I just pass the raw frame (24bpp, no padding) into a
> > > QImage, I get an effect almost identical to your captures (grayscale,
> > > 4 shifted copies of the image). The unpacking routine is very simple
> > > (not optimized, just enough to work):
> > >
> > > unsigned char* in = /* pointer from OpenCV */;
> > > unsigned char* out = /* my buffer to be passed into a QImage with
> > > format QImage::Format_RGB32*/;
> > > for (int i=0; i< width() * height(); i++)
> > > {
> > > out[i*4+0] = in[i*3+0]; // blue
> > > out[i*4+1] = in[i*3+1]; // green
> > > out[i*4+2] = in[i*3+2]; // red
> > > out[i*4+3] = 0; // alpha (not provided by OpenCV)
> > > }
> >
> > Shouldn't alpha be 255? Or you need it different?
>
> In this case, the alpha value doesn't matter because I put the data
> into the QImage with Format_RGB32 (which ignores the alpha values). If
> I were putting the data into QImage with Format_ARGB32, then the alpha
> value would need to be set appropriately (most likely to 255, as you
> say).
>
> So in my application, that line is unnecessary. It could be removed
> for a small speedup.
You say you get shifted images ¿could it be that Format_RGB32 "thinks" there
is _no_ alpha encoded, soy you get a displacement?
I have not checked the sources nor the docs (maybe I shouldn't aswer mails
just before going to sleep :-) )
Regards, Lisandro.
--
[ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Jasper Leemans wrote: > Maybe I have to write a format conversion function > which converts the frame->image buffer to Qt's internal RGB format? Yes, looks like your image is not in Format_RGB32. > and a bigger problem, when passing this new m_image > created from the uchar frame->image to my widget that paints, > the line: > > "painter.drawImage(target,*m_image);" > > segfaults during runtime. Any ideas? Whats the > difference between a QImage from disk and a QImage created > from a uchar? Sometimes it helps to read the docs ;-) from the docs of QImage::QImage ( uchar * data, int width, int height, Format format ): "The buffer must remain valid throughout the life of the QImage." Your buffer has probably been released in the meantime. Cheers, Peter -- [ signature omitted ]
Peter Prade wrote: > Subject: AW: qimage and draw problem (edit) > Date: Thu, 8 Nov 2007 12:24:59 +0100 > From: prade@xxxxxxxxxxx > To: qt-interest@xxxxxxxxxxxxx > > Jasper Leemans wrote: > > > Maybe I have to write a format conversion function > > which converts the frame->image buffer to Qt's internal RGB format? > > Yes, looks like your image is not in Format_RGB32. jip, I wrote a similar unpacking routine as Andrew's (thanks) and it worked. I used Format_ARGB32 and therefore did set the alpha channel to 255, I don't know if it's obligatory to use the ARGB32 format if you want to use alpha blending later, so I just did it to be safe in case I might need it in the future. > > and a bigger problem, when passing this new m_image > > created from the uchar frame->image to my widget that paints, > > the line: > > > > "painter.drawImage(target,*m_image);" > > > > segfaults during runtime. Any ideas? Whats the > > difference between a QImage from disk and a QImage created > > from a uchar? > > Sometimes it helps to read the docs ;-) > > from the docs of QImage::QImage ( uchar * data, int width, int height, > Format format ): > "The buffer must remain valid throughout the life of the QImage." > > Your buffer has probably been released in the meantime. I did actually read that, however this was not the case, after doing the unpacking and loading QImage with proper image data this problem went away. > > Cheers, > Peter > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE