siptoolbox-devel — Development and advanced discussion

[SIP-devel] bug in interfeometry-gui

[DRUEL J. <joc...@li...>]

Hi,
The function snap1() in the gui asked for a filename but did not use it.
I send a corrected version in which I added tests in video1() and snap1() to 
be sure the user is on a Linux box with xawtv installed (or running).
That's the only change I did.

Best regards
Jocelyn

-- 
Powered by Linux

Re: [SIP-devel] pb with mogrify -draw

[Ricardo F. <rf...@if...>]

On Fri, 5 Sep 2003, DRUEL Jocelyn wrote:

> Le Jeudi 4 Septembre 2003 14:10, vous avez =E9crit :
> >
> > I don't know exactly how to solve this.  Maybe SIP's mogrify should
> > have one parameter for each commandline argument, like this:
> >
> > b=3Dmogrify('arara.jpg','-draw','circle 10,10 15,15');
> >
> > This should be easy to do.
> > If everybody agrees I'll code it as soon as I can.
>
> It's allright for me, but I think users would then expect to write
> b=3Dmogrify('arara.jpg','-median','2');
> and not
> b=3Dmogrify('arara.jpg','-median 2');
>

That's OK, it won't cause an error.

>
> I saw on the todo list that mogrify was not working with color images.
> Can't we simply use the function cmogrify (color mogrify) that I send ?
>

As a temporary solution, yes.
But some functions in mogrify works directly on the color image. For
  example: mogrify -draw 'circle 10,10 15,15' -foreground rgb:0:9:5
  or: mogrify -segment

cheers,
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  www.rfabbri.kit.net

Re: [SIP-devel] images fft + contrib mkfftfilter

[DRUEL J. <joc...@li...>]

Le Jeudi 4 Septembre 2003 14:17, vous avez écrit :
> On Tue, 2 Sep 2003, DRUEL Jocelyn wrote:
> > > 	spectrum = abs(IM).*conj(IM)
> >
> > I suppose you mean: spectrum=real(IM.*conj(IM))
>
> OPS, sorry,
> not even "real" is needed.
> spectrum=IM.*conj(IM) already gives a real power spectrum
>

In theory...but Scilab still considers the spectrum matrix as imaginary:
imshow(spectrum,[]) does not work. So, I think that the "real" is compulsory.

I suggest the following contribution which is named mkfftfilter: in order to 
ease this type of spectrum filtering, the function returns commonly used 
transfert functions. The filtering is made in 3 or 4 lines:

image=gray_imread(SIPDIR+'images/ararauna.jpg');
IM=fft(image,-1);
h=mkfftfilter(image,'butterworth',20);
IM2=IM.*fftshift(h);//spectrum modification
im2=real(fft(IM2,1));
Done...

I hope it could be a good introduction to spectrum filtering.

Best regards
Jocelyn

-- 
Powered by Linux

Re: [SIP-devel] pb with mogrify -draw

[DRUEL J. <joc...@li...>]

Le Jeudi 4 Septembre 2003 14:10, vous avez écrit :
>
> I don't know exactly how to solve this.  Maybe SIP's mogrify should
> have one parameter for each commandline argument, like this:
>
> b=mogrify('arara.jpg','-draw','circle 10,10 15,15');
>
> This should be easy to do.
> If everybody agrees I'll code it as soon as I can.

It's allright for me, but I think users would then expect to write
b=mogrify('arara.jpg','-median','2');
and not 
b=mogrify('arara.jpg','-median 2');


I saw on the todo list that mogrify was not working with color images.
Can't we simply use the function cmogrify (color mogrify) that I send ?

Best regards
Jocelyn

-- 
Powered by Linux

Re: [SIP-devel] pb with mogrify -draw

[Ricardo F. <rf...@if...>]

On Sun, 31 Aug 2003, DRUEL Jocelyn wrote:

> Hi,
> Did anybody succed in using the function draw of mogrify within SIP ?
>
> a=gray_imread('ararauna.jpg');
> b=mogrify(a,'-draw circle 10,10 15,15')
>
> The answer is "Non conforming primitive definition".

SIP's mogrify parsing of mogrify's arguments must be improved.

In the command line, ImageMagick would be used like this:

convert -draw 'circle 10,10 15,15' ararauna.jpg ararauna2.jpg

As you see, parameter "circle 10,10 15,15" is passed as a single
string to the program.

I don't know exactly how to solve this.  Maybe SIP's mogrify should
have one parameter for each commandline argument, like this:

b=mogrify('arara.jpg','-draw','circle 10,10 15,15');

This should be easy to do.
If everybody agrees I'll code it as soon as I can.

thanks for reporting,
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  www.rfabbri.kit.net

Re: [SIP-devel] SIP to-do list

[Ricardo F. <rf...@if...>]

On Sun, 31 Aug 2003, DRUEL Jocelyn wrote:

> Hi,
> Back from holliday in Australia,

Don't need to tell it was fun!

> I see you've been active during summer.
> Great.

I've been quite busy lately with many exams for applying to graduate
study in Brazil and abroad. It's a pain in the ..., but it should be
worth the hassle.

> I see there are things to do for SIP developpers !

We need more developers like you :)

>
> I'm trying to write some documentation (an introductory user manual) for SIP
> as I believe that the best documentation is not the one written by the main
> developper (ie Ricardo) but the one written by users.
>
> I send you my work, which is very incomplete but a good step (I hope) to
> start with SIP.
> I'd like to explain some notions about image treatment in it.
>
>

It's a very nice start!!!!!!!! Great!

I've been writing a paper about SIP and Scilab for a linux journal,
but its too big. I must split it in two. I'll send it directly to you
because it has some nice image processing examples and other stuff
that may help with the manual.

In the future we should place documentation in CVS so everybody can
make improvements directly and easily.

In the meantime.. Let's do it the hard way.
I'm sending some suggestions to the manual's draft.

- home page address is:  http://siptoolbox.sourceforge.net
- demo is now exec(SIPDEMO)
- should say to put stacksize(3e8) in users ~/.scilab
- reading/viewing/writing images
	- should explain briefly the different image formats and
	that it is necessary to rescale an image to 65535 to write it.
	(this is really a cumbersome characteristic of SIP, but we
	have to rescale the image until integer formats be used)
	See the paper on SIP that I wrote. It has a brief explanation
	that should help you with the manual.

	You do explain about this in sec 2.7 but shouldn't it
	come before sec. 2.4?

- in sec. 2.8, the command normal(dmat,255,0) should be easily
rewritten to normal(dmat,255)
- in Chap 3, the final version of the manual should ideally show the
result of the operations on sample images.
- par 3.3 typo (addition or subStraction..); it should be subtraction


That's all,
I hope you get the time to continue with the manual.
However, an advantage of free software development is that any work
you do is never lost. If you can't finish it, others will (someday), because
they are free to do it.

thanks again!
best,
Ricardo.

[SIP-devel] pb with mogrify -draw

[DRUEL J. <joc...@li...>]

Hi,
Did anybody succed in using the function draw of mogrify within SIP ?

a=gray_imread('ararauna.jpg');
b=mogrify(a,'-draw circle 10,10 15,15')

The answer is "Non conforming primitive definition".

Any suggestion ?
Best regards
Jocelyn


-- 
Powered by Linux

Re: [SIP-devel] SIP to-do list

[DRUEL J. <joc...@li...>]

Hi,
Back from holliday in Australia, I see you've been active during summer. 
Great.
I see there are things to do for SIP developpers !

I'm trying to write some documentation (an introductory user manual) for SIP 
as I believe that the best documentation is not the one written by the main 
developper (ie Ricardo) but the one written by users.

I send you my work, which is very incomplete but a good step (I hope) to 
start with SIP. 
I'd like to explain some notions about image treatment in it.

Feel free to send me critics or comments on it (even on english grammar as 
I'm not a native english).

The file format is dvi (I use latex to produce it) but I can send a pdf file 
(much bigger) if anyone is in trouble with dvi. Or I can send my latex source 
is someone is interested in it.

Best regards
Jocelyn Druel


Le Lundi 4 Août 2003 18:50, vous avez écrit :
> Dear co-developers,
>
> There is a new tasklist at Sourceforge. You may see where you
> could help, and also track how SIP is evolving:
>
> 	http://sourceforge.net/pm/?group_id=68055
>
> Please browse the unassigned tasks to see if you can actively join SIP
> development.  The tasks that I'm currently involved may be browsed by
> user "ricardofabbri".
>
> Any suggestions will be appreciated.
>
> Best regards,
> Ricardo.

-- 
Powered by Linux

[SIP-devel] New dev release

[Ricardo F. <rf...@if...>]

Dear co-developers,

a new development version is available. The main change is the new
watershed function for image segmentation. It accepts markers.  There
is a nice example in the help page, showing how to separate overlying
objects in a binary image.

SIP 0.3.0 is about to come, so it will be specially important to have
feedback from you in the next weeks.

There are also many advances to SIP's core library, called
Animal (An IMAging Library, http://animal.sf.net). In particular, It
is nice to have started using Gandalf library
(http://gandalf-library.sf.net).  Together with the IFT (Image
Foresting Transform), this will provoke an avalanche of new operators.
It is just a matter of time.

Here is the new features for Animal

0.7.0
   + Fast Watershed transform by IFT (function watershed in
   morphology.h)
   + Regional minima detection by IFT (regional_minima in
   morphology.h)
   + IFT procedures and framework were rewritten. They are more
   general.  One may readily implement many image processing operators
   using it, specially segmentation operators.
   + In file analysis.c we changed the way propagation functions are
   called (parameters, etc).
   + Many bugfixes to the propagation routines, which affects
   euclidean distance transforms and multiscale skeletonization.
   + Error treatment has been improved in some routines, by making use
   of lib Gandalf's error treatment scheme.


Animal and SIP-dev installs easily under Linux. Any problems please
write to this list.

Enjoy!
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  www.rfabbri.kit.net
  "Quality and Quantity both matter, but nowadays we miss Quality"

[SIP-devel] SIP to-do list

[Ricardo F. <rf...@if...>]

Dear co-developers,

There is a new tasklist at Sourceforge. You may see where you
could help, and also track how SIP is evolving:

	http://sourceforge.net/pm/?group_id=68055

Please browse the unassigned tasks to see if you can actively join SIP
development.  The tasks that I'm currently involved may be browsed by
user "ricardofabbri".

Any suggestions will be appreciated.

Best regards,
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  www.rfabbri.kit.net
  "Quality and Quantity are both good, but nowadays we miss Quality"

[SIP-devel] Re: new development release!

[Ricardo F. <rf...@if...>]

Download sip-dev at:

	http://siptoolbox.sf.net/devel

Ricardo.
On Mon, 4 Aug 2003, Ricardo Fabbri wrote:

>
> sip-dev 20030804 has just been released:
> ...

[SIP-devel] new development release!

[Ricardo F. <rf...@if...>]

Dear co-developers,

sip-dev 20030804 has just been released:

   + New function: bwdist, for distance tranform. A new very fast
   exact euclidean method is available (Lotufo-Zampirolli 2001).

   + New function: imnoise, to generate a few types of noise, such as
   gaussian white noise, salt & pepper, and more.

   + im2gray and gray_imread are now much faster

   + im2bw threshold is by default taken relatively to the maximum value
   of the image, instead of 255. This approach is more convenient.

   + autoreconf now works without any error messages


It installs easily under Linux or Unix platforms, as long as you
install the dependencies first, which are:
	- www.imagemagick.org
	- http://gandalf-library.sourceforge.net
	- http://animal.sourceforge.net

have fun :)
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  www.rfabbri.kit.net
  "Quality and Quantity are both good, but nowadays we miss Quality"

Re: [SIP-devel] images fft

[Ricardo F. <rf...@if...>]

> I wanted too to:
> 1) calculate the spectrum of an image
> 2) modify the spectrum
> 3) apply a reverse fourier transform to see modifications on the original
> picture (strioscopy, foucaultage).
> But I don't know how to perform a reverse fourier transform with scilab.

Hello, Jocelyn,

Sorry for the long delay. It is a bit confusing to use the DFT, but it
is not hard once you get used to it. (I apologize if you already know
some of the stuff I'm going to say).

It seems that all you want is to calculate the image power spectrum centered
on the array.
It is simple:
	// im is a grayscale image
	IM = fft(im,-1);

	// powerspectrum = |IM|^2
	// (you could use only abs, too).
	spectrum = abs(IM).*conj(IM)

	// to center the power spectrum
	spectrum = fftshift(spectrum);

	imshow(spectrum,[]);

To visualize low frequencies, I don't think you need to threshold
like you did:

	imshow(log(spectrum + 1),[])

That simple trick greatly enhances the pow.spectrum (see Gonzalez & Woods
Digital Image Processing book).

	// reverse tranform
	im2 = real( fft(IM,1) );

To modify the spectrum and take the inverse fft, the code of SIP's
gsm2d helps you understand how it is done.  Roughly speaking, you have
to remind that Discrete Fourier Transforms understand the spectrum as
a finite window of a period over the whole continuous infinite
spectrum with period T. By convention (I guess) DFTs choose NOT the
window _arround_ the origin, but the window _starting_ at the origin.
So what you have to do is:
	1 - Modify the spectrum. Before this, centralize it if you want
	(using fftshift), or calculate shifted coordinates, like I did
	in gsm2d.
	2 - Pass it to the inverse FFT. HOWEVER, if you used fftshift,
	you must first use it again to re-wrapp your image to the
	conventional form that FFT understands it.

BTW, I saw in the help file that you use the following construct to
show an image and normalize it:

	imshow(normal(spectrum1,255,0));

It is equivalent and easier like this:

	imshow(spectrum1,[]);

Thanks again for your active engagement in SIP development.
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  www.rfabbri.kit.net
  "Quality and Quantity are both good, but nowadays we miss Quality"

[SIP-devel] images fft

[DRUEL J. <joc...@li...>]

Hi,
A function to obtain the frequency spectrum of an image.
My problem with scilab's fft function was that the result did not correspond 
to what I saw each time I performed a Fraunhoffer diffraction.

So I moved low frequencies from the edges to the center and added a few 
parameters to help visualisation of details in the spectrum.

I wrote this function to
1) illustrate (and simulate) diffraction by several openings.
2) for a double exposition speckle experiment: an object is lightened by a 
laser beam: a 1st picture of the speckle is taken with a CCD camera. The 
object is then moved of several microns. A 2nd picture is taken.
Adding the 2 pictures and then launching a fft transfrom will show fringes. 
The space between fringes is related to the object displacement.

I'm really not a fft specialist so don't hesitate to criticize this work.
I wanted too to:
1) calculate the spectrum of an image
2) modify the spectrum
3) apply a reverse fourier transform to see modifications on the original 
picture (strioscopy, foucaultage).
But I don't know how to perform a reverse fourier transform with scilab.

Best regards
Jocelyn
-- 
Powered by Linux

Re: [SIP-devel] sip slow in windows

[Ricardo F. <rf...@if...>]

On Wed, 2 Jul 2003, DRUEL Jocelyn wrote:

> Hi,
> Testing sip in windows, I find it very much slower than under linux to
> display images.
> It refreashes the display very often and the refresh is too slow for me.
>
>
> Does anybody have a solution to improve speed on windows
> (scilab2-7 seems a bit faster than scilab-2.6)?
> My OS is win2k.
>

Hi, Jocelyn,

Scilab is awfully slow for displaying images. I'm thinking about
rewriting some of scilab's graphical functions to speed this process
up, but it will take me a lot of time.

In the meanwhile, You can try this in scilab 2.7:

xset("pixmap",1);   // pixmap mode

imshow(some_image)

xset("wshow")       // shows the pixbuffer in the screen at once

xset("pixmap",0);   // returns to normal mode


My friend which has a windows box is using it, so I won't be able to test that
solution until thursday.

Until then, please tell me if it works for you.
The drawback of this solution is that it may be hard to use subplot,
I think.

You should also post your question to the scilab newsgroup:
comp.soft-sys.math.scilab

hope it helps,
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  http://cyvision.if.sc.usp.br/~rfabbri

Re: [SIP-devel] auto-loading the sip toolbox in windows

[Ricardo F. <rf...@if...>]

On Wed, 2 Jul 2003, DRUEL Jocelyn wrote:

>
> I think, you could indicate that adding this line at the end of c:\program
> files\scilab-2.6\scilab.star can be good (if several users use the machine,
> there's no need to write several .scilab files for each of them):
> exec 'c:\program files\sip-0.1.0-win\loader.sce'
>

Agreed. Done  for next version.
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  http://cyvision.if.sc.usp.br/~rfabbri

[SIP-devel] sip slow in windows

[DRUEL J. <joc...@li...>]

Hi,
Testing sip in windows, I find it very much slower than under linux to 
display images.
It refreashes the display very often and the refresh is too slow for me.


Does anybody have a solution to improve speed on windows 
(scilab2-7 seems a bit faster than scilab-2.6)?
My OS is win2k.

Thanks
Jocelyn
-- 
Powered by Linux

[SIP-devel] auto-loading the sip toolbox in windows

[DRUEL J. <joc...@li...>]

Hi,
To have the automatic loading of the sip toolbox in windows, the install.txt 
file (in sip-0.1.1-win5) suggests that you modify the autoexec.bat and use 
.scilab files.

I think, you could indicate that adding this line at the end of c:\program 
files\scilab-2.6\scilab.star can be good (if several users use the machine, 
there's no need to write several .scilab files for each of them):
exec 'c:\program files\sip-0.1.0-win\loader.sce'

For me, it's a more convenient solution.

Best regards
Jocelyn


-- 
Powered by Linux

Re: [SIP-devel] new interf_demo + pbs

[DRUEL J. <joc...@li...>]

Hi Riccardo,
I hope your exams were all right.
I send you a new version of the gui:


Le Mardi 1 Juillet 2003 00:47, vous avez écrit :
> On Sat, 21 Jun 2003, DRUEL Jocelyn wrote:
> > 2) 2 functions to take pictures from a video camera using xawtv. We use a
> > cheap miroPCTV for this (about 50$). This works on linux only of course.
>
> Cool. I suggest that you check if the xawtv command is available
> before calling it. But this is not very important.
>
Good idea.
I did a message if we're under windows but I don't know how to test the 
existence of xawtv from within scilab.

There was a syntax error in the function snap1: 2 , instead of 1 in the 
name=xgetfile...
This is now corrected.

> > 3) modifications to use gray_imread:
> > I replaced many gray_imread by gray_imread/2555 because I had problems
> > with displaying or tracing profiles. I don't exactly know why.
>
> This is due to the fact that you read your .jpg images, which are
> pseudo-color (indexed). What you probably did before imread was to use
> the index of the image, which points to 256 different colors in the
> colormap. The colors in the colormap goes from 0 to 65535, so you must
> divide by __257__ to get the 0-255 range (65535 / 257 == 255).
>

ok, I changed my division factor from 255 to 257



> > The gray_imread function is much much slower than imread when I read
> > grayscale pictures. A test on my box gave: 2.4 and 0.26 (estimated by
> > timer()). That's a pb for me (specially as I read several images to make
> > some calculations).
>
> gray_imread (because of im2gray) is really very slow, I haven't
> noticed that before.  I optimized im2gray to eliminate a for loop (see
> attachment). gray_imread is much faster now. In scilab any loop over
> an image is prohibitive :-((. It is ok just for "thumbnail-sized"
> images, when we need to prototype an algorithm.
>
> I could implement im2gray in C, but the trick I done in gray_imread
> saved me some development time. But if it is still slow, please tell me.
>

The speed is now all right for me.


I have a pb with the mogrify function:
I tested b=mogrify(image, '-draw circle 100,100 150,150')
the answer is: non conforming drawing primitive definition
I saw that "draw" is the only options which requires a string. Is it the 
problem ?
Well, if you have a solution, maybe you could add it in the examples of the 
help page.


Best regards
Jocelyn

-- 
Powered by Linux

Re: [SIP-devel] new interf_demo + pbs

[Ricardo F. <rf...@if...>]

On Sat, 21 Jun 2003, DRUEL Jocelyn wrote:

> 2) 2 functions to take pictures from a video camera using xawtv. We use a
> cheap miroPCTV for this (about 50$). This works on linux only of course.

Cool. I suggest that you check if the xawtv command is available
before calling it. But this is not very important.

> 3) modifications to use gray_imread:
> I replaced many gray_imread by gray_imread/2555 because I had problems with
> displaying or tracing profiles. I don't exactly know why.

This is due to the fact that you read your .jpg images, which are
pseudo-color (indexed). What you probably did before imread was to use
the index of the image, which points to 256 different colors in the
colormap. The colors in the colormap goes from 0 to 65535, so you must
divide by __257__ to get the 0-255 range (65535 / 257 == 255).

>
> The gray_imread function is much much slower than imread when I read
> grayscale pictures. A test on my box gave: 2.4 and 0.26 (estimated by
> timer()). That's a pb for me (specially as I read several images to make some
> calculations).
>
gray_imread (because of im2gray) is really very slow, I haven't
noticed that before.  I optimized im2gray to eliminate a for loop (see
attachment). gray_imread is much faster now. In scilab any loop over
an image is prohibitive :-((. It is ok just for "thumbnail-sized"
images, when we need to prototype an algorithm.

I could implement im2gray in C, but the trick I done in gray_imread
saved me some development time. But if it is still slow, please tell me.

> Why not modify the gray_imread so that with a grayscale image, it does simply
> an imread ? Does it cause pbs ?

Yes, it causes problems, because there is no fast way (in scilab) to
know if a pseudo-color (indexed) image is grayscale or color. It
depends on the colormap. Even if it is grayscale, the intensity
distribution in the colormap may be different from the numbers in the
index image.  Although this is not common, may happen.

What you've been doing is using directly the index image and assume
that the colormap has a linear intensity distribution, so it can be
discarded. This will work only with your particular images, but may
fail with other images.

best regards,
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  http://cyvision.if.sc.usp.br/~rfabbri

Re: [SIP-devel] new interf_demo + pbs

[Ricardo F. <rf...@if...>]

Hi!

I've been busy having many exams here at the University,
especially a hard one about partial differential equations.
But this will enable me to learn and implement more advanced methods in
SIP, namely those based on level sets for segmentation and filtering.

Soon I'll incorporate your last developments and continue with SIP.

regards,
Ricardo.

On Sat, 21 Jun 2003, DRUEL Jocelyn wrote:

> Hi,
> Still working on my gui (renamed interferometry_demo by Ricardo), I send you
> my last developments.
> The main differences from the interferometry_dem included in the developement
> distribution are:
> 1) a new menu: laser beams to display and calculate gaussian profiles (test
> with the laser_beam image sent)
> 2) 2 functions to take pictures from a video camera using xawtv. We use a
> cheap miroPCTV for this (about 50$). This works on linux only of course.
> 3) modifications to use gray_imread:
> I replaced many gray_imread by gray_imread/2555 because I had problems with
> displaying or tracing profiles. I don't exactly know why.
>
> The gray_imread function is much much slower than imread when I read
> grayscale pictures. A test on my box gave: 2.4 and 0.26 (estimated by
> timer()). That's a pb for me (specially as I read several images to make some
> calculations).
> Why not modify the gray_imread so that with a grayscale image, it does simply
> an imread ? Does it cause pbs ?
>
> Best regards
> Jocelyn
>

[SIP-devel] new interf_demo + pbs

[DRUEL J. <joc...@li...>]

Hi,
Still working on my gui (renamed interferometry_demo by Ricardo), I send you 
my last developments.
The main differences from the interferometry_dem included in the developement 
distribution are:
1) a new menu: laser beams to display and calculate gaussian profiles (test 
with the laser_beam image sent)
2) 2 functions to take pictures from a video camera using xawtv. We use a 
cheap miroPCTV for this (about 50$). This works on linux only of course.
3) modifications to use gray_imread:
I replaced many gray_imread by gray_imread/2555 because I had problems with 
displaying or tracing profiles. I don't exactly know why.

The gray_imread function is much much slower than imread when I read 
grayscale pictures. A test on my box gave: 2.4 and 0.26 (estimated by 
timer()). That's a pb for me (specially as I read several images to make some 
calculations). 
Why not modify the gray_imread so that with a grayscale image, it does simply 
an imread ? Does it cause pbs ?

Best regards
Jocelyn 
-- 
Powered by Linux

Re: [SIP-devel] a gui for sip

[Ricardo F. <rf...@if...>]

> The 1st thing is that I need the normalize function for some image
> manipulations.

OK. We could keep automatic normalization at imshow only, it
would simpler to newbies. But if you need to display images
un-normalized, then pls forget what I said...

> The 2nd is about the TODO section: I really like the "Is it OK ?" dialog,
> because I can see the original picture and the modified one at the same time.
> I think a undo button would not be that convenient.

Indeed.

>
> I'm still working on this gui and I hope to send you soon a new version.

TIA,
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  http://cyvision.if.sc.usp.br/~rfabbri

Re: [SIP-devel] a gui for sip

[DRUEL J. <joc...@li...>]

Le Dimanche 25 Mai 2003 04:09, vous avez écrit :
>
> The demo is now using gray_imread and imshows the images using
> imshow(image,[]), which already normalizes the image to the 0-255
> range. I took off the menus "Nomalize" and "Convert to grayscale",
> please let me know if you still need the normalize menu.
>
> A new sipdev will be out in some hours from now with your new
> contribs/updates.
>

Hi,
I had a quick look to your modifications on the gui. 
The 1st thing is that I need the normalize function for some image 
manipulations.
The 2nd is about the TODO section: I really like the "Is it OK ?" dialog, 
because I can see the original picture and the modified one at the same time.
I think a undo button would not be that convenient.

I'm still working on this gui and I hope to send you soon a new version.

Best regards
Jocelyn

-- 
Powered by Linux

[SIP-devel] new sip-devel

[Ricardo F. <rf...@if...>]

Hi,

a new sip-devel package is out:
https://sourceforge.net/project/showfiles.php?group_id=68055&release_id=161483

The main changes are:
   + new "thin" (standard Zhang-Suen thinning) implemented in C
   + gray_imread (simply to read every image as grayscale) manpage
   + improfile changed (it is now incompatible with the previous one)
   + manpage for perim
   + new example figures
   + requires Animal 0.5.0

have fun!
Ricardo.

--
  Ricardo Fabbri, Cybernetic Vision Research Group, USP, Brazil.
  http://cyvision.if.sc.usp.br/~rfabbri