| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
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 |
|---|
| Version: | 1.1-current |
|---|
| Created By: | fsausm |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v5825) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #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>
int
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 *)i.data()[0],
i.w() / 2, i.h() / 2,
i.d(), i.w() * i.d());
b.image(image->copy(image->w() * 2, image->h() * 2));
w.show();
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 *)i.data()[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 *)i.data()[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:
http://www.fltk.org/articles.php?L468 | |
| |
| #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.
<http://frederik-sausmikat.pytalhost.de/fltk/>
Thanks for your help,
Freddy | |
| |
| #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.
Regards,
Freddy | |
| |
| #6 | matt
06:19 May 14, 2007 |
| Fixed in Subversion repository.
Thank you for the patches! | |
[ Return to Bugs & Features ]
|
| |
