[Digikam-devel] 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 :

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20100325/15fdeb28/attachment.html>