IT-LIST Digest 19Topics covered in this issue include:  1) RE: Sample MSVC++ plug-in source	by Don Wilcox   2) RE: Adding a scanner to IT	by Don Wilcox   3) RE: Win95 Driver for DT3155 Frame Grabber	by Don Wilcox   4) RE: Hough transform (fwd)	by Don Wilcox   5) RE: Plugin Development	by Don Wilcox   6) RE: IT	by Don Wilcox   7) RE: tif	by Don Wilcox   8) Re: Zip-Files	by Peter Herdman   9) Re: Zip-Files	by Nick Beser ----------------------------------------------------------------------Date: Sun, 28 Apr 1996 16:53:28 -0700From: Don Wilcox To: 'ImageTool List Server' Subject: RE: Sample MSVC++ plug-in sourceMessage-ID: <>>From a quick look at the SDK, it appears that the file=20filter interface is hardwired to Borland OWL. We'd prefer=20to use MSVC++ simply because it's the devil we know=20(besides I've no room on disk for yet another 100Mb=20compiler suite )The file filter interface only supports OWL because it simplified the =problems for IT when I added stacks.  I wanted to use the built-in array =class, and at that time no one array class was supported by both. I =suppose I could re-write ImageTool to use STL...  Anyways, you can get =the effect you need by writing an acquisition plug-in, as there is an =interface for writing such plug-ins using standard Windows API calls.  =The interface is documented as the generic interface in the docs.  The =downside of using this interface is that you will not open your files =using the File | Open command, but a sub-command of the File | Acquire =menu.Is there a way to write file filter plug-ins without=20resorting to OWL and, for the purpose of getting=20started, has anyone got MSVC++ 2.0 sources for a working=20plug-in skeleton that does something rudimentary, e.g.,=20simply copying the existing image?There is a sample OWL file filter in the SDK, look for the file =photocd.cpp.  It uses a call from UTILib to load a PhotoCD file, giving =you the choice of which image to load.Don------------------------------Date: Sun, 28 Apr 1996 16:53:37 -0700From: Don Wilcox To: 'ImageTool List Server' Subject: RE: Adding a scanner to ITMessage-ID: <>----------From:[]Sent:  Wednesday, April 24, 1996 12:07 AMTo:  wilcox@xroads.comSubject:  Re: Adding a scanner to ITDescription of ImageTool's failure to properly do TWAIN deleted.=20Mmmm... May be the next release might have this bug licked.Unfortunately, it appears that something I did late in the last release =broke TWAIN.  To make sure that this never happens again, I have ordered =a Snappy to facilitate testing this feature.  Sorry.=20Don------------------------------Date: Sun, 28 Apr 1996 16:53:42 -0700From: Don Wilcox To: 'ImageTool List Server' Subject: RE: Win95 Driver for DT3155 Frame GrabberMessage-ID: <>We have seen the addition of the Win NT plug-in and eagerly await the=20Win 95 version.  Do you have an idea when, if ever, this will be =available?=20If not, is there any other way of acquiring images directly e.g. using =the=20Win 95 driver supplied with the card.Data Translations has promised a version of the Windows 95 driver very =soon, and it is our understanding that it should enable ImageTool to run =a DT3155 card under Win95 unchanged.  As soon as I get a copy, I will =test it and let everyone know.Keep up the good work!Thanks,Don------------------------------Date: Sun, 28 Apr 1996 16:53:48 -0700From: Don Wilcox To: 'ImageTool List Server' Subject: RE: Hough transform (fwd)Message-ID: <>----------From:  C Bower[]Sent:  Tuesday, April 23, 1996 9:53 PMTo:  wilcox@xroads.comSubject:  Hough transform (fwd)I know that the Hough transform can be used to identify lines or circles =in an=20image by exploring all the parameters of 'Hough Space' but I don't have=20the time (or expertise) to implement such an algorithm. I think that =such=20an algorithm would be extremly useful for a variety of image processing=20applications where the object of interest is Spherical (circular).(I also realise that the best way to facilitate thresholding would be to =improve the contrast in the original images, but this is proving =difficult) Is anyone planning to implement such an algorithm as a plug-in, or=20as an extra feature on the next version of Image Tool?I currently have no plans to implement such an algorithm.  If someone =were to want to write the Hough transform (and its not that difficult, I =am just working on other things), it would need to be added to ImageTool =itself so that the detected objects could be associated with the image.Don------------------------------Date: Sun, 28 Apr 1996 16:53:53 -0700From: Don Wilcox To: 'ImageTool List Server' Subject: RE: Plugin DevelopmentMessage-ID: <>----------From:[]Sent:  Tuesday, April 23, 1996 9:33 PMTo:  wilcox@xroads.comSubject:  Plugin DevelopmentI am considering writing ImageTool plugins and to familiarise myself =with it, I=20decided to try and compile the median.cpp source file obtained with=20ImageTool into a dll. I am using Borland C++ and have succeeded in=20compiling it, yet when Borland tries to link it, it gives four errors:Linker Error: Unresolved external 'RWDib::Depth() const' referenced from =  module MEDIAN.CPPLinker Error: Unresolved external 'RWDib::IsGrayScale() const' =referenced=20  from module MEDIAN.CPPLinker Error: Unresolved external 'RWDib::RWDib(const RWDib &)'=20  referenced from module MEDIAN.CPPLinker Error: Unresolved external 'RWDib::ActualWidth() const' =referenced=20  from module MEDIAN.CPPIs it looking for another library which I don't have? Do I need to =inform the=20linker to look for some other library? Or, is it something else?It is looking for the import library for UTILib.  The library resides =(on my machine), in the ,..\..\utilib directory.  IT is possible that I =failed to place it into the SDK, in which case you should run implib on =the shipping UTILib32.dll to create the import library.  Let me know how =this goes, I would like to see some more work on developing plug-ins.Don------------------------------Date: Sun, 28 Apr 1996 17:04:36 -0700From: Don Wilcox To: 'ImageTool List Server' Subject: RE: ITMessage-ID: <>----------From:  henry.valk[]Sent:  Thursday, April 04, 1996 11:54 AMTo:  wilcox@xroads.comSubject:  ITI have been playing around with Image Tools V1.23 to evaluate its =potential as processing=20software for an automated laboratory application and have observed the =following;1. There is only one available calibration process which is applied to =the whole image, ie,=20horizontal and vertical planes. Generally the spacial relationship in =these two planes will be=20different due to the lens used, the pixel spacing on the CCD and the =typical 4:3 aspect ratio of=20most imaging systems.If an image is calibrated in the horizontal plane, for example, then any =off axis measurements=20made will be in error.=202. In addition to item 1, there is no facility for mapping out any non =linearities during the=20calibration procedure,ie, if measurements are made in various parts of =the image there is no way=20of accounting for linearity variations at the edge of the image compared =to the centre of the=20image.It is possible to create a calibration file that describes a square =pixel image.  The format is described in the documentation.  There is no =interface for doing this within ImageTool because I have not come up =with what I consider a satisfactory interface.  If you have a suggestion =on how this might be done, let me know.3. There does not appear to be an automatic scroll option for making =measurements of objects=20which extend beyond the screen perimeter, typically for zoomed areas of =the image.This is difficult within the ImageTool architecture.4. There does not appear to be an area based histogram feature where the =area is selected by the=20user (Also very usefull for colour identification).We do not currently provide color histogram tool.  ImageTool grew out of =a radiology application, and so color support has not grown with the =application.  We are currently thinking about the types of things that =we would need to provide better color support, and will hopefully be =adding it in future releases.5. There is no facility to determine the distance between the rising =edge and falling edge of a=20typical line histogram, ie, it would be nice to be able to measure =something by applying a line=20histogram and defining a threshold to the data such that the distance =between two consecutive=20threshold values is given based on the spacial calibration applied.I had not thought of this.  I will add it to the open list.6. As per a previous message, colour images are not yet adequately =supported. In particular, a=20colour image can be separated to its primary constituent colours but no =histogram option can be=20applied to the sub images.=20If you take the separated imagesand apply the linear color table (in the =file Liean.pal) to each, you will get a grayscale image which you can =take a histogram of.  I added the color separation plug-in for just this =sort of analysis, since I knew I could not hope to get true color =support in in time for the release.7. Similarly, there is no option to classify a particular colour and =find all objects in a colour=20image of the same colour (with an applied tolerance).This is already on the list of features that would be needed for color =support.8. IT does no appear to support automatic loading and processing of =images. I believe that the=20source code is available though from which an embedded application may =be written.There is a rudimentary macro language for automating some tasks.  We are =designing a better language much like the macro language in NIH Image.Wish list :=20	A very handy DLL would be one that reads barcode labels for automatic =object=20identification. Either automatically identifying the barcode label type =and providing the barcode=20number or one DLL for each barcode type.I'm not sure what you mean.	Extension of the maths functions to perform volume calculations given =object=20characteristic information, ie, objects of type "x" are assumed to be =cylindrical, or spherical,=20etc, find volume of object. Similarly, object subtraction, ie, for all =objects of type "x",=20assumed to be cylindrical, find volume, subtract object of type "y", =assumed to be cylindrical,=20calculate total volume (handy for calculating the volume of the contents =of a vessel knowing the=20characteristics of that vessel).Interesting.  The object analysis plug-in could be easily modified to =provide this feature if someone wanted it (read: I probably won't get to =it, but it shouldn't be hard if someone else wanted to try).	This could also be extended to conditional math functions whereby the =volume of a=20particular coloured layer in a known vessel is determined by applying a =condition to the previous=20example of "colour type".Please let me know if any of my observations are incorrect or if I am =trying to use IT for=20something other than intended.=20Having said all this I would like to add that IT is good tool for image =processing and will=20likely evolve into an excellent tool in the near future.I'm glad you like it.  We have been pressing hard to get a feature set =that makes the app useful.  I'm hoping that as it grows in use that =other programmers will begin writing plug-ins to implement features that =are not in the mainstream of image processing problems, which is where I =(for obvious reasons) spend my efforts.Don------------------------------Date: Sun, 28 Apr 1996 17:07:12 -0700From: Don Wilcox To: 'ImageTool List Server' Subject: RE: tifMessage-ID: <>----------From:  Heberto Ghezzo[]Sent:  Monday, April 01, 1996 6:48 PMTo:  wilcox@xroads.comSubject:  Re: tifHi Brent, looks like I did not make myself clear.I 'load' an 8 bit TIFF image. loads is OK but I can not convert to=20gray scale to count things etc. The gray-convert works only with 24=20bits color.Then I 'load' a 24 bit TIFF image. Hi-Jack confirms that the image is=20'rgb' 3 bytes, but 'IT' does not like it and dumps me back to 'import'where it says 24 bit color, the proper size and asks for the size of =headerThere is something there that does not works. I can ftp the image in=20question if you want to try it.I am guessing that the file is compressed.  The recent decision by =Unisys to enforce the patent on LZW compression has made it impossible =for us to support TIFF-LZW files, and so the support was removed in =version 1.2On another line I tried to download ITSDK and the fifth or sith file=20has the zip header corrupt and the unzipping stops there. Can someone=20replace the zip file?The SDK file contains files with long filenames, and must be =uncompressed by a win 32 uncompresser like WinZip.  The old standby =pkzunzip 2.04g will not handle the file.Don------------------------------Date: Mon, 29 Apr 96 14:43:07 gmtFrom: Peter Herdman To: Image Tool List Subject: Re: Zip-FilesMessage-ID: All I can suggest is that your version of PK Unzip may be too old to unzip the ITool files - we have certainly experienced problems with old versions.  A hunt around the Web should yield the latest version (note that it is shareware!) and may solve your problems.Good LuckAndy FalconerArjo Wiggins Ltd.------------------------------Date: Mon, 29 Apr 1996 10:10:26 -0400 (EDT)From: Nick Beser To: it-list@sparky.uthscsa.eduSubject: Re: Zip-FilesMessage-ID: On Mon, 29 Apr 1996, Peter Herdman wrote:> All I can suggest is that your version of PK Unzip may be too old to unzip > the ITool files - we have certainly experienced problems with old > versions.  A hunt around the Web should yield the latest version (note > that it is shareware!) and may solve your problems.> > Good Luck> > Andy Falconer> Arjo Wiggins Ltd.> The version is the 32 bit WinZip for Windows 95. Can you tell me a version number that you know works?Nick Beser------------------------------End of IT-LIST Digest 19