Hi Group

Windows 2000 and XP are the recommended operating systems for image
processing in general and IP in particular. Windows 98 with 256 or
less RAM is a good second choice. I have heard a lot of probelms
with ME and would not recommend using it for image processing.
Windows 2000 and XP are preferred since they both have robust RAM
and virtual memory management. Check the size of your page file and
bump it up to match the amount of memory used by the images you
normally have open within reason.

I developed and tested most of the current version of IP under
Windows 98 on a 400Mhz Gateway with 128 RAM. This machine can work
reasonably well with 5 or 6 2160x1440 RGB images but it can be slow
and does a lot of paging memory to disk. A 1500Mhz Pentium 4 with

RDRAM makes IP run nicely with a group of 10 - 20 2160x1440 images
loaded. One of the big reasons for all of the current work with

crop, auto align and combine of a really large set of images of the
planets (100-500 or more images) is that processing this quanity of
data needs to be file based and not all in memory. In March and
April the crop, align, and combine functions for deep space objects
will be added to IP for the same reason.


IP was initially designed to be multi-threaded. The IP code issues

BeginThread() function and Windows decides which processor will run
the thread. Currently compute intense commands such as all of the
iterative restoration methods, adaptive histogram modification,
region growing, dilation, and erosion are multithreaded. Operators
that are multi-threaded diaplay a yellow frame around an image

the operation is executing and also have a Cancel button to stop

execution. If the Cancel button is used the current iteration is
finished before control is returned to the operator dialog box.

I am planning on adding several new multiresolution based operators
to IP this summer and they will all be multi-threaded.

Mike Unsold

I'm getting a lot of brouhaha about the new dual system I
have...let's go to the source...IP is multi-threaded...is it also
multi-processor enabled, or am I in one of those "vague areas" again?

IP was initially designed to be multi-threaded. The IP code issues a
BeginThread() function and Windows decides which processor will run
the thread. Currently compute intense commands such as all of the
iterative restoration methods, adaptive histogram modification,
region growing, dilation, and erosion are multithreaded. Operators
that are multi-threaded diaplay a yellow frame around an image while
the operation is executing and also have a Cancel button to stop the
execution. If the Cancel button is used the current iteration is
finished before control is returned to the operator dialog box.

Tom,

I'm getting a lot of brouhaha about the new dual system I
have...let's go to the source...IP is multi-threaded...is it also
multi-processor enabled, or am I in one of those "vague areas"

Mike's reply has the answer:

Being multi-treaded allows "Windows to decide which processor" to

you are going to get some bang from your multiprocessors! I'm

IP was initially designed to be multi-threaded. The IP code

BeginThread() function and Windows decides which processor will

the thread. Currently compute intense commands such as all of

iterative restoration methods, adaptive histogram modification,
region growing, dilation, and erosion are multithreaded.

that are multi-threaded diaplay a yellow frame around an image

the operation is executing and also have a Cancel button to stop

execution. If the Cancel button is used the current iteration is
finished before control is returned to the operator dialog box.

Ken

I'm currently in a "chat"
where the thinking is multi-threaded does not necessarily mean
multi-processor enabled.....

To me, in my mainframe mentality, if its a single-threaded app on a
multi-processor, you get single threaded service.

If its a multi-threaded/processor app running on a single
processor, you get single threaded service.

If its a multi-threaded app running on a multi-
processor, Hello Dolly!

I'm currently in a "chat"
where the thinking is multi-threaded does not necessarily mean
multi-processor enabled.....

Yes - it means the same thing on Windows. Programs can be multi-
threaded meaning they contain more than one independent thread of
execution. Each processor can only run one thread at a time and

a round-robin to divide processing time between all of the threads
executing on it. A multi-processor machine can run one thread per
processor for true parallel processing but each processor still

the round-robin between threads assigned to it.

To me, in my mainframe mentality, if its a single-threaded app on

multi-processor, you get single threaded service.

Correct and Windows decides which processor runs the single-

app.

If its a multi-threaded/processor app running on a single
processor, you get single threaded service.

No such thing as a multi-threaded/processor app. As explained above
programs can be designed to be single or multi-threaded and the
programmer uses a BeginThread() and ExitThread() function to start
and stop threads. The WIN32 API does not contain a function that
allows the programmer to assign a thread to a processor. Windows
notices that an app has more than one thread and that the computer
has more than one processor and Windows balances the threads

processors.

Operating systems are designed to use mutliple processors and

threads from multi-thread apps

Each thread of the multi-threaded app on a single processor

appears to run independant of each other, it appears as if both are
running. Actually windows only runs one thread per processor at a
time. For each processor Windows switches very quickly between each
thread assigned to the processor give the illusion that all are
running simultaneously.

If its a multi-threaded app running on a multi-
processor, Hello Dolly!

Yep! Now each processor can do its round-robin between all assigned
threads and do it simultaneously.

Tom, if your interested in a good explanation of Windows internals,
fill your pockets with all those Oreo cookies and ale that people
are sending you and ask Cindy Crawford to meet you in the computer
section at Borders tonight. She will be very impressed when you
pull "Advanced Windows" by Jeffrey Richter or "Programming Windows"
by Charles Petzold from the book shelf.

What I wanted to do was emphasize my
chat buddies nondistinction of multi-threaded written app / multi-
processor enabled app.

It should have been something like:
If its a multi-threaded app / multi-processor enabled app
according
to their terms)...blah...blah...blah....

Us "Big Iron Workers" actually have the pleasure of assigning at
least one processor (CP in my world) to an application, or for the
sole use of the OS and let the other CPs balance the remaining
OS/application workload. By no means am I saying one is better than
the other; just making some observations.

Single processors handle multi-threaded apps similarly on MFs. As
you're familiar with paging, our processors do a analogous "cycle
steal" where one thread sits idle for however many nano/pico-
seconds
to give service to the other thread and/or application.