Using FLTK for the UI, OpenCV for image processing

[Jim Graham]

Ok, here's the next question. I'm working on a photo/image editor.
I'm using FLTK for the UI, and OpenCV for the image processing.
Should I use an FLTK window to load images in, and then process
those images with OpenCV? Or should I use an OpenCV window? I
tried it with OpenCV windows, and the images did load in them,
but (and I probably forgot some options) the image windows were
inactive.

If anyone here has ever combined these two before, and has any
suggestions, I'd love to hear them.

Thanks,
--jim


--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >
spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W
http://fineartamerica.com/profiles/4-james-graham.html

BOFH Excuse for the day:
Heavy gravity fluctuation, move computer to floor rapidly.

[Jim Graham]

Re-stating my previous post to make it a bit more clear....

On Wed, Mar 04, 2015 at 08:26:14AM -0600, Jim Graham wrote:
Ok, here's the next question. I'm working on a photo/image editor.
I'm using FLTK for the UI, and OpenCV for the image processing.

I have yet to figure out how to put buttons on OpenCV image windows,
but I know I can put buttons, slide-bars (whatever), etc., on an
Fl_Window. I've been trying to find out how to use the native file
chooser (Finder, on my Mac) to load an image file (got this part done)
and display it in an Fl_Window (have not found the docs for this yet)
for displaying as the original, and in another Fl_Window, filtering via
OpenCV methods with buttons, slide-bars (again, whatever), etc., as
needed for the image processing method in use.

The first question is, how do I load the image in the Fl_Window? Or do
I need to use a different window type?

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >
spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W
http://fineartamerica.com/profiles/4-james-graham.html

Do not look into waveguide with remaining eye.

[crocher...@gmail.com]

Hi Jim,

    I would recommend to go with the first idea: do your processing using OpenCv in the background and display your image through FLTK. The use of Opencv windows in an FLTK app gave me some erratic behaviors in the past and anyway it will not give you a "nice integration" in your final program (what if you want some buttons or other widgets on the display window for instance?).
    You can have a look here: https://sourceforge.net/p/timeslice/code/ci/master/tree/src/ , grab the Fl_Opencv.cxx and Fl_Opencv.h : it's a simple FLTK widget that takes an Opencv image (a cv::Mat actually) as a parameter and do the job to display it on a Widget (that you can easily include in an Fl_Window or turn into an Fl_Window). The job is done through an FL_Image. The code is not very nice and still basic but that's doing the job (I personally use this one to display videos loaded with Opencv).
I also have a bit more clean and advanced version of the same thing here: https://sourceforge.net/p/bdreader/code/ci/master/tree/src/ (Fl_ViewerCV.cxx and Fl_ViewerCV.h respectively). This one has a few callback mechanisms in it and allows to display only a part (defined by a cv:Rect) of the image you give in parameters.
     Again code is not really nice and can be improved, for instance it only deals with BGR and BGRA images if I remember well, but should be quite easy to modify it.

    And as the header says it has originally been developed by BlueKid and I have turn it to accept Mat (was originally using the old IplImage) and add a few more functionalities.

Vincent

[Jim Graham]

On Thu, Mar 05, 2015 at 03:56:55PM -0800, crocher...@gmail.com wrote:

> I would recommend to go with the first idea: do your processing using
> OpenCv in the background and display your image through FLTK. The use of
> Opencv windows in an FLTK app gave me some erratic behaviors in the past
> and anyway it will not give you a "nice integration" in your final program
> (what if you want some buttons or other widgets on the display window for
> instance?).

I definitely will...at the very least, [reset] [cancel][ok] ... and I
don't know if those can be done via OpenCV windows (question to the
opencv-users list is out, but still not posted, but then, I'm not sure
if that's the list that was shut down when the forums were formed, or if
it's a new list, so it may never be posted).

> You can have a look here:
> https://sourceforge.net/p/timeslice/code/ci/master/tree/src/ , grab the
> Fl_Opencv.cxx and Fl_Opencv.h : it's a simple FLTK widget that takes an
> Opencv image (a cv::Mat actually) as a parameter and do the job to display
> it on a Widget (that you can easily include in an Fl_Window or turn into an
> Fl_Window).

I was looking for that earlier, but the page I found describing it sent
me to a dead link. Thanks! Except...looks like it's not on Sourceforge
anymore. First, I was asked to login (uhhh, that's not right...not just
to get something). Then I did a search ... no results found.

> The job is done through an FL_Image. The code is not very nice
> and still basic but that's doing the job (I personally use this one to
> display videos loaded with Opencv).
> I also have a bit more clean and advanced version of the same thing here:
> https://sourceforge.net/p/bdreader/code/ci/master/tree/src/ (Fl_ViewerCV.cxx
> and Fl_ViewerCV.h

I was able to grab those. Question, then: if I use these, does my
project suddenly become GPL'd?

> Again code is not really nice and can be improved, for instance it
> only deals with BGR and BGRA images if I remember well, but should be quite
> easy to modify it.

No grayscale, then?

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >
spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W
http://fineartamerica.com/profiles/4-james-graham.html

BOFH Excuse for the day:

The Usenet news is out of date.

[Vincent C]

OpenCV GUI will allow you ta had a few controls on your window, but again if anyway you plan to mix it with other FLTK windows/controls, directly go for a full FLTK GUI (and keep Opencv only for the background, image processing job). 

Apologies for the first link I forgot this project is not "public" yet (still in a really alpha version) so that's why you were asked to login: I attach the two files in this message.

Speaking about license: the original code by Bluekid is LGPL and mine (so the Fl_Viewer thing I derived from is work) is GPL, yes. If this license bother you (and I can understand that), the best is certainly for you to have a look to it to get the general idea and write your own derived Fl_Widget or derived Fl_Window since anyway you might have specific needs (resizing...) a bit different than what I'm doing and that sounds not much work. The general idea is really to get a conversion from an Opencv Mat to an Fl_Image and display that.

And regarding the grayscale I think I did something for it but it's something to look at, if not, the more efficient way to deal with that is certainly to check the Opencv Mat format and from that convert it to RGB or BGR and then display it with FLTK as a color image: multiple Opencv formats to one common format to display. That's two lines of code (check image format and opencv convert).

And, last comment, quickly looking at the code, I will recommend you to more look at the Fl_Viewer version than the Fl_Opencv it's a bit cleaner.

Vincent

 

[MacArthur, Ian (Selex ES, UK)]

> I have yet to figure out how to put buttons on OpenCV image windows,
> but I know I can put buttons, slide-bars (whatever), etc., on an
> Fl_Window. I've been trying to find out how to use the native file
> chooser (Finder, on my Mac) to load an image file (got this part done)
> and display it in an Fl_Window (have not found the docs for this yet)
> for displaying as the original, and in another Fl_Window, filtering via
> OpenCV methods with buttons, slide-bars (again, whatever), etc., as
> needed for the image processing method in use.

I don't have code I can give you, but when I did something similar, we used fltk to build the whole GUI, including displaying of the processed image, the image lib was used only to process the image data, not to display it.
That may be the better option for you, too.

>
> The first question is, how do I load the image in the Fl_Window? Or do
> I need to use a different window type?

You probably want to take a look at Greg's examples, e.g. this one:-

http://www.seriss.com/people/erco/fltk/#Fl_JPG_Image


For manipulating the "raw" data of the image, there's a howto here:-

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



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.
********************************************************************

[Jim Graham]

On Fri, Mar 06, 2015 at 09:10:11AM +0000, MacArthur, Ian (Selex ES, UK) wrote:

> > The first question is, how do I load the image in the Fl_Window? Or
> > do I need to use a different window type?

> You probably want to take a look at Greg's examples, e.g. this one:-
>
> http://www.seriss.com/people/erco/fltk/#Fl_JPG_Image

That works, IF the extension exists and is correct (or you have something
read the binary image to get the format).

> For manipulating the "raw" data of the image, there's a howto here:-
>
> http://www.fltk.org/articles.php?L468

If I'm right, that should even work for OpenCV MAT images, with one
tweak:

r = (unsigned char)datap[idx];
g = (unsigned char)datap[idx + 1];
b = (unsigned char)datap[idx + 2];

becomes

b = (unsigned char)datap[idx];
g = (unsigned char)datap[idx + 1];
r = (unsigned char)datap[idx + 2];
a = (unsigned char)datap[idx + 3]; // if there's an alpha channel

But there's one part I definitely don't understand:

if ((xc < xoff) || (xc > (200 - xoff))) {
puts("X click not in image area");
fflush(stdout);
return ret;
}
if ((yc < yoff) || (yc > (200 - yoff))) {
puts("Y click not in image area");
fflush(stdout);
return ret;
}

I see the depth == 3 above, that, for the BGRA version I would change
3 to 4, but what is this bit?

Or it may not work...I now see a lot more code in there. I also just
realized that I need to load a MAT for OpenCV to work with it in an
FLTK window. Hmmmm.

Thanks...I'll try that today. The worst that can happen is it doesn't
work.

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) |

spook...@gmail.com | TeX actually recognizes several kinds of
< Running Mac OS X Lion > | infinity, some of which are ``more infinite''
ICBM / Hurricane: | than others.
30.44406N 86. 59909W | --Donald Knuth in {The TeXbook}
http://fineartamerica.com/profiles/4-james-graham.html

[MacArthur, Ian (Selex ES, UK)]

> > You probably want to take a look at Greg's examples, e.g. this one:-
> >
> > http://www.seriss.com/people/erco/fltk/#Fl_JPG_Image
>

> That works, IF the extension exists and is correct (or you have
> something
> read the binary image to get the format).

If you use an Fl_JPG_Image, as Greg did here, it will favour loading a JPEG.

If you use another fltk image format, or one of the generic options like Fl_Shared_Image, it will try to load the image in "any" supported format (see the pixmap_browser demo in the test folder for a worked example of this.)

> > For manipulating the "raw" data of the image, there's a howto here:-
> >
> > http://www.fltk.org/articles.php?L468
>

> If I'm right, that should even work for OpenCV MAT images, with one
> tweak:
>
> r = (unsigned char)datap[idx];
> g = (unsigned char)datap[idx + 1];
> b = (unsigned char)datap[idx + 2];
>
> becomes
>
> b = (unsigned char)datap[idx];
> g = (unsigned char)datap[idx + 1];
> r = (unsigned char)datap[idx + 2];
> a = (unsigned char)datap[idx + 3]; // if there's an alpha channel

I can't comment on the byte order in a MAT, but the fltk byte order is r,g,b,[a] (where the a is optional) so you need to order the bytes you are reading to get them into the fltk "surface" in that order. Note that is RGBA, not BGRA...

> But there's one part I definitely don't understand:
>
> if ((xc < xoff) || (xc > (200 - xoff))) {
> puts("X click not in image area");
> fflush(stdout);
> return ret;
> }
> if ((yc < yoff) || (yc > (200 - yoff))) {
> puts("Y click not in image area");
> fflush(stdout);
> return ret;
> }

Way back when, someone had asked how to tell if a mouse click fell in the image area or not, and if so return the clicked pixel.
That code is a leftover from that example. If you run the code from a terminal shell, and click in a loaded image, it should print something to tell you what you clicked on. Or something...

>
> I see the depth == 3 above, that, for the BGRA version I would change
> 3 to 4, but what is this bit?
>
> Or it may not work...I now see a lot more code in there. I also just
> realized that I need to load a MAT for OpenCV to work with it in an
> FLTK window. Hmmmm.
>
> Thanks...I'll try that today. The worst that can happen is it doesn't
> work.

[Jim Graham]

On Fri, Mar 06, 2015 at 12:24:44PM +0000, MacArthur, Ian (Selex ES, UK) wrote:

> If you use an Fl_JPG_Image, as Greg did here, it will favour loading a
> JPEG.
>
> If you use another fltk image format, or one of the generic options
> like Fl_Shared_Image, it will try to load the image in "any" supported
> format (see the pixmap_browser demo in the test folder for a worked
> example of this.)

Ah, ok, thanks.

> > > For manipulating the "raw" data of the image, there's a howto here:-
> > >
> > > http://www.fltk.org/articles.php?L468
> >
> > If I'm right, that should even work for OpenCV MAT images, with one
> > tweak:
> >
> > r = (unsigned char)datap[idx];
> > g = (unsigned char)datap[idx + 1];
> > b = (unsigned char)datap[idx + 2];
> >
> > becomes
> >
> > b = (unsigned char)datap[idx];
> > g = (unsigned char)datap[idx + 1];
> > r = (unsigned char)datap[idx + 2];
> > a = (unsigned char)datap[idx + 3]; // if there's an alpha channel
>

> I can't comment on the byte order in a MAT,

It's reversed: BGR, BGRA, etc.

> but the fltk byte order is r,g,b,[a] (where the a is optional) so you
> need to order the bytes you are reading to get them into the fltk
> "surface" in that order. Note that is RGBA, not BGRA...

I do know that there is a custom widget that handles MAT images, but
it's GPL, and my project isn't. So I know it CAN be done ... just not
how to do it. Perhaps it does what I thought I was doing---just reverse
the order for display purposes, but leave it as is for passing to OpenCV
for processing. That's just a guess, of course.

> > But there's one part I definitely don't understand:
> >
> > if ((xc < xoff) || (xc > (200 - xoff))) {
> > puts("X click not in image area");
> > fflush(stdout);
> > return ret;
> > }
> > if ((yc < yoff) || (yc > (200 - yoff))) {
> > puts("Y click not in image area");
> > fflush(stdout);
> > return ret;
> > }
>
> Way back when, someone had asked how to tell if a mouse click fell in
> the image area or not

Ahh, yes, I should have seen that. Wasn't able to have my coffee yet.[1]
I'm not "all there" until I have my coffee. :-)

Thanks,
--jim


[1] One of the post-cancer #1 meds I'll be on for the rest of my life
has to be taken first thing in the morning, on an empty stomach, and
you can't have anything to eat or drink for the next 45--60 minutes.
I'd just taken it.

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >
spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W
http://fineartamerica.com/profiles/4-james-graham.html

"Beer is proof that God loves us, and wants us to be happy."
--Benjamin Franklin

[Jim Graham]

On Fri, Mar 06, 2015 at 12:24:44PM +0000, MacArthur, Ian (Selex ES, UK) wrote:

> I can't comment on the byte order in a MAT, but the fltk byte order is
> r,g,b,[a] (where the a is optional) so you need to order the bytes you
> are reading to get them into the fltk "surface" in that order. Note
> that is RGBA, not BGRA...

I have an easier idea now---one I should have thought of before, given
that I've done this before for an Android project (UltraCamPro). In
the FLTK image window, I work with "normal" formats (jpg, png, gif, and
tiff, if it's supported---if not, if a tiff is loaded, I'll convert it
to png with zero compression, and when loading into ANY OpenCV process,
convert to Mat, but show changes in more or less real time in an FLTK
window in its original format (i.e., convert back and forth). It'll
work, but the only question is whether or not it will be acceptably fast.
That, I'm about to test.....

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) | "This 'telephone' has too many
spook...@gmail.com | shortcomings to be seriously considered
< Running Mac OS X Lion > | as a means of communication. The device
ICBM / Hurricane: | is inherently of no value to us."
30.44406N 86.59909W | (Western Union internal memo, 1876)
http://fineartamerica.com/profiles/4-james-graham.html

[imm]

On Mar 6, 2015 4:27 PM, "Jim Graham" wrote:
>
>  In
> the FLTK image window, I work with "normal" formats (jpg, png, gif, and
> tiff, if it's supported---if not, if a tiff is loaded, I'll convert it
> to png with zero compression, and when loading into ANY OpenCV process,
> convert to Mat, but show changes in more or less real time in an FLTK
> window in its original format (i.e., convert back and forth).  It'll
> work, but the only question is whether or not it will be acceptably fast.

To be honest, fltk is perfectly happy with a simple array of RGBA data, as per the howto I linked to earlier.

So I'd recommend using the Fl_Shared_Image to load the image then recovering the underlying data() array for use.

Flipping data between fltk's RGBA format and MAT's BGRA format is fairly trivial with a modern (SSE, AVX, NEON, etc) equipped CPU, though you may need to use the compiler intrinsics, which can make the source code less portable...
--
Ian
Sent, perhaps surprisingly, from my Fairphone FP1

[Jim Graham]

On Sat, Mar 07, 2015 at 09:50:49AM +0000, imm wrote:
> On Mar 6, 2015 4:27 PM, "Jim Graham" wrote:
> >
> > In
> > the FLTK image window, I work with "normal" formats (jpg, png, gif, and
> > tiff, if it's supported---if not, if a tiff is loaded, I'll convert it
> > to png with zero compression, and when loading into ANY OpenCV process,
> > convert to Mat, but show changes in more or less real time in an FLTK
> > window in its original format (i.e., convert back and forth). It'll
> > work, but the only question is whether or not it will be acceptably fast.

Update: I noticed just yesterday that adjustments to images don't
actually show up in real-time...only after you stop moving the slider,
stop changing the numbers, etc. So a quick MAT-->[image format]
conversion and re-draw in the window would be trivial. In other words,
I don't need to worry about having to do a continuous series of
conversions...just one, after the input has stopped.

So here's what my plan basically looks like:

Image (main, loaded and displayed) ---> user calls image processing x
|
.------------------------------------------------'
|
|
`---> Copy main image into image processing preview window

Copy image data to MAT data
Run image processing method on MAT data with default values
Keep MAT data AND convert to [image format] and update in preview

No MAT images need to be displayed in a FLTK window at all. And, I
just thought of something else. The preview image will be a small
(say, around 240px on one axis (which would depend on aspect ratio---if
using 240px on the larger axis made the smaller axis microscopic, then
some adjustments would have to be made).

> Flipping data between fltk's RGBA format and MAT's BGRA format is fairly
> trivial with a modern (SSE, AVX, NEON, etc) equipped CPU, though you may
> need to use the compiler intrinsics, which can make the source code less
> portable...

And that's a problem. I want this to be availble on Mac, Linux, and the
doze. Keeping everything as portable as possible definitely helps in
that goal....

I'm going to build the test windows (slidebars, number entry, etc.,
along with the preview display---small copy of the original) today, and
run some basic image processing routines using OpenCV.

And here's a question (sorry, not quite on-topic): does anyone know how
"undo" is normally handled? I'm guessing that undoing filters that
destroy image data can't just be undone, so is it more of a start with
the original and repeat everything up to but not including the last
operation?

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >
spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W
http://fineartamerica.com/profiles/4-james-graham.html

BOFH Excuse for the day:

[Ian MacArthur]

On Sat Mar 07 2015 14:07:07, Jim Graham wrote:

>> Flipping data between fltk's RGBA format and MAT's BGRA format is fairly
>> trivial with a modern (SSE, AVX, NEON, etc) equipped CPU, though you may
>> need to use the compiler intrinsics, which can make the source code less
>> portable...
>
> And that's a problem. I want this to be availble on Mac, Linux, and the
> doze. Keeping everything as portable as possible definitely helps in
> that goal....

The “portability” issue in this case is not across host OS, it is across core CPU architecture. What I’m proposing is to use SSE (say, if it is an “intel” architecture) to do the flip between RGBA and BGRA or whatever, format. Indeed, this is just the sort of thing that the vector engines were added to the CPU cores to address.

So, since Windows, OSX and a lot of Linux boxes are using x86 cores capable of SSE, then that are all “the same” in this regard. The issue arises if you hit a machine *without* SSE, or are running on ARM where you’d need to use the equivalent NEON simd operations.

Of course, to do this right, you ought to test for the presence of SSE (or NEON) and fallback to doing it the hard way of the simd engine is not found.

(NEON is pretty good, but there’s still a lot of ARM machines out there that do not have it, and it isn’t entirely certain that any x86 machine will support SSE, though it nearly is!)

Note that in all this I,m ignoring the PPC/Altivec paring; sad to tell that seems to have faded, which is a shame as I spent a great many years happily programming PPC/Altivec machines...

>
> And here's a question (sorry, not quite on-topic): does anyone know how
> "undo" is normally handled? I'm guessing that undoing filters that
> destroy image data can't just be undone, so is it more of a start with
> the original and repeat everything up to but not including the last
> operation?

The answer is “It depends.”

a) Sometimes it is better to keep a record of all the changes since the last save, and replay all but the last one to “undo” the last operation.

b) Sometimes it is better to keep a record of all the changes and revert them one by one, from the most recent back.

c) Other strategies, depending on the nature of the data and operations on it...

If the changes are very lossy, reverting them may not be feasible at all, so (a) may be best, that sort of thing.

[Jim Graham]

On Sun, Mar 08, 2015 at 10:25:53PM +0000, Ian MacArthur wrote:
> On Sat Mar 07 2015 14:07:07, Jim Graham wrote:

> So, since Windows, OSX and a lot of Linux boxes are using x86 cores

> capable of SSE, then that are all ???the same??? in this regard. The

> issue arises if you hit a machine *without* SSE, or are running on ARM

> where you???d need to use the equivalent NEON simd operations.

>
> Of course, to do this right, you ought to test for the presence of SSE
> (or NEON) and fallback to doing it the hard way of the simd engine is
> not found.

First, I didn't understand a bit of that. Second, as long as imread,
imencode, imdecode, mat.channels(), mat.size(), mat.convertTo, and
mat.copyTo all work, and as long as FLTK works, it should all work
fine. If those don't work then there's a compatibility problem with
OpenCV and/or FLTK (that, or I just need to find a way to compile on
yet another system I don't have).

I thought I wrote all of this in a file last night, but apparently,
I didn't. The idea is, load the file as a Mat, get all of the specifics
(X size, Y size, number/type of color channels, image type, etc.) from
OpenCV, then convert to that image type and load in the appropriate
Fl image window. For changes, convert to Mat, scale it down to a good
preview size, do the changes, and if/when the user accepts the changes,
repeat the process, including the user's changes, for the real image.

Obviously, it's not quite that simple for everything, but it's a start.
Some operations will be more natural in the Fl image window on the real
image.

> (NEON is pretty good, but there???s still a lot of ARM machines out

There are PCs running ARM? That's news to me, though it doesn't surprise
me.

> > And here's a question (sorry, not quite on-topic): does anyone know how
> > "undo" is normally handled? I'm guessing that undoing filters that
> > destroy image data can't just be undone, so is it more of a start with
> > the original and repeat everything up to but not including the last
> > operation?

I found the answer to that one on Stack Overflow. GIMP, PhotoShop, and
most others keep a copy in memory for each level of undo to be supported.
I'm guessing, from that, that the really huge files will have far fewer
undo levels. The other way is, of course, to start fresh and work your
way back forward. Reversing changes is unreliable, as, for example, if
you convert to grayscale, you can't undo back to color; or if you blur
the image, you can't just undo the blur to get the detail back.

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) | Peter da Silva: No, try "rm -rf /"
spook...@gmail.com | Dave Aronson: As your life flashes before
< Running Mac OS X Lion > | your eyes, in the unit of time known as an
ICBM / Hurricane: | ohnosecond.... (alt.sysadmin.recovery)
30.44406N 86. 59909W |
http://fineartamerica.com/profiles/4-james-graham.html

[Francesco Piscani]

Hello Vincent,

Thank you very much for the input. 

I have tried to use your Fl_Viewer.cpp and Fl_Viewer.h and try to access with a main file to load an image with opencv and then view it through fltk but have been unsuccessful.  Do you have any test.cpp or main.cpp snippets that use your implementation and header files.

Thank you in advance.

Francesco

[Edzard Egberts]

Francesco Piscani wrote:

> load an image with opencv and then view it through fltk

The first part is easy, because by using cv::Mat::imread() a OpenCV Mat
can load nearly every type of image, when there is a valid extension given.

For viewing a cv::mat with fltk I wrote a method, to change a Mat to a
Fl_Image, which is easy to display:

You can display the Fl_Image by overwriting a FLTK::draw() method and
use Fl_Image::draw(x, y, w, h) directly or do some scaling using
Fl_Image::copy(w, h):

Fl_Image* Scale= mp_Pic->copy(m_pw, m_ph);
Scale->draw(x() +m_ox, y() + m_oy, m_pw, m_ph);

[crocher...@gmail.com]

Unless you are really after some specific functionalities of Fl_ViewerCV (callbacks, specific resizing, zomm etc...), I would suggest to go with Ed solution which is a lot cleaner than the Fl_ViewerCV which has been wrote (and tweaked!) for my specific needs.

Anyway, if you are still keen on using it I attach you a minimal example for it (and simple Makefile).

[Francesco Piscani]

 Hello Gentlemen,

Thank you for the input. Greatly appreciated.  I knew there was an easier way, without having to reinvent the wheel.

[danielc...@gmail.com]

Hi

I want to contribute with an example for came capture.

regards