Main Page | Modules | Namespace List | Class Hierarchy | Alphabetical List | Class List | Directories | File List | Namespace Members | Class Members | File Members | Related Pages

phission Class List

Here are the classes, structs, unions and interfaces with brief descriptions:
add_Filter
arg_node_tThis struct holds the settings of an argument that will be parsed from the command line
argument_table_t
auto_coord_t
auto_line_s
autoblob_Filter
ave_Filter
average_Filter
bilinear_pixel_u
blob_Filter
blob_t
blobify_Filter
block_Filter
brightness_Filter
callout_Filter
canny_Filter
convert_Filter
crop_Filter
cv_canny_Filter
cv_empty_Filter
cv_houghLines2_Filter
ddimage_Filter
draw_Filter
drawRect_Filter
edge
empty_Filter
FLDisplayTodo
gaussian3x3_Filter
gaussianBlur_Filter
GDIDisplayTodo
graphSegmentation_Filter
grayScale_Filter
histogram_Filter
hsvsegment_Filter
hsvthreshold_Filter
image_data_collection_t
image_data_set_t
inverse_Filter
invert_Filter
key_matte_threshold_Filter
mask_Filter
maskBottom_Filter
match_Filter
meanBlur_Filter
meanNxN_Filter
medianBlur_Filter
medianNxN_Filter
ml_class_stats_t
motion_Filter
NetDisplayTodo
original_Filter
ph_bilinear_pix_array_t
ph_bilinear_pixel_t
ph_bilinear_table_t
ph_cond_node_t
ph_condition_info_t
ph_convert_func_struct
ph_destination_mgr
ph_edge
ph_int32_array_t
ph_joystick_key_t
ph_jpeg_compress_struct
ph_jpeg_compress_struct_t
ph_jpeg_decompress_struct
ph_jpeg_decompress_struct_t
ph_jpeg_struct_t
ph_mem_info
ph_mutex_info_t
ph_nearest_neighbor_table_t
ph_player_client_t
ph_player_position_t
ph_player_power_t
ph_player_ptz_t
ph_player_sonar_t
ph_player_wifi_link_t
ph_player_wifi_t
ph_ppm_image_s
ph_qs_stack_t
ph_rwlock_info_t
ph_semaphore_info_t
ph_socket_info_t
ph_source_mgr
ph_thread_info_t
ph_time_entry_t
ph_time_t
ph_timedb_t
ph_uni_elt_t
ph_x_table_t
ph_y_table_t
phANNSystem
phArgTableUsed to parse command line arguments. This class is used to set up a table that maps command line switches to variables within a program. The parsing process is:
  • create a phArgTable object,
  • add a series of <switch string, parameter storage pointer, value type> tuples to the list by calling phArgTable::add
  • and then call the parse method to fill in the values of the variables
phautoblob_args_t
phautoblob_data_t
phautoblob_t
phAutoBlobData
phAvcodecSourceTodo
phAvcodecSourceInfo_t
phblob_args_t
phblob_coord_t
phblob_data_t
phblob_line_s
phblob_t
phBlobData
phCaptureInterfaceThe phCaptureInterface is the higher level class abstraction for any data capturing thread
phCircle_t
phClientHandler
phClientListener
phColor_t
phColorABGR32_t
phColorArray_t
phColorBGR24_t
phColorBGRA32_t
phColorGREY8_t
phColorHSV_t
phColorRGB24_t
phColorRGBA32_t
phColorSCT24_t
phColorYUV9_t
phConditionThis class implements a platform independent condition variable mechanism. Not every platform has it's own implementation and other algorithms were found to create condition variables where they aren't natively supported. These algorithms use a combination of mutexes and semaphores to emulate the behavior of condition variables. While it might seem straight forward to use the algorithms, it required a bit of work. The implemented algorithm using Win32 API and using the Phission API for the Blackfin was derived from: http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
phConditionCounterThis is a Condition Counter class that allows for threads to block while waiting for a specific value setting. Threads will call phConditionCounter::waitForValue with a value parameter and a conditional operation choice to compare the passed value with the counter value. In order to provide the condition variable functionality, this class inherits from the phCondition class. The phConditionCounter::waitForValue method is a convenience because it simplifies the code at higher levels when a specific value is desired where hard looping or sleeping will impact performance. The waiting doesn't return until the condition is met whereas phConditon will return whenever the condition is signaled
phCross_t
phDataObjectTodo
phDisplayInterfaceTodo
phDrawing_t
phDrawingObjectNode_t
phEffectsThread
phFilterTodo
phFLImageWindowTodo
phGDI_pair_t
phGDIHandlerParameters_t
phGDIImageWindowTodo
phGDIWindowInfo_t
phGravisGamePadProData
phHistogramData
phHoughData
phImageTodo
phImageCaptureTodo
phImageSurface_t
phImageWindowTodo
phJoystickControl
phJoystickData
phLamportSystem
phLine_t
phLinkedListThe phLinkedList is not a thread-safe linked list implementation
phLinkedListNode
phLinuxJoystick
phListThe phList is a thread-safe linked list implementation. The list is locked whenever an operation is being performed on the list. List nodes are only locked if they are being looked at or having the next/previous pointers adjusted. Otherwise, it is possible for multiple threads to access multiple nodes at a time when the list doesn't have a node locked
phListNodePhListNode is used with the phList class and represents a simple node type that can be added or removed from the list. It doesn't hold any information and classes should be derived from it if a node type that holds information wishes to be implemented. The phObjectNode is one class that inherits from this class and implements new methods specific to the phObjectNode and phObjectList classes. The node inherits from phMutex so that it can be locked when list operations are being performed to make the implementation thread-safe. Whenever the node pointers are being adjusted using phListNode::setNext or phListNode::setPrevious the specific instance of phListNode will be locked so that no other thread can try adjusting the pointers at the same time. The object is also locked in phListNode::getNext and phListNode::getPrevious so no thread can change the pointers while another thread is trying to get access to them
phLiveCookieTodo
phLiveObjectThe phLiveObject and phLiveCookie classes are the backbone of the data flow type system. They are used to encapsulate all update and signaling functionality. Any object that wants to use the connect, update and disconnect phLiveObject API should derive from this class. In this manner, any object that also derives from phLiveObject can connect to any other phLiveObject class. These classes must also overload the 'copy' and 'swap' methods of the phObject class
phMessage
phMessageNode
phMutexPhMutex provides platform independent locking mechanisms to the Phission code. The phMutex is a recursive implemented mutex. Multiple mutexes can be obtained by a thread by calling the phMutex::lock() method and each successful phMutex::lock() should be matched with a call to the phMutex::unlock() method. If there isn't one phMutex::unlock() call for every phMutex::lock()/phMutextryLock() call that succeeded, deadlock could occur in other threads that are trying to obtain the lock. Recursive mutexes are necessary for a system such as Phission where a call to the current object's method may also call other methods that belong to the same instance of the object. Those other methods could be called on their own as well. Without recursive mutexes, the one scope calling into another scope (scope being separate methods or blocks of code) will deadlock on the second attempt at locking
phNetClientRecvThreadTodo
phNetClientThreadTodo
phNetImageWindowTodo
phNetSourceTodo
phNetSourceInfo_t
phNodeComm
phNodeControllerClient
phObjectThis is the parent class of every object in the Phission library. Every object must inherit from the phObject class to provide a generic way of passing Phission objects around and creating generic interfaces. Copy and swap methods were added to phObject to support phLiveObject functionality. Should other inherited classes required interface support from phObject, the interfaces will be added
phObjectListThe phObjectList is a list that operates with phObjectNodes to create a thread-safe list structure for the storage of any class derived from phObject. This class basically wraps around the phList interface but makes adaptations to take phObject pointers as parameters. In addition, a phObjectList::findObject method will determine if a phObject exists in the list for any purpose such as making sure the phObject exists only once in the list. The methods are renamed to include the term Object so that they will not be mistaken for the phList wrapped methods. The phObjectList also handles much of the creation of the phObjectNode containers by taking only a phObject pointer as a parameter. This greatly simplifies higher level code such as the code in phSystem that makes use of this class. If one wishes the nodes in a phObjectNode to always have the auto delete option enabled, the phObjectNode returned from any of the following methods can be used to enabled it:
phObjectNodeThe phObjectNode wraps most of the phListNode methods to provide a phObjectNode interface that doesn't require a user to always wrap the phListNode returned pointers to a phObjectNode pointer. The phObjectNode adds methods to set the phObject pointer that is packaged within the node. The autoDelete_on parameter is used to delete the phObjects in the phObjectNodes when delete is called on the phObjectNode. This allows one to add nodes to the list and forget about deleting the objects if it serves the code. Auto-deleting is disabled by default because the common case dictates that a user will add a phObject and then delete that object manually instead of letting the node do it
phPioneerSonarData
phPipelineThe pipeline class is the main processing thread within the Phission system. phFilter classes are added to a phPipeline and are processed in the order in which there were added
phPixel_u
phPlayerClient
phPlayerDevice
phPlayerPosition
phPlayerPower
phPlayerPtz
phPlayerSonar
phPlayerWifi
phPoint_t
phPositionData
phPowerData
phRectangle_t
phRequestDB
phRequestList
phRWLockThis class provides a platform independent Reader-Writer class
phRWLockThread
phSDLImageWindowTodo
phSDLWindowInfo_t
phSemaphoreThis class implements a thread safe portable semaphore class. It extend the normal interface of a semaphore with the phSemaphore::postWaiting and phSemaphore::postMax methods. This semaphore object will keep track of the number of waiting threads at any instance in time to allow them to all be 'woken up' if necessary to permit the proper shutdown or cleanup of a thread or series of threads. Being able to post the maximum number of semaphores possible without any of the threads returning until all the semaphores are posted can be useful in synchronization. Otherwise, the semaphores can be posted one at a time
phServerSocketTodo
phServerThread
phSideWinderPrecisionProData
phSimpleVision
phSize_t
phSocketA simple client-side socket communication layer
phSonarData
phSonarHandler
phSystemTODO
phThreadC++ wrapper class for threading
phThreadClassOne
phThreadClassThree
phThreadClassTwo
phTimeIntervalTodo
phTimeListTodo
phTimeStampTodo
phTriangle_t
phUniverse
phUPoint_t
phUSize_t
phV4LCaptureInfo_t
phVFW_pair_t
phVFWHandlerParameters_t
phVFWWindowInfo_t
phWander
phWifiData
phWifiLinkData
phWrapperThread
phX11DisplayInfo_t
phX11EventAtom_t
phX11EventInfo_t
phX11ImageInfo_t
phX11ImageWindowTodo
phX11LocationInfo_t
phX11SizeInfo_t
phX11WindowInfo_t
point_t
random_selection_t
resize_Filter
VDK::RMutex
save_frame_t
scale_Filter
SDLDisplayTodo
setPlane_Filter
sobel3x3_Filter
sobel_Filter
subtract_Filter
superRGB_Filter
swapPlanes_Filter
thread_attr_struct
threshold_Filter
uni_elt_t
universe
V4LCaptureTodo
VFWSourceTodo
X11DisplayTodo




Copyright (C) 2002 - 2007 Philip D.S. Thoren ( pthoren@users.sourceforge.net )
University Of Massachusetts at Lowell
Robotics Lab
SourceForge.net Logo

Generated on Sat Jun 16 02:44:26 2007 for phission by  doxygen 1.4.4