Mailinglist Archive: opensuse-project (502 mails)

< Previous Next >
[opensuse-project] Fwd: gsoc proposal : icc device profile repository
  • From: nitin chadha <upcomingnewton@xxxxxxxxx>
  • Date: Sat, 2 Apr 2011 16:39:28 +0530
  • Message-id: <BANLkTi=FTOLW=J2qy8GLsyqU+eAWKU5SxQ@mail.gmail.com>
---------- Forwarded message ----------
From: nitin chadha <upcomingnewton@xxxxxxxxx>
Date: Sat, Apr 2, 2011 at 3:56 PM
Subject: gsoc proposal : icc device profile repository
To: opensuse-project@xxxxxxxxxxxx



hi all, i have made a proposal for device profile repository and i
would like to share it with all.
please provide comments and guide me to submit a better proposal



PROPOSAL FOR ICC DEVICE PROFILE REPOSITORY.



COLOR MANAGEMENT  BACKGROUND



Many a times, it is observed that an image as seen on a monitor may
have color variations when printed. Or a scanned image appears
differently when seen on monitor etc. All these are examples of color
mismatch or poor color management.

 Users are looking for color predictability and consistency. We would
like a colored page to be reproducible on a variety of technologies /
devices / mediums with consistent results.

 In order to get similar results, we must ensure that a colors match
their colorimetric ( or standardized like CIE ) values on different
devices, and hence different color values need to be sent to different
devices ( like monitor for a pc, a printer, a plotter , or may be a
mobile or ipad screen, since every device perceives colors differently
) or applications ( say, gimp or photoshop ) for maintaining
consistency.

Thus, we need a way to take the values that represent the desired
color on one device ( called technically as input profile ) and change
it to corresponding value on other device ( or output profiles, as ICC
calls them ).Also a reference is also needed so that conversion is
consistent( commonly called profile connection space ( PCS), and
generally internationally accepted reference standards are used ).



The transformation is done by a generic transform mechanism using a
color matching module or color matching method (CMM). A CMM is a part
of larger software called color management system (CMS).  A cms
ensures that colors remain same regardless of the device or medium
used to display colors.



PROBLEM BACKGROUND



There are a plenty of color - viewing- mediums in the market ( mediums
may be different devices like monitors, scanners, printers, or they
may be applications like gimp or may be a Smartphone screen, the only
needed thing is that it should support colors in some way or the other
). And each one perceives colors differently. So, whenever images are
transferred from one of these mediums to another, they have
(standardized) attached profiles so that this conversion is smooth and
not a large difference is observed in the colors. Thus, we require
correct ( and the best ) profiles to correctly handle colors
transformations.

Systems like windows and mac have inbuilt color management modules at
os level, so that these conversions  and profiling are done
automatically. However, in linux, color management is not implemented
at os level, hence associated profiles and  transformations are not
very efficient. Hence I propose to build a cross platform solution for
obtaining and using best profiles by applications / devices
automatically.



( Here’s a small example )

( suppose you take a picture from your android phone and transfer it
to pc for manipulation using gimp or for taking a print out. Now,
phone perceives colors in a different way, and your monitor screen (
in case of gimp ) or printer perceives colors differently. Hence, when
picture  is transferred to pc, a profile is sent along. If you open it
using gimp, it is duty of gimp to transfer the image data accordingly
to monitor profile so that you view the colors consistently. If you
want to take a print out, then it is duty of printer settings to do
conversion accordingly.

But for best conversion, we need the best possible profile attached.



BASIC IDEA

The basic idea is the creation of a central repository and a web front
end as well as small command line interface + GUI on client systems.
Whenever, users open color management application on their computer,
then they will have an option to get the best profile from the web
matching their device.  Also, they will have an option to send and
share their profiles with others. Web front end will be a kind of
wiki, where users will rate and comment on the profiles, also they can
ask their questions and where web statistics regarding color devices
and management will be shown. This central database / repository will
be linked with CMS like oyranosCMS etc and various front- ends like
kolor-manager through the client library. An independent client GUI
application will also be developed.



Use Cases

Typical users should not care about color management of their devices.
Their configuration will be handled automatically with little
interaction.
For amateurs, who do not own an expensive measurement device, it can
make color management under Linux affordable and popular.

For experts, it will be a nice way of sharing the best profiles

Companies can directly put the pre configured profiles matching
devices etc in our database.

Technical following projects:
We can Integrate the new system into various setup tools like printer
setup,  or integrate over the Color management solutions etc.

Benefits:
The proposed system will have many benefits. I am presenting some, but
others can be easily thought.



1.     HOME USERS



Optimization will be a big thing. You can take full advantage of your
printers, scanners etc. the proposed system will enable it to download
and use the best profile relating to your scanner and printer. Thus,
enabling to publish or print the image with original colors preserved.

Normal users can very easily and conveniently download and configure
various profiles for different hardware devices like printers,
scanners, phones, pads etc. It will enable much better sharing of
colored images, videos etc. Users need not worry about the technical
details and whatever colors they have picked will be served even if
they change the viewing application or device.



2.     SMALL TO MID RANGE BUSINESS



Small to mid range business for color related tasks like printing
shops etc will be beneficial as they can get best profiles written by
experts for free ( as against buying profiles ). Thus, using linux as
a medium for color management will be affordable and cheap.

3.     MANUFACTURERS

They can put their profiles in our central database directly, whereby,
it will be very convenient for users to have the best profiles.



4.     It will act as an already made repository for fetching icc
files ( like repositories in opensuse ) for future color management
systems.





In short, I would like a way for every application on Linux to
implement the best color possible by connecting it to a centralized
CMS like oyranos, lcms and then getting the best possible profile
according to the hardware it’s going to work on, from the net,
automatically.

The best benefit is to end user, who will be able to exploit the
hardware devices fully with best available profiles available for
them.





Technical Details and Implementation



The whole project is divided in different stages. I will explain the
stages one by one giving their working.



1. MAKING OF CENTRAL DATABASE.



A relational database and a file system as a part of project will be
implemented.



Relational database will have necessary meta data about profiles,
devices, hardware, drivers etc. since expected number of profiles can
run into thousands, hence they are not directly stored in database,
but in some file ( like xml files ) on file system. Only, concerned
Meta data will be stored in database.



File system for storing profiles will have hierarchical structure.

LEVEL - 1 = / ( root of the application ) ( directory )

LEVEL - 2 = different types of devices (like monitors, printers etc )
( directory )

LEVEL - 3 = manufacturer of the device  ( like hp, canon etc ) ( directory )
LEVEL - 4 = specifications ( like make, model etc ) ( directory )

LEVEL - 5 =  here the profile's file will stay. ( files )



BENEFITS OF THIS APPROACH :



1. POSSIBLE TO EXPAND AND CONTRACT THE TREE.

2. EASE OF BACKUP

3. CAN STORE QUITE AMOUNT OF INFORMATION



DRAWBACKS



1.     Possible searching time can be more, if profiles amount is less.



The final structure and  schema of database will be finalized after
discussion with mentor, community and going through the minute
database structure of CMS

Like oyranos , lcms etc( oyranos uses a similar database structure as
proposed here). I will do it before 23 may  i.e. before coding starts.



2. WRITING SERVER SIDE CODE ( SERVER API'S FOR ACCESSING DATABASE BOTH
FROM WEBSITE AS WELL AS FROM END USER'S REQUEST )

 Basically, all coding for inserting, deleting , selecting or updating
the database will be done through this layer. Both website as well as
requests coming from the users will be referencing the code here. This
approach has advantages

   1. Direct access to database is not provided so that nobody cannot
modify database in illegal manner or inconsistent manner.

   2. A uniform platform for all data related tasks - so these api's
can be called from anywhere.

   3. Even tomorrow if we have to change the database, then it will be
very easy as the coding is generic and scalable for future changes



4. Helps in maintaining and extending the code easily.

5. Easy to understand and flexible.

6. Business rules can be made here. For example, we do not won’t that
a duplicate profile should be stored in our data base systems, then we
can make coding accordingly here.



3. WRITING CLIENT SIDE LIBRARY FOR ACCESSING THE DATABASE + MAKING OF CLI.



This will be made in c/c++ . Purpose of this library will be to
exchange the data with central database and share and get profiles.
Medium of data import / export will be either xml or json. This
library will be responsible for all database related tasks and will
act as an intermediate between central database and client
applications. It will provide data to requesting to client app’s like
CLI or various CMS like oyranos, lcms etc. this is essential because
it will provide a consistent api so that in future this code can be
easily integrated with cms directly or with front- ends like
kolor-manager or gnome-color-manager.



4. MAKING OF WEB SITE.

The website part will be either in php/ python. Either it can be made
from scratch or can be made from other content management solutions
like drupal / joomla / django.

Main tasks performed here will be

1. Comments and rating of profiles

2. Display statistics for various profiles / hardware.

3. Getting the expert help.

4. Users can add new profiles to central database from here.

5. Users can download the best profile matching their device from here.



5. WRITING THE GUI FOR THE CLIENT SIDE, (PROBABLY CROSS – PLATFORM).



Now, client side api’s already written, it’s time to write the client
side GUI probably in QT, which will be totally cross platform so that
application runs on gnome or kde equally well.





6. INTEGRATION WITH KOLOR MANAGER + WRITING A WRAPPER LIBRARY FOR OYRANOS.



lastly, i would love to take this opportunity to integrate the code
with the applications like kolor-manager and various databases running
at os level like oyranos, so that they can select the best profile
matching hardware on client’s system themselves automatically.





TIMELINE



BEFORE MAY 23 – finalise the database structure and schema. Making use
case diagrams , finalizing classes ( in short, completeion of SRS ).
Also, reading  and understanding of documentation of various color
management systems.



May 23 – may 29 – making database, writing stored procedures ,
triggers etc ( wherever necessary ).



May 30 – june 5 – 1st week of writing server side code ( start )

June  6 – june 12 – 2nd week of writing server side code. ( finalizing
server side code, testing etc )



June 13 – june 19 – 1st week on client side library. ( start )

June 20 – june 26 – 2nd week of writing client side library. (
finalizing and testing )

June 27 – july 3 – 3rd week of client side code.( integration with
oyranos, and making and testing command line interface, also
populating the central database with CLI ).

July 4 – july 11  - 4th week of client coding. Making a small qt
application or integrating with already exists GUI like Kolor-manager.



JULY 11  - INTERMEDIATE EVALUATION



July 11 – july 17 – 1st week of starting of website (making users,
administrators etc ).

July 18 – july 24 – 2nd week of website. ( displaying the statistics,
profiles, making the comment and rating system )

July 25 – july 31 – 3rd week of website. ( making comment
system,rating system etc and administrator pages etc )

August 1 – august 7 – 4th week of website. ( giving final touches,
improving css etc )



AUGUST 8 – 15 ie  A PERIOD OF 2 WEEKS HAVE BEEN KEPT AS A BUFFER PERIOD.

If anything goes wrong or is delayed, then it will be corrected in
this period. Else, I will go ahead and start integrating with the
other CMS like  AgryllCMS etc.



Why Me



1.     I have good experience in making websites for my college. I
know php/ python , sql, html, css, js and jquery. I am  eager to learn
django or drupal and will learn one of the cms before gsoc starts. (
it will also benefit me in making other sites after gsoc, so learning
one is on my radar ).

2.     I am learning QT as a part of current curriculum at the
university will have gained a significant experience in it before gsoc
starts.

3.     I have a good grasp of C and C++.

4.     I am hardworking, dedicated and know how to find my way once
pointed in the right direction.

5.     I am free during the summers and have no other preoccupation ,
except an hour of running/exercise in the morning.

6.     I am fluent in English so I would not have any problems with
the conversations with the mentors, I speak Hindi and Punjabi as well.

7.     I have talked extensively with my mentor on irc and through
mail so that project is clear to me.

8.     I  have searched a lot of and proposed various new things,
discussed the topic extensively and proposed the best thing possible
for this project.









ABOUT ME

I am Nitin Chadha,pursuing my undergraduation ( currently, in my
pre-final year) in Computer Science Engineering from Panjab
University, Chandigarh, India. Panjab University is one of the oldest
and best institutions in the country to study science and engineering.
I have been using open suse from 3 years now, and got to know about
GSOC, when one of my friend met open suse members in KDE conference
held in Bangalore this march.



I am deeply interested in linux and playing with javascript. I have
conducted workshops on FOSS at my university. I have undertaken
severly professional linux courses for operating system internals and
device driver programming.

My preferred languages of coding are c, c++ and python ( although I am
getting accustomized to java ).



Regarding websites, I have designed several of them for my
university’s student  related  tasks from time to time. I love to play
with javascript and emulating flash through jquery and javascript.



Contact Information



You can contact me through my mail  or on irc.

I am there on gtalk, twitter and facebook.

email-id = upcomingnewton@xxxxxxxxx

irc-nick = upcomingnewton

phone no. = ( +91 ) 9646441196

im( gtalk ) xmpp:upcomingnewton@xxxxxxxxx



COMMENTS ARE WELCOME AND DISCUSSION AND CRITISM WILL BE HIGHLY
APPRECIATED. ANY IMPROVEMENTS ETC ARE ALSO WELCOME, BEFORE I SUBMIT IT
ON MELANGE PAGE.



--
GREETINGS
NITIN CHADHA




--
GREETINGS
NITIN CHADHA
--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups