GSOC 2010 Proposal : Non-destructive editing of images in digiKam

[Adwait Gandhe]

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 :

[hidden email]

[hidden email]

 

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 : [hidden email]

           : [hidden email]

Phone : Will be given if requested.

 

 -- 

Adwait Gandhe
Second Year Undergraduate
BE(Hons) EEE
BITS-Pilani, Goa Campus.
|[phone]|
[hidden email]

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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 <[hidden email]>:

> 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 :
>
> [hidden email]
>
> [hidden email]
>
>
>
> 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 : [hidden email]
>
>            : [hidden email]
>
> Phone : Will be given if requested.
>
>
>
>  --
>
> Adwait Gandhe
> Second Year Undergraduate
> BE(Hons) EEE
> BITS-Pilani, Goa Campus.
> |[phone]|
> [hidden email]
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> 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 ?

Students can apply for more than one proposal but will be selected only for
one.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel