[Digikam-devel] GSOC 2010 Proposal : Non-destructive editing of images in digiKam

[Gilles Caulier]

And a new one. You will work on both subject, or you tried to make
more than one proposal to increase chance to be selected by Google ?

Anyway, this paper is fine for me too.

Gilles Caulier

2010/3/25 Adwait Gandhe <adwait.gandhe1990 at gmail.com>:
> Dear Sir,
> The following is my proposal for GSOC 2010 on Non-destructive editing of
> images in digiKam.
> I had earlier sent it to Mr. Marcel Wiesweg.
> Hoping to work with digiKam in the summer.
> Kindly let me know of any suggestions or improvements.
>
> NON-DESTRUCTIVE EDITING OF IMAGES IN 'digiKam’ PHOTO MANAGEMENT PROGRAM TO
> MAINTAIN ORIGINAL IMAGE AND ENABLE THE USER TO COMPARE THE CHANGES AND
> ACCESS THE HISTORY OF CHANGES MADE
>
>
>
> Abstract:
>
> ­The digiKam photo management program allows users to manage their photo
> collection and apply certain changes to image properties. Currently the
> changes made to the image directly act on the image and the original image
> is lost in the process. This project proposal runs parallel to the idea
> suggested of non-destructive image editing by creating a copy of the image
> in question and imparting all the changes the user wishes to make on this
> image copy, hence maintaining the original image and allowing the users to
> compare the changes made. This work also considers the fact that the user
> may want to first implement a series of changes to an image and then on
> comparison implement all or some of the same set of changes to another
> image.
>
> Name and Contact info:
>
> Adwait Gandhe
>
> Email :
>
> adwait.gandhe1990 at gmail.com
>
> adwait1990 at gmail.com
>
>
>
> Benefits to the community:
>
> The current version of digiKam allows users to make changes to an image.
> However a common problem encountered is that these changes are implemented
> on the original image. It often happens that the user is not convinced of
> the changes made and later regrets making them as the original image is
> lost. Also, a user may want to view the image history of the changes made to
> an image and view each image in the timeline. By doing this the user can
> compare the changes made to the image and how the image actually looks like
> as compared to one say before making ten changes. The user will also be
> allowed to either choose a particular set of changes made to an image or
> implement the same ones or a part of them to another image.  Implementing a
> system where the original image is not lost and bulk changes can be made to
> an image will improve the usability of the software.
>
> Another feature that I plan to integrate is to allow the users to predefine
> a set of changes that they usually like to implement to an image and have a
> specific naming system for these changes. For example, a user will be able
> to apply a change called ‘rectify’ to an image that will say crop the
> central square of the image, increase contrast, implement red-eye etc. This
> feature will save the users time, especially those who need to more or less
> apply the same set of changes every time to their images, in this case say
> those who take portrait pictures of people.
>
>
>
> Necessary work to be done:
>
> 1.      XML schema: For storing the set of changes the user wishes to
> implement, a proper well designed XML schema needs to be implemented. I am
> currently researching the types of XML schema that other open source
> software use. However, I would prefer to have a self-designed schema as that
> can be made to make the integration and storage procedure easier. This
> schema should have a well defined hierarchical structure and the parameters
> as the digiKam plugins give to the user. Another reason for making the
> schema project specific is that this data now needs to be integrated with
> the software.
>
> 2.      Copy of image:  As necessary for the project, the software will
> create a copy of the image and allow the image to be accessed and modified
> globally. This copy needs to be generated only when the first change is
> initiated by the user, not otherwise as that will utilize unnecessary
> memory.
>
> 3.      Changes made: While making the various changes, the user will now be
> looking at the image copy. All the changes made by the user will update the
> XML file, keeping a tab of the image history. Also, complementary changes
> made to the image need to be stored separately. For example, if a user
> increases contrast by a factor of say 3, follows this with a series of
> changes and then decreases contrast by 2, the effective value should not be
> stored as increase contrast by 1. This is necessary as later we plan to have
> a feature of implementing a set of similar changes to another image. Here
> again, we see the importance of a proper XML file format.
>
> 4.      Apply Changes: As the changes are made to the image, our program now
> stores what changes are to be made. The next step is to link all the
> available plugins in the software. The idea now is to feed the XML data as
> input to the various functions, replace the image variable which originally
> was the original image with the copy, and save each resultant image in same
> variable. This will later enable us to display the entire image history, by
> generating images using the schema.
>
> 5.       Display as required: The next crucial part of the project is to
> simultaneously display the changes. The image history display needs to be
> made attractive and user friendly, allowing users to see the timeline of
> images, dates of changes etc. Also, an option of choosing an entire set of
> changes or a particular set of changes. This process would be to modify the
> XML data for that image in such a way that the corresponding parameters will
> be added when the user clicks on an image after selecting the option of
> ‘apply similar changes’. In this procedure, the changes from previous image
> to current image will be stored. This feature will allow the user to first
> implement the changes on a dummy image and then select only the appealing
> ones for further implementation.
>
> 6.      Save a set of changes:  After the previous work, this feature should
> not be difficult to handle. The software will provide a dummy image to the
> user. The user selects the ‘save changes’ option and implements all the
> changes on this dummy image. The corresponding XML file will now be
> generated under a specific user-given name. The same changes can later be
> applied to any image.
>
> 7.      Naming System: In the process of development of this project, a lot
> of new images and files will be created. An efficient naming system needs to
> be adopted to ease the operation process. Though I am currently doing some
> research to see how such systems are adopted, I would like to take help from
> the mentor as they are more experienced in the software development.
>
> 8.      Saving procedure: The user need not be asked if images are to be
> saved. The copies as suggested can be saved, displayed as stacks below the
> original image. Also, the image history can be made more attractive where
> the previous images zoom onto the screen. The ‘tree view’ as suggested may
> also be implemented. The idea is to make the entire setup easy to understand
> and use. Also, the ‘apply similar changes’ widget is integrated here.
>
>
>
> The above is a modular analysis I think will be required to complete the
> project. In addition if time permits, or else as a developer later, I plan
> to have another widget that can apply the selected set of changes to a group
> of different images the user chooses. This part will greatly reduce the time
> required for image manipulation. For example, the images I take from a
> simple webcam always need increase in contrast, red-eye effect and cropping
> off the borders. The above mentioned widget will directly give me the image
> after doing all these usual changes.
>
> Another parallel feature that seems useful here, is to develop the system a
> bit further, to have routine image corrections. For example, when I input
> images, I should decide whether they need to be stored as they are and then
> apply changes, or make changes and then save. This is important as the user
> may not always want to know about the image history, where he himself has
> predefined the set of changes. The original input may not always be useful
> and need not be saved. In my case, I want the pictures I take on my camera
> to be saved, but the webcam pictures initially processed and then saved for
> further changes.
>
>
>
> Work by timeline:
>
> April 9 to April 26: Understand properly the code for digiKam.
>
> April 26 to May 24: Perfect and revise the necessary skills for the project
> like C/C++
>
>                                : Read the source code for other open source
> projects to narrow down
>
>                                     on a good XML schema design. Also
> interact with the mentor to
>
>                                    understand the expectations of the
> organisation.
>
> 1.      Start coding.(May 24 to May 31) Initially for the first week work on
> developing the XML template. As this work has been started from before,
> completing and perfecting the template should not be difficult. Interact
> with the mentor and community to clear concepts regarding the source code.
> Make sure that the template developed suits the purposes.
>
> 2.      Complete XML template.(June 1 to June 8) I am keeping more time for
> this part as the success of the work depends on this. The more efficient the
> template, the easier it is to carry on with the project.
>
> 3.      Naming System(Simultaneously). A proper naming system needs to be
> sketched. It needs to be efficient and non bounded to allow as many changes
> a user wishes to make.
>
> 4.      Work on image copy.(June 8 to June 15) This part is not the most
> complicated. However, till this time any backlog can be completed. So far,
> the XML schema is ready and image copy available.
>
> 5.      Linking the various functions.(June 15 to June 29) The part that is
> more tedious, but necessary to say the least. It will involve making
> functions that will send the XML data to the already existent image
> modification functions along with the parameters and apply changes on the
> image.
>
> 6.      Save set of changes.(July 15)  As mentioned previously, a widget can
> be developed that stores a set of changes made on an image, or directly
> takes a set of changes from user and stores them in the XML schema
> specified. This part will add to the usability of the software. The GUI
> option also needs to be added.
>
> Midterm
> Evaluation.............................................................................
>
>
>
> 7.      Display Image history.(July 15 to July 29) After all the work behind
> the scenes, it is time to display the images. This needs to attractive and
> efficient. The new images should be stacked under the original image. The
> interim period will be used to understand and take help from the mentor on
> proper execution.
>
> 8.      Work on the further ideas.(July 29 to August 7) If time permits, the
> ideas described above can be attempted. It will help to make the software
> easier to handle.
>
> 9.      Complete the entire project till August 14. Always good to finish
> before deadline.
>
>
>
> Personal Bio:
>
> Hi, my name is Adwait Gandhe. I am a second year student at Birla Institute
> of Technology and Science, BITS-Pilani, Goa Campus. I am currently pursuing
> Electrical and Electronics engineering. My primary interest is Image
> Processing.
>
> I have taken certain related courses like Computer Programming 1 and 2
> covering the programming basics of C/C++ environment. I have good experience
> in coding in C/C++ and deeply interested in working in image manipulation.
> My main motivation in applying to this organisation was working on software
> for image manipulation. I plan to work to the best of my knowledge and
> simultaneously learn during the project.
>
> Contact details :
>
> Email : adwait.gandhe1990 at gmail.com
>
>            : adwait1990 at gmail.com
>
> Phone : Will be given if requested.
>
>
>
>  --
>
> Adwait Gandhe
> Second Year Undergraduate
> BE(Hons) EEE
> BITS-Pilani, Goa Campus.
> |+919881469181|
> adwait.gandhe1990 at gmail.com
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>