Fl_RGB_Image::draw replacing pixels with random data

[Tom Grieve]

I have a custom widget subclassed from Fl_Window as part of my user interface, in which I'd like to display a 640-by-480-pixel grayscale image and draw a few lines on the image.  When I display the image, the last few lines have seemingly random data replacing the pixel values.

I have retrieved the current image data array (using Fl_RGB_Image::data()) and printed the values to a comma-delimited text file.  I loaded this file into Matlab and the image looks fine.

I've tried with several images of different objects, all .BMP files.  With images containing fewer pixels, it seems to obscure a larger number of the pixels.

I am using FLTK 1.3.2 with MinGW (g++ version 4.8.1) on Windows 7 64-bit.

Has anyone seen this behavior before?  Any ideas of what I might try to further diagnose the problem?  Everything I can see says that the images are fine.

Thank you for whatever help you might provide!

Tom

[Greg Ercolano]

I haven't heard of this..

Since it sounds image specific, can you provide the image
and describe how you're displaying it with FLTK, or better yet,
show us a small compilable example that shows the problem
vis a vis like a modified version one of the simple cheat
page image oriented examples, such as:
http://seriss.com/people/erco/fltk/#Fl_JPG_Image

It should be easy to change that example to display a BMP
just by changing "JPEG" to "BMP" throughout the code.

[MacArthur, Ian (Selex ES, UK)]

I have a custom widget subclassed from Fl_Window as part of my user interface, in which I'd like to display a 640-by-480-pixel grayscale image and draw a few lines on the image.  When I display the image, the last few lines have seemingly random data replacing the pixel values.

 

I have retrieved the current image data array (using Fl_RGB_Image::data()) and printed the values to a comma-delimited text file.  I loaded this file into Matlab and the image looks fine.

 

I've tried with several images of different objects, all .BMP files.  With images containing fewer pixels, it seems to obscure a larger number of the pixels.

 

I am using FLTK 1.3.2 with MinGW (g++ version 4.8.1) on Windows 7 64-bit.

 

Has anyone seen this behavior before?  Any ideas of what I might try to further diagnose the problem?  Everything I can see says that the images are fine.

 

[imm] I see Greg’s already given a few hints, and I’d be interested to hear what happens if you open your .bmp file using fltk’s own test/pixmap_browser demo sample.

 

It handles the image formats that fltk “knows” about, including .bmp, so if it can *not* cope with your images then that gives us somewhere solid to start from.

 

If they open OK in in test/pixmap_browser then I guess that might be something in your derived widget? If it fails in test/pixmap_browser, then that gives us some code we all have, that can be tested on a variety of systems...

 

FWIW, the test/pixmap_browser demo works fine for me this morning!

 

Cheers

 

 

Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Tom Grieve]

On Wednesday, July 9, 2014 2:44:22 AM UTC-6, MacArthur, Ian (Selex ES, UK) wrote:

I have a custom widget subclassed from Fl_Window as part of my user interface, in which I'd like to display a 640-by-480-pixel grayscale image and draw a few lines on the image.  When I display the image, the last few lines have seemingly random data replacing the pixel values.

 

I have retrieved the current image data array (using Fl_RGB_Image::data()) and printed the values to a comma-delimited text file.  I loaded this file into Matlab and the image looks fine.

 

I've tried with several images of different objects, all .BMP files.  With images containing fewer pixels, it seems to obscure a larger number of the pixels.

 

I am using FLTK 1.3.2 with MinGW (g++ version 4.8.1) on Windows 7 64-bit.

 

Has anyone seen this behavior before?  Any ideas of what I might try to further diagnose the problem?  Everything I can see says that the images are fine.

 

[imm] I see Greg’s already given a few hints, and I’d be interested to hear what happens if you open your .bmp file using fltk’s own test/pixmap_browser demo sample.

 

It handles the image formats that fltk “knows” about, including .bmp, so if it can *not* cope with your images then that gives us somewhere solid to start from.

 

If they open OK in in test/pixmap_browser then I guess that might be something in your derived widget? If it fails in test/pixmap_browser, then that gives us some code we all have, that can be tested on a variety of systems...

 

FWIW, the test/pixmap_browser demo works fine for me this morning!

Greg & Ian,

Thank you both for your replies!

All of my test images open perfectly fine with the test/pixmap_browser demo.  (I hadn't seen that one--I appreciate the suggestion and will look more closely at the test folder when I run into trouble in the future!)  I guess that tells me there's probably nothing wrong with my images, and instead something wrong with my code.

I've been trying to reduce my code to a simple "demo" version I can post online, and I've run into some trouble deciding what I can chop out.  It may take me another day or two to get it together.

Thanks,

Tom

[MacArthur, Ian (Selex ES, UK)]

 

All of my test images open perfectly fine with the test/pixmap_browser demo.  (I hadn't seen that one--I appreciate the suggestion and will look more closely at the test folder when I run into trouble in the future!)  I guess that tells me there's probably nothing wrong with my images, and instead something wrong with my code.

 

I've been trying to reduce my code to a simple "demo" version I can post online, and I've run into some trouble deciding what I can chop out.  It may take me another day or two to get it together.

 

[imm]

 

In case it helps, there is an old how-to I wrote centuries ago that might be relevant:

 

http://www.fltk.org/articles.php?L468

 

 

Though I’m not sure how pertinent to your problem that will be.

 

 

 

 

 

[Tom Grieve]

On Thursday, July 10, 2014 3:28:32 AM UTC-6, MacArthur, Ian (Selex ES, UK) wrote:

 

All of my test images open perfectly fine with the test/pixmap_browser demo.  (I hadn't seen that one--I appreciate the suggestion and will look more closely at the test folder when I run into trouble in the future!)  I guess that tells me there's probably nothing wrong with my images, and instead something wrong with my code.

 

I've been trying to reduce my code to a simple "demo" version I can post online, and I've run into some trouble deciding what I can chop out.  It may take me another day or two to get it together.

 

[imm]

 

In case it helps, there is an old how-to I wrote centuries ago that might be relevant:

 

http://www.fltk.org/articles.php?L468

 

 

Though I’m not sure how pertinent to your problem that will be.

 

Thanks to your help, I think I've finally solved it.

I think what was causing the problem was how I was drawing the images.  In my subclassed widget, I had a member of type Fl_RGB_Image called my_image, and in my widget's draw() function, I had the following lines:

void CustomWidget::draw()

{

    // Have Fl_Window run its underlying draw() routine

    Fl_Window::draw();

    

    // Draw the image

    my_image->draw(0,0,width,height);

    

    // Some other code

}

I have changed the CustomWidget so it has an unsigned char array called image_buffer, and modified the draw() function to read:

void CustomWidget::draw()

{

    // Have Fl_Window run its underlying draw() routine

    Fl_Window::draw();

    

    // Draw the image

    fl_draw_image_mono(image_buffer, 0, 0, width, height);

    

    // Some other code

}

It no longer has the "corrupted"-looking pixels in the bottom few rows.  Problem solved!

So now my question is, should the Fl_RGB_Image::draw() method work the way I was using it before, or was I trying to use the library incorrectly?  If it should work that way, does that mean there's something else wrong with my setup?

Tom

[Ian MacArthur]

On Tue Jul 15 2014 17:57:31, Tom Grieve wrote:

> Thanks to your help, I think I've finally solved it.

Glad to hear you got it working...

> I think what was causing the problem was how I was drawing the images. In my subclassed widget, I had a member of type Fl_RGB_Image called my_image, and in my widget's draw() function, I had the following lines:
>
> void CustomWidget::draw()
> {
> // Have Fl_Window run its underlying draw() routine
> Fl_Window::draw();
>
> // Draw the image
> my_image->draw(0,0,width,height);
>
> // Some other code
> }

I’d probably just have used my_image->draw(0,0); here I suspect - though in practice I’d probably have gone with the fl_draw_image_mono() approach anyway...

> I have changed the CustomWidget so it has an unsigned char array called image_buffer, and modified the draw() function to read:
>
> void CustomWidget::draw()
> {
> // Have Fl_Window run its underlying draw() routine
> Fl_Window::draw();
>
> // Draw the image
> fl_draw_image_mono(image_buffer, 0, 0, width, height);
>
> // Some other code
> }
>
> It no longer has the "corrupted"-looking pixels in the bottom few rows. Problem solved!
>
> So now my question is, should the Fl_RGB_Image::draw() method work the way I was using it before, or was I trying to use the library incorrectly? If it should work that way, does that mean there's something else wrong with my setup?

No idea; looks like it ought to work.

There may be something in your setup, hard to say, but I’ve no idea what to suggest.

One thing, I don’t think I’d have derived my widget from Fl_Window; I’d probably have derived from something simpler like Fl_Box, then just put that inside a standard window...

Can’t say whether that will make any difference or not though!