Problems observed while using fl_imgtk::crop

[Kevin Routley]

I will be looking at using other bits of code soon, but here are some problems I discovered after grabbing the crop function. My thanks in advance for these functions!

1. Perhaps you have a macro in your headers someplace, but this: #pragma omp parellel should be "parallel".
2. I'm occasionally encountering images which are very large. You might consider using size_t to calculate the size of obuff.
3. This following chunk of code leaks obuff if rbuff is NULL.

        uchar* rbuff = (uchar*)src->data()[0];
        uchar* obuff = new uchar[ rw * rh * sd ];

        if ( ( rbuff != NULL ) && ( obuff != NULL ) )

4. This might a limitation of Microsoft's OMP implementation, but it complains the cntx and cnty loop variables need to be signed objects in the parallel for loops.
5. Something which I think is inadequately documented is the fact that the Fl_RGB_Image destructor does not free the memory buffer automatically. The programmer has to manually set the field alloc_array to non-zero, otherwise the buffer is leaked. So:

		return new Fl_RGB_Image(obuff, rw, rh, sd);

really should be:

		Fl_RGB_Image* retimg = new Fl_RGB_Image(obuff, rw, rh, sd);
                retimg->alloc_array = 1;
		return retimg;

[Raphael Kim]

Thanks for advising.
I made this for OpenMP 4.x and not planed to support MSVC OpenMP 2.x, because it actually made for Linux and MacOS.
MSVC doesn't support unsinged(size_t) acutally for OpenMP and I don't have plan to change this. MS are using concurrency instead supporting lastest version of OpenMP. ( or You can fork fl_imgtk for MSVC OpenMP support version )
And ... I was followed default reference of Fl_RGB_Image() in here : https://www.fltk.org/doc-1.3/classFl__RGB__Image.html
And here described as -

The caller is responsible that the image data array bits persists as long as the image is used.
This constructor sets Fl_RGB_Image::alloc_array to 0. To have the image object control the deallocation of the data array bits, set alloc_array to non-zero after construction.

Yes, maybe you are right but I didn't change alloc_array to 1. ( but it seems to better change alloc_array to 1 )
How about using a function to delete Fl_RGB_Image automatically, see 'void discard_user_rgb_image( Fl_RGB_Image* &img );' and it might be useful to delete Fl_RGB_Image from fl_imgtk or FLTK.

And any idea for more ?

[Raphael Kim]

Now fixing typo error in line 2039 of ::cop().

[Raphael Kim]

You can try latest commit version 0.3.37.12.
I've been changed many things for MSVC and fixed some bugs.
Let me know any suggestion if you have :)

[Raphael Kim]

Seems to done it.