U.S. patent number 7,266,238 [Application Number 11/006,600] was granted by the patent office on 2007-09-04 for color management architecture using phantom profiles to transfer data between transform modules.
This patent grant is currently assigned to Canon Kabushiki Kaisha. Invention is credited to John S. Haikin.
United States Patent |
7,266,238 |
Haikin |
September 4, 2007 |
Color management architecture using phantom profiles to transfer
data between transform modules
Abstract
A color management architecture includes multiple color
transform modules chainable together by a framework, with each
color transform module having access to color profiles which
provide data necessary to convert color data in accordance with
algorithmic functionality in the transform modules. The color
profiles are stored in accordance with a pre-designated format,
such as a standardized format that is neither vendor specific nor
platform specific. Each color transform module further includes the
functionality to read to and write from a phantom profile. The
phantom profile is also organized in the same pre-designated
format, and thus serves as a primary conduit for data transfer
between chained ones of the color transform modules.
Inventors: |
Haikin; John S. (Fremont,
CA) |
Assignee: |
Canon Kabushiki Kaisha (Tokyo,
JP)
|
Family
ID: |
25114781 |
Appl.
No.: |
11/006,600 |
Filed: |
December 8, 2004 |
Prior Publication Data
|
|
|
|
Document
Identifier |
Publication Date |
|
US 20050094875 A1 |
May 5, 2005 |
|
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
09778925 |
Feb 8, 2001 |
6831999 |
|
|
|
Current U.S.
Class: |
382/162 |
Current CPC
Class: |
H04N
1/603 (20130101) |
Current International
Class: |
G06K
9/00 (20060101) |
Field of
Search: |
;382/162-167,302-305,276
;358/1.9,500-530 ;348/222.1 ;345/589-604,629 ;715/528 |
References Cited
[Referenced By]
U.S. Patent Documents
Other References
"File Format For Color Profiles", ICC Specification No.
ICC.1:1998-09 (1998), as amended by "Addendum 2", Document No.
ICC.1A:1999-04 (1999). cited by other.
|
Primary Examiner: Sherali; Ishrat
Attorney, Agent or Firm: Fitzpatrick, Cella, Harper &
Scinto
Parent Case Text
This application is a division of application Ser. No. 09/778,925,
filed Feb. 8, 2001, now U.S. Pat. No. 6,831,999, the contents of
which is incorporated herein by reference.
Claims
What is claimed is:
1. A color management architecture, comprising: multiple transform
modules for effecting a color transformation; multiple color
profiles each including information necessary to effect the color
transformation; and a framework for chaining together multiple ones
of the plural transform modules so as to effect a commanded color
transformation; wherein said transform modules each having a
function to read information described in a pre-designed format and
the information from the color profile; and wherein a storing area
for said information described in the pre-designed format is an
interface for transferring data between said multiple transform
modules.
2. A color management architecture according to claim 1, wherein
one of said transform modules transforms color data in a source
device color space into color data in a device independent color
space.
3. A color management architecture according to claim 1, wherein
one of said transform modules performs gamut mapping.
4. A color management architecture according to claim 1, wherein
one of said transform modules transforms gamut mapped color data
into color data of a designated device color space.
5. A color management architecture according to claim 1, wherein at
least one of the multiple transform modules writes color
transformed data in the storing area for said information in the
pre-designed format.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to color management architecture in
which plural transformation modules each act to transform color
data from an input side to an output side, and particularly relates
to use of a phantom profile so as to transfer data from one
transformation module to another.
2. Description of the Related Art
Since 1993, the International Color Consortium
(HTTP://www.color.org/) has acted to promote a standardized
architecture and standardized components for an open,
vendor-neutral, cross-platform color management system. A
representative architecture using such components is illustrated in
FIG. 1. As seen there, an application 10 executing under an
operating system has access to a graphics library 11 and an imaging
library 12. To perform color management functionality, application
10 accesses a color management framework interface 14, which in
turn has access to color profiles 15 and a default color management
module 16. Interface 14 also allows access to third party color
management modules illustrated diagrammatically at 17 and 18.
Profiles 15 provide the color management modules with information
necessary to transform color data, such as a conversion between a
native device color space and a device independent color space. For
each different kind of color device, different algorithmic models
are described which perform transformation between the color spaces
based on the color information in the color profiles 15. These
algorithmic models are realized programmatically within
transformation modules of the color management modules, as
illustrated below in FIG. 2.
FIG. 2 shows a color management framework in which three
transformation modules serially perform color transformation, each
between an input side and an output side. The overall result of
processing by the three modules illustrated in FIG. 2 might, for
example, correspond to a transformation from an input device color
space to a device neutral color space (module 1), a gamut mapping
so as to ensure that colors properly are within the outputable
gamut of an output device (module 2), and a transformation from the
gamut-mapped device independent color space into an output color
space (module 3). As seen in FIG. 2, a first module 20 derives
input from a variety of different sources. For example, in the
context of FIG. 2, module 20 derives input information from four
different sources. First, input information is passed as a
parameter from the color management framework 14 as part of an
initial function call that activates module 20. Second, module 20
access data in one of the color profiles 15 which define the color
information necessary to convert color data between color spaces.
Third, local data 24 is maintained in an area accessible only by
the module itself, such as pre-designated data specific to
initialization of the module. Fourth, each module can access global
data in a global data pool 25.
Recently, color management has focused on the construction of a
color management pipeline in which a pipeline script defines
transformation modules that apply serially, step-by-step, so as to
transform color data from a given input to a target output. Because
of a desire to maintain a vendor-neutral, cross-platform color
management system, however, the large variety of data sources
available to the transformation modules causes difficulties. For
example, different platforms and different vendors might pass
parameters differently from framework 14 to each individual module.
And, each individual module might store data differently in global
data area 25, in dependence on the vendor who wrote the module and
the platform on which the module is executing. Particularly in
situations where a color management pipeline is used, because the
global data area 25 is the primary source of transferring data
between the different modules, such a situation can lead to
difficulties in data transfer and can yield unexpected and
unintended color management results.
SUMMARY OF THE INVENTION
It is an object of the invention to address the foregoing
difficulties through use of color transformation modules that
transfer data into and out of the module through a phantom profile
whose organizational format is the same as that of standardized
color profiles.
Thus, according to one aspect of the invention, each of multiple
color transformation modules, which can be pipelined together to
yield a desired color transformation from a desired input color
space to a desired output color space, includes software
functionality that permits the color transform module to write
profiles as well as to read them. One particular profile that is
writable and readable by each color transform module is a phantom
profile. The phantom profile serves as the primary conduit of data
transfer between one color transform module and others, as well as
the primary data conduit for transfer of data from the framework to
the modules.
In particularly preferred embodiments, the phantom profile is
defined in accordance with the format used by other color profiles,
particularly color profiles as standardized by the ICC.
By virtue of the foregoing features, the invention provides for
vendor-neutral cross-platform color management since data is
transferred between color transform modules in a format
corresponding to standard color profiles. Because the profiles are
standardized, vendor-specific and platform-specific anomalies that
might result from data transfer to a global memory area are
avoided.
In particularly preferred embodiments, the color transform modules
are chained together in a pipeline specified by a pipeline script
which defines which modules are needed to transform the data, as
well as which color profiles are needed to supply the color
conversion information. Each module in the pipeline carries with it
its own local data, which is managed by the transform module
itself. This local data is set aside by the module when it
initializes itself, and the local data is then available to the
module whenever the module is actively processing image data. This
local image data is available only to the transform module that
uses and creates it. On the other hand, information from outside
the module, such as information about the characteristics of the
device or information from prior transformation modules, is
provided in standardized format by a profile. Most commonly, the
profiles are either color profiles which contain information
necessary to transform color data, or a phantom profile which
contains data accessible to all transform modules, including data
passed from the framework or data passed from previous color
transform modules.
This brief summary has been provided so that the nature of the
invention may be understood quickly. A more complete understanding
of the invention can be obtained by reference to the following
detailed description of the preferred embodiment thereof in
connection with the attached drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram showing a conventional color management
architecture.
FIG. 2 is a block diagram showing a conventional technique for
transferring data between color transform modules in a color
management framework.
FIG. 3 is a block diagram for explaining transfer of data between
color transform modules according to the invention.
FIGS. 4A, 4B, 4C and 4D are views for comparing functionality of a
conventional color transform module with that of color transform
modules according to the invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 3 is a block diagram showing a representative embodiment of
the invention, in which transform modules, in addition to
functionality permitting the transform module to read a profile,
also include functionality to write to profiles. Briefly, according
to the invention, transform modules transfer data between
themselves, or with the color management framework, by reading and
writing to one or more phantom profiles, as discussed more fully
below.
Thus, as shown in FIG. 3, color management framework 114 provides a
framework for color management including an architecture to convert
color data in a first color space (such as a source device color
space) to a second color space (such as a destination device color
space). Framework 114 works by chaining together color transform
functionality provided by individual ones of multiple transform
modules illustrated here at 120, 121 and 122. The chain provided by
framework 114 can be specified in a pipeline script which is read
by the framework 114. The script is specified, either directly or
indirectly, with a color image for which color management is
desired.
Particularly in the case where a script provides for a
transformation pipeline, the script specifies individual transform
elements in the order that they are to be executed. The sequence of
executable steps is assembled by framework 114 at "runtime", that
is, after the script has been read but before the image is color
managed. The algorithmic functionality needed for each transform
module is taken from a library of pre-designated modules that is
maintained by framework 114. It is intended in this architecture
that the functionality of each transform module is as general as
possible so that it is possible to include the functionality in the
library, along with the script, in the image, or in color profiles
themselves, in order to provide a complete color management
package.
Each transform module includes functionality to read color
profiles. In one aspect that focuses on color characteristics of
devices, color profiles store information needed to convert color
data between color spaces, such as between a native device color
space and a device independent color space. Preferably, color
profiles are correlated with each different device model so as to
provide color characteristics of the model. For example, a first
device profile might be provided in correlation with a first model
of ink jet printers from a manufacturer, and a second device
profile might be provided in correlation with a second model of ink
jet printers from the same manufacturer. It is generally intended
that each different color device (scanners, printers, displays, and
the like) be provided with an individualized device profile
tailored to the color characteristics of the device in question,
although it is possible that in the absence of tailored device data
(for example, in a situation where a manufacturer has not yet or
will not provide tailored color data), default color profiles might
be used instead.
Color profiles also exist to specify information needed for other
types of transformations or mappings, such as transformations to or
from perceptual color spaces, or gamut parameters for gamut mapping
algorithms.
The color profiles are stored in a standardized, pre-designated
format, thereby ensuring that each different transform module can
read the profile, regardless of vendor or platform-specific
differences. In preferred embodiments, the color profiles conform
to the format specified by the International Color Consortium at
"File Format For Color Profiles", ICC Specification No. ICC.1:
1998-09 (1998), as amended by "Addendum 2", Document No. ICC.1A:
1999-04 (1999).
The color profiles specified by the ICC provide for standardized
formats of needed color information, including device transform
color information, gamut mapping information, coordinate transform
information (such as transforms to perceptual color space) and the
like.
In accordance with the invention, and as further shown in FIG. 3,
each transform module includes functionality to write profiles.
Coupled with the functionality to read profiles, each transform
module includes functionality that permits it to read from and
write to a phantom profile 126, although more than a single phantom
profile may be provided in other embodiments of the invention.
Preferably, phantom profile 126 (alone or in conjunction with other
phantom profiles) is the primary interface for transferring data
between multiple ones of the transform modules, and between the
framework 114 and the modules.
In more detail, and assuming framework 114 has chained modules 120,
121 and 122 as shown in FIG. 3, framework 114 deposits parameters
needed to initiate the transform process into phantom profile 126.
First module 120 reads the parameters from the phantom profile, as
well as color data needed for its transform functionality from ICC
profile 115a. After initializing local data 124, transform module
120 performs its color transform algorithmic functionality, for
example, to transform color data from a source device color space
into color data in a device independent color space. At the
conclusion of its transform functionality, first module 120 writes
transformed data back to phantom profile 126 and otherwise
signifies to framework 114 that its transform functionality has
been completed.
Framework 114 then initiates processing by second module 121, again
with any needed parameters being written to phantom profile 126.
Second module 121 initiates its color transform algorithmic
functionality based on information read from phantom profile 126,
together with any information needed by (unshown) color profiles.
For example, second module 121 might perform gamut mapping. When
transform 121 completes its color processing functionality, it
writes its results to phantom profile 126, and otherwise signifies
to framework 114 that its processing has been completed.
Framework 114 then initiates processing of third module 122, again
with parameters needed by module 122 being written to phantom
profile 126. Third module 122 reads needed data from phantom
profile 126 as well as color data from color profile 115b, and
applies its color transform functionality. For example, third
module 122 might transform gamut-mapped color data into destination
device color coordinates. Module 122 writes transformed data to
phantom profile 126, and otherwise signifies to framework 114 that
its processing is complete. Framework 114 then provides the
transformed data back to the software application that initialled
had requested color management.
FIGS. 4B and 4C are block diagrams showing internal functionality
of each of the multiple transform modules chainable by framework
114. FIG. 4A shows transform module functionality according to the
prior art, for comparison purposes. As seen in FIGS. 4B and 4C,
transform modules according to the invention include functionality
to write profiles, including a write to phantom profile(s) which
form the primary conduit for transfer of data between multiple ones
of the transform modules as well as between the framework and the
modules. As seen in FIG. 4B, it is also possible for at least some
of the transform modules to access global memory so as to permit
data transfer, as well as to provide an interface to framework 114
for receiving parameters therefrom. On the other hand, and as shown
in FIG. 4C, at least some of the transform modules might be
constrained such that their only functionality by which data can be
transferred into and out of the transform module is by means of
profile reading and writing. In particular, the module shown in
FIG. 4C simply does not include functionality for access to global
memory, or for an interface with framework 114 for receiving
parameters.
FIG. 4D shows a different embodiment, in which data transfer
between modules is accomplished through reads and writes to a
database in accordance with indexed keys into the database.
Specifically, as seen in FIG. 4D, transform modules include
functionality to read and to write to profiles, primarily to obtain
needed color or transform data for the algorithmic functionality of
the module. In addition, the transform modules include
functionality to read and to write to a database or databases, such
as through a keyed index into the database(s). Through such keyed
reads and writes to the database(s), the transform modules transfer
data between multiple ones of the modules, as well as transfer data
and initialization parameters to and from the framework. It is also
possible for the modules to access the database(s) in connection
with their algorithmic functionality, so as to permit expanded
and/or more customizable features to the algorithmic
functionality.
Other configurations for the modules are possible, such as a
configuration in which only access to global memory is omitted, or
only an interface for receiving parameters is omitted, relative to
the configuration shown in FIG. 4B. In addition, it is possible to
combine modules from the different embodiments in one pipelined
transform, such that some modules have access to global memory and
some do not, for example; and such that some modules transfer data
therebetween via phantom profiles and some do not, as another
example.
The invention has been described with respect to particular
illustrative embodiments. It is to be understood that the invention
is not limited to the above-described embodiments and that various
changes and modifications may be made by those of ordinary skill in
the art without departing from the spirit and scope of the
invention.
* * * * *