STR #1673

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

STR #1673

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:Image Support
Summary:Fl_RGB_Image::copy() broken with ld != 0
Created By:fsausm
Assigned To:matt
Fix Version:1.1-current (SVN: v5825)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 fsausm
11:20 May 12, 2007
#2 fsausm
12:34 May 13, 2007
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 fsausm
11:20 May 12, 2007
Creating a scaled image (using copy()) from Fl_RGB_Image when LD is != 0 does not work (image is garbled when drawn). This is because in Fl_RGB_Image::copy() the line offset into the source image array is calculated incorrectly.

I've attached a patch against 1.1.x-r5808 which seems to fix this.

Code to reproduce the problem:

#include <FL/Fl.H>
#include <FL/Fl_Box.H>
#include <FL/Fl_Image.H>
#include <FL/Fl_PNG_Image.H>
#include <FL/Fl_Window.H>

main(int argc, char **argv)
        Fl_Image *image = 0;
        Fl_PNG_Image i("YOUR_IMAGE_HERE.png");
        Fl_Window w(800, 600, "copy bug");
        Fl_Box b(0, 0, 800, 600);

        image = new Fl_RGB_Image((unsigned char *)[0],
                                 i.w() / 2, i.h() / 2,
                                 i.d(), i.w() * i.d());

        b.image(image->copy(image->w() * 2, image->h() * 2));;

        return Fl::run();

Regards, Freddy

BTW: desaturate() seems to suffer from a similar problem, will have a look at this tomorrow.
#2 ianmacarthur
03:13 May 13, 2007
Hmmm, I can't comment on your patch, as it is much too early in the day here for me to think straight (!)...  There may well be a bug here, but I can't figure it out!

However; I think maybe your test example is wrong though...

Specifically, the constructor of the new RGB image - you are passing it *all* the data from your input image, but are telling it that the size is half in both width and height. I'm pretty sure the Fl_RGB constructor does not resize the image data you pass it, so that will cause the image to be incorrectly sized. This looks wrong to me...

       image = new Fl_RGB_Image((unsigned char *)[0],
                                        i.w() / 2, i.h() / 2,
                                        i.d(), i.w() * i.d());

Does that account for the mis-scaling you see when you then try and resize the image back up in your copy method? I suspect it does, to be honest.
Also, setting the LD data in the constructor is unlikely to be correct, I think...

Something like this seems to work fine for me:

        image = new Fl_RGB_Image((unsigned char *)[0],
// i.w() / 2, i.h() / 2,
                                                                i.w(), i.h(),
                                i.d() );
// i.d(), i.w() * i.d());

Have you compared your code with the pixmap_browser demo in the test directory? Also this HowTo might be relevant:
#3 fsausm
06:06 May 13, 2007
Indeed passing *all* the data is intended. I have an image which
contains several subimages (a tileset) which I want to extract. As
far as I understand (and it works), Fl_RGB_Image provides the
ld (line delta) parameter exactly for this purpose.

You pass a pointer to rgb image data, set desired width and height,
set depth to match that of the data and ld to the offset in bytes to
the next line of your subimage. This only assigns attributes,
there is nothing done with the image data itself.

Now all Fl_Image::* methods working directly on the image data have
to be (and are) aware of the ld attribute. But in the case of copy()
(and desaturate() also) it is used incorrectly, IMHO.

I've set up a web page which shows what I'm trying to achieve. Maybe
this makes things clearer.


Thanks for your help,
#4 matt
06:20 May 13, 2007
Thanks for the patch. I will try to test this out tonight or tomorrow.  
#5 fsausm
12:55 May 13, 2007
Extended my patch to Fl_Image to also fix color_average() and desaturate() which both suffer from a similar problem as copy().

For sure there exists a more elegant solution to the problem than my version, but I wanted to change the current implementation as little as neccessary.

#6 matt
06:19 May 14, 2007
Fixed in Subversion repository.

Thank you for the patches!
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.