DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current Manolo, thanks for the patch, this is a good starting point, but IMO there are a few points that don't work as they should. (1) We can't introduce FL_IMAGE_DATA_LA and distinguish it from FL_IMAGE_DATA_RGBA, because this is very likely to break existing code. We have only one /default/ value that we can set for the optional format value. I also didn't anticipate this problem, but it is real. So we must have some flag for *automatic* detection, depending on the d() or delta value, as it was before. Thus, I propose to change the enum to have: FL_IMAGE_DATA_AUTO = 0 // automatic, depending on d, w/o alpha FL_IMAGE_DATA_ALPHA = 1 // automatic, depending on d, with alpha The default is 0, which means: 1 <= abs(d) <= 2 = gray scale (luminance) w/o alpha abs(d) > 2 = RGB (w/o alpha) Then we can add: FL_IMAGE_DATA_L = 2 // luminance (gray scale) FL_IMAGE_DATA_LA = 3 // luminance (gray scale) with alpha FL_IMAGE_RGB = 4 // RGB FL_IMAGE_DATA_RGBA = 5 // RGBA (RGB with alpha) We should interpret the enum as a bit mask, with the following encoding: Bit 0 (0x0001) = alpha channel (can be combined with others) Bit 1 (0x0002) = gray only (luminance) => L (or LA) Bit 2 (0x0004) = RGB or RGBA (with alpha) later, e.g. Bit 3 (0x0008) = BGR (inv. colors) or ABGR (with alpha) ... or even other encodings, such as 16-bit color channels. Hence, FL_IMAGE_DATA_RGBA == FL_IMAGE_DATA_RGB | FL_IMAGE_DATA_ALPHA etc. Second point: fl_draw_image_mono() should IMHO *not* have the optional format argument. It is designed and documented so that you can pick one of n channels out of, for instance, RGB(A) data and draw this as a gray scale image. This wouldn't work with an alpha channel at a different offset. Thus, fl_draw_image_mono() should simply call fl_draw_image() with format=FL_IMAGE_DATA_L (explicitly), and this should do it. Or am I missing a point here? I assume that fl_draw_image_mono() was only needed because of the auto-detection of color formats implied by the old function. Thus, we should deprecate fl_draw_image_mono() once the new implementation is complete, in favor of using the additional argument. [OT: another useful optional argument for fl_draw_image_mono() could maybe be a color value, either R, G, or B, so that one could draw the R channel in red, the G channel in green, etc.] Third point (just a note): FL_IMAGE_WITH_ALPHA *has* been used in src/Fl_Image.cxx at line #503 (in the "present code base", before your patch), but this can surely be replaced. Last point: the fourth image (Gray+Alpha) in test/unittests doesn't draw correctly on Windows, but this is probably a side effect of the different data format settings. This is probably moot, when the data format enum is changed, because the function must be called differently anyway. I'm going to modify the patch and propose an update, but this will probably not be before Sunday afternoon. Meanwhile, all comments and suggestions would be welcome. Thanks. Link: http://www.fltk.org/str.php?L2583 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
