reference will now be made in detail to the preferred embodiments of the present invention , examples of which are illustrated in the accompanying drawings . fig1 illustrates what the microsoft windows ® standard viewer , windows picture and fax viewer ( wpvf ), which is used as an example in this discussion , looks like . other os standard image viewers and managers , e . g ., the standard viewer in microsoft windows vista ( or a viewer such as windows photo gallery ) are also intended to be covered by this description . as shown in fig1 , the wpvf main window has a header area , an area where the current image is displayed , and an instrument panel that allows the user some modest image manipulation capabilities , such as image rotation , zoom in , zoom out , printing , etc . in addition to these relatively simple functions , many users would like to be able to edit the images . for example , such editing might include red eye remover , color correction , caricature effects , lighting effects , retouching , resizing , cropping , removal of artifacts , etc . at minimum , to enable additional functionality , the standard viewer , whether for the versions available in 2006 , or for any future versions , such as windows vista , etc ., needs to have additional buttons added , for the user interface . this is illustrated in fig2 . additionally , other functionality needs to be added to the viewer , that is not necessarily visible to the user , but is needed to enable the required functionality due to the absence of a plug - in interface in wpfv . furthermore , it is desirable to have the option to hide the added buttons , so that the user can return to the standard browser viewer interface that he is used to . although the toolbar in fig2 is shown at the bottom of the screen , one skilled in the art will readily appreciate that the toolbar can be positioned elsewhere in the window as well , for example , at the top , on the side , or even be displayed dynamically , for example , when the user presses some key . when the image editing functionality is called by the user , an appropriate image processing module is then activated , and the results of the processing are displayed on the screen . optionally , the user can have the ability to replace the original image on the screen , retain the original image on the screen under a different name , cancel the edits to the image , display both the original image and the edited image simultaneously , etc . this is illustrated in fig3 . thus , the task of incorporating additional functionality into the standard viewer includes : ( b ) attaching to the main window of the viewer , in order to intercept the messages between the operating system and the viewer window ; generally , when the above aspects are implemented , the algorithm for doing so is broken up into a number of specific tasks , which typically need to be done during the execution of the program . for example , these tasks include : 1 . identifying the name of the file of the current image that is being displayed ; 3 . displaying the edited image in the viewer &# 39 ; s main image window , including an optional ability to display both the edited image and the original image , and optionally synchronizing the scale of the edited image and the original image ( i . e ., synchronizing the zoom factor ); 4 . don &# 39 ; t allow the user to do something in the viewer window until he has finished the editing of the image . this forces the image editing window to be active if the user is attempting to activate the viewer window . the algorithm of integrating the additional functionality into the standard viewer uses , for example , the mechanism of hooks in microsoft windows ®. a “ hook ” refers to code that implements the changed code , such as new function calls that replace the original function calls in wpfv . usually the hook is added in the process of patching or installing the new code , such as the photo toolkit , but it can also be present already , and activated later . using the hook mechanism of windows ® permits integrating the photo toolkit code into the code of another process , such that the photo toolkit code is called when certain events occur . the photo toolkit code is preferably provided as a separate module , and is loaded by the operating system into all system processes that have a user interface . once a certain event happens , for example , a message from the system to the viewer window , the photo toolkit module then determines whether this process is the process that it is interested in , in other words , a standard viewer such as wpfv , or the standard viewer in the future versions of windows ®. if the calling program is not a standard viewer , then the module does nothing , allowing the operating system and whatever module was calling it to act “ normally .” if it is a standard viewer , such as wpfv , then it is required to do all the remaining tasks related to the integration into a viewer . this can be done in parallel with the operation of wpfv itself , for example , by using a separate thread , or a similar mechanism . this also helps avoid possible problems , such as the wpfv “ hanging up ” or slowing down of the start of the wpfv itself , etc . in one embodiment , for each instance of the viewer , a separate instance of the photo toolkit module is launched . once launched , the photo toolkit module then calls the panel integration function . this function has the following tasks : 3 . the attaching function then checks whether the photo toolkit panel is already installed in the viewer window . if it is , then no further work needs to be done . otherwise , using standard windows ® api mechanisms , the function replaces the current instrument panel with the photo toolkit instrument panel . this is illustrated in fig4 . as shown in fig4 , once the process is started ( step 402 ), in step 404 , the process looks for the viewer &# 39 ; s main window . if no such main window is found , then the process terminates in step 412 . if the main window is found , then , in step 408 , the process checks whether the instance of the viewer that it found already has the photo toolkit instrument panel . if it does , then the process terminates in step 412 , otherwise , the window procedure is intercepted in step 410 and the process terminates in step 412 . in other words , each window in microsoft windows ® has its own service callback function that is called then an event occur . intercepting the window procedure means that windows ® will call a specified callback procedure instead of the original callback procedure . the specified callback procedure will then call original procedure . as noted earlier , the instrument panel of the standard viewer needs to be modified as well , to provide the user an interface for the added functionality . one of the decisions that needs to be made is related to the appearance of the window and the additional toolbar . this is generally viewer - specific . for example , the added toolbar can be placed at the bottom of the window , at the sides of the window , at the top , etc . it can be integrated into the original toolbar , for example , by stretching it , by somewhat shrinking the original buttons in size , by providing a dynamic pop - up toolbar , etc . as yet a further option , fig3 , discussed above , illustrates how the added toolbar can be displayed , including a button for hiding it . one of the difficulties of working with the windows ® standard viewer , wpfv , is that wpfv does not have a mechanism for providing a file name of the image that is currently being displayed . to address this problem , in one embodiment of the invention , the following approach has been implemented . in response to a user request , wpfv can show a window on the screen that displays the properties of the file , as shown in fig5 . fig5 illustrates that the newly opened window contains all the information necessary to generate the file name . in order to actually generate the file name , it is therefore possible to imitate the opening of the dialog window of fig5 by the user , wait for its appearance , and , upon receipt of the information from the window , close it . therefore , the algorithm for identifying the file name is generally as follows ( see also fig6 ): 1 . after starting ( 602 ), inside wpfv , a hook is installed ( step 604 ), within which the algorithm awaits the moment of creation and initialization of the file properties dialog window . this algorithm can have a relatively simple check of the call , whether this call is meant to initiate the dialog . once the dialog initialization event is received , this indicates that the dialog window is open and is populated with information , but is not yet displayed . 2 . the algorithm then imitates an action by the user to display the file properties window ( 606 ). this is implemented by sending a standard windows ® call to main window of wpfv with a function parameter ( identifier ) that corresponds to the parameter to open the dialog window shown in fig5 . 3 . the algorithm then awaits the initiation of the dialog window shown in fig5 ( step 608 ). 4 . since the message regarding the initiation of the dialog window can come from several windows , due to the properties of the dialog window , it is necessary to identify the message from the “ general ” tab , or from the “ summary ” tab ( 610 ). to do this , a procedure that checks the parent window of the message can be used . if the parent dialog window has an identifier “ 32770 ” then this is the dialog window the algorithm is looking for . otherwise , the procedure waits for a message from the proper dialog window . 5 . the “ general ” tab is of interest , and this tab is made the main tab , and its identifier is received ( 612 ). if receiving the identifier is not possible , that means the dialog window has not been initiated yet ( 614 ). 6 . using standard os functions that work with dialog windows , the file name ( here , “ water lilies ”), file path ( here , “ d :\ documents and settings \ . . . ”), and file size ( here , 81 . 8 kb , or 83 , 794 bytes ) can be received ( 616 ). the file size is of interest because the “ general ” tab contains no information about the extension of the file ( but only its user - friendly name ). if the folder has several files with the same name , but with different extensions , the file will be identified by both the name and file size . 7 . the dialog window can then be closed ( 618 ). the algorithm described above can , at times , be somewhat slow , primarily because the dialog window that shows the file properties is called by the wpfv with some delay . to address this problem , the following modification can be implemented . the modification is based on the fact that wpfv shows the file name in the header of the main window , and , therefore , most of the time there will not be a need to call the window that shows file properties . the algorithm for this can be as follows : 1 . the algorithm checks whether the current working folder of images is known . the folder will be stored in a known place , and , if it is not known , then the current folder can be identified using a standard windows ® function call . 2 . the file name of the image is then derived from the title of the viewer window . 3 . the algorithm then checks that the file with that name is actually present on the disk . if there is no such file , then this indicates that the folder is unknown , and it is different from what has been identified by the standard windows ® function call . in that case , the algorithm described above with reference to fig6 needs to be used . once that algorithm has been run , the current working folder derived by it is stored for the further use by this algorithm . 4 . if the file with that name does exist on the hard disk drive , then the number of files needs to be checked . if there are several files with the same name , then , again , the standard method shown in fig6 needs to be used . if only one file is found , then , knowing the folder , the file name , and file extension , the entire file identifier can then be displayed . fig7 illustrates the accelerated algorithm for deriving the file name that corresponds to the image being displayed . as shown in fig7 , after the algorithm starts in step 702 , in step 704 , the algorithm checks whether the current working folder is known . if the current working folder is unknown , then , in step 708 , the current working folder is identified using standard windows ® apis . then the file name is derived from the header of the currently open main window ( step 706 ). if , in step 704 , the current folder is known , then the file name is derived from the header of the currently open main window ( step 706 ). the algorithm then checks whether the current folder has only one file with that name ( step 710 ). if there is more than one name , or there are no files with that name found , then the algorithm proceeds to step 714 . if there is only one name , then the entire file name and file path can be derived from the folder ( step 712 ). the process then terminates in step 718 . in step 714 , the “ slow ” method is used , as illustrated in fig6 . then , in step 716 , the name of the current folder is stored , and the process then terminates in step 718 . it should be noted that as a practical matter , the situation where there are multiple files that have the same name but different file types ( i . e ., waterlilies . jpg , waterlilies . bmp , waterlilies . tif , etc .) is relatively rare , most of the time , it is expected that the accelerated algorithm shown in fig7 can be used . another issue that needs to be addressed is refreshing the current image when that image has been edited . wpfv does not have a standard mechanism for doing that . to address this issue , the following algorithm is proposed , and is illustrated in the screen shot of fig8 and the flow chart of fig9 . as shown in fig9 , after starting the algorithm in step 902 , in step 904 , the window with the current image is hidden ( step 904 ). this is done in order for the user to avoid seeing a “ blinking ” of the image on the screen due to the execution of the steps discussed further below . note that despite the hiding of the window , the image itself does not disappear ; it merely is no longer refreshed . in step 906 , the algorithm imitates the actions by the user , when the user presses the “ forward ” and “ back ” buttons on the wpfv standard toolbar . this forces wpfv to refresh the image of the edited picture . in step 908 , the algorithm shows the window with the current image , and the user now sees the edited image in the main window . the algorithm ends in step 910 . to display the results of the image editing , a special window is opened , such that the window fulfills the functions analogous to the wpfv main display window . in other words , this window shows the image , and scales the image appropriately . the other window that shows the current image is temporarily hidden . since these windows appear identical , the user will not notice any difference . additionally , the photo toolkit gives the user the option of comparing the edited image with the original image . this can be done by loading , into the new main window , the original image . switching between the windows can be done , for example , using the right mouse button , which is convenient for the user . another aspect that needs to be addressed is the scaling , or zoom factor , of the image . wpfv provides a number of different scale factors that the user can employ — for example , scale to window size , scale to actual size , scale to some specified zoom factor . accordingly , the edited image needs to be displayed to the same scale factor as that used in the original wpfv image . furthermore , not only does the scale factor needs to be synchronized , but also the current position of the image , if the image is larger than the window used to display it . in order to accomplish this , the following algorithm can be implemented : old commands that control the current scale factor of the image are transferred to the window with the current picture . that window continues to process those commands , as before , upon receipt , even though that window is hidden . when the command is processed by the window , the algorithm can synchronize the scale of the image in the window that shows the edited image with the scale of the original image . the synchronization itself is done based on the state of the buttons on the instrument panel and the parameters of the scroll bars of the current image . this can be done as follows : if the button “ best fit ” is inaccessible , then the window that shows the edited image uses the same scale factor . if the “ best fit ” button is accessible , then the algorithm checks the state of the “ actual image size ” button . if that button is inaccessible , then the scale factor is set to one for the window that shows the edited image as well . if that button is also accessible , that means that the user has set the size by using the zoom in / zoom out buttons . the image scale can be derived based on the state of the scroll bars . the parameter maximum position is indicative of the required zoom factor of the image ( for example , for an image size 200 pixels , with a scale factor of 2 , the necessary image size will be 400 pixels ), while the parameter “ current position ” is indicative of the current images upper left most xy coordinate . the height and length of the image corresponds to the horizontal and vertical scroll bars . if the user changes the position of the view area of image , then the parameter “ current position ” of the image editing window &# 39 ; s scrollbars is synchronized with the appropriate parameters of the current image window ( that belongs to wpfv ) as well . fig1 illustrates the scaling algorithm in flowchart form . as shown in fig1 , once the algorithm begins in step 1002 , the algorithm awaits the “ change zoom ” command from the user ( step 1004 ). the command is then processed using the means available in the wpfv ( step 1006 ). the algorithm then checks whether the button “ best fit ” is inaccessible ( step 1008 ). if it is , then , in step 1010 , the current window is set to the scale factor ( step 1010 ), and the process ends in step 1018 . if , in step 1008 , the “ best fit ” button is available , then , in step 1012 , the algorithm checks whether the button “ actual image size ” is inaccessible . if it is , then in step 1014 the same scale factor is applied to the current image . if it is not , then the scale factor is set based on the parameters of the original image ( step 1016 ) and the process terminates in step 1018 . additionally , it is preferable that the principle of modality be preserved . this means that while the photo toolkit is performing some dialog - based function ( e . g ., red - eye removal ), that the wpfv wait for the dialog window to be closed , before doing anything else . in other words , the added photo toolkit functions behave the same way as the standards wpfv functions . this is done by calling the window activation function when receiving the standard message of setting the input focus and message of drawing the main window &# 39 ; s title . an example of the computing system 1102 on which the technology described above can be implemented is illustrated in fig1 . the computing system 1102 includes one or more processors , such as processor 1101 . the processor 1101 is connected to a communication infrastructure 1106 , such as a bus or network . various software implementations are described in terms of this exemplary computer system . after reading this description , it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and / or computer architectures . computing system 1102 also includes a main memory 1108 , preferably random access memory ( ram ), and may also include a secondary memory 1110 . the secondary memory 1110 may include , for example , a hard disk drive 1112 and / or a removable storage drive 1114 , representing a magnetic tape drive , an optical disk drive , etc . the removable storage drive 1114 reads from and / or writes to a removable storage unit 1118 in a well known manner . removable storage unit 1118 represents a magnetic tape , optical disk , or other storage medium that is read by and written to by removable storage drive 1114 . as will be appreciated , the removable storage unit 1118 can include a computer usable storage medium having stored therein computer software and / or data . in alternative implementations , secondary memory 1110 may include other means for allowing computer programs or other instructions to be loaded into computing system 1102 . such means may include , for example , a removable storage unit 1122 and an interface 1120 . an example of such means may include a removable memory chip ( such as an eprom , or prom ) and associated socket , or other removable storage units 1122 and interfaces 1120 which allow software and data to be transferred from the removable storage unit 1122 to computing system 1102 . computing system 1102 may also include one or more communications interfaces , such as communications interface 1124 . communications interface 1124 allows software and data to be transferred between computing system 1102 and external devices . examples of communications interface 1124 may include a modem , a network interface ( such as an ethernet card ), a communications port , a pcmcia slot and card , etc . software and data transferred via communications interface 1124 are in the form of signals 1128 which may be electronic , electromagnetic , optical or other signals capable of being received by communications interface 1124 . these signals 1128 are provided to communications interface 1124 via a communications path ( i . e ., channel ) 1126 . this channel 1126 carries signals 1128 and may be implemented using wire or cable , fiber optics , an rf link and other communications channels . in an embodiment of the invention , signals 1128 comprise data packets sent to processor 1101 . information representing processed packets can also be sent in the form of signals 1128 from processor 1101 through communications path 1126 . the terms “ computer program medium ” and “ computer usable medium ” are used to generally refer to media such as removable storage units 1118 and 1122 , a hard disk installed in hard disk drive 1112 , and signals 1128 , which provide software to the computing system 1102 . computer programs are stored in main memory 1108 and / or secondary memory 1110 . computer programs may also be received via communications interface 1124 . such computer programs , when executed , enable the computing system 1102 to implement the present invention as discussed herein . in particular , the computer programs , when executed , enable the processor 1101 to implement the present invention . where the invention is implemented using software , the software may be stored in a computer program product and loaded into computing system 1102 using removable storage drive 1114 , hard drive 1112 or communications interface 1124 . having thus described a preferred embodiment , it should be apparent to those skilled in the art that certain advantages of the described method and apparatus have been achieved . it should also be appreciated that various modifications , adaptations , and alternative embodiments thereof may be made within the scope and spirit of the present invention . the invention is further defined by the following claims .