도 1은 본 발명이 구현될 수 있는 적합한 컴퓨팅 시스템 환경(100)의 예를 도시한다. 특히, 도 1은 무선 포인터 장치(161), 예를 들어, 컴퓨팅 시스템 환경(100)의 문맥에서 광학 무선 마우스의 동작을 보여준다. 컴퓨팅 시스템 환경(100)은 적합한 컴퓨팅 환경의 하나의 예일뿐이며 본 발명의 사용이나 기능의 범위에 어 떠한 제한도 가하고자 하는 것은 아니다. 컴퓨팅 환경(100)은 예시적인 운영 환경(100)에 도시된 임의의 컴포넌트 또는 컴포넌트들의 조합에 관련된 어떠한 의존성이나 요구사항을 가지는 것으로 해석되어서는 안 된다.
본 발명은 다수의 기타 범용 또는 특수 목적 컴퓨팅 시스템 환경이나 구성에서 동작가능하다. 본 발명의 사용에 적합할 수 있는 잘 알려진 컴퓨팅 시스템, 환경, 및/또는 구성의 예는 개인용 컴퓨터, 서버 컴퓨터, 포켓형 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋탑 박스, 프로그래밍가능한 소비자 가전기기, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템 또는 장치 등 중 임의의 것을 포함하는 분산 컴퓨팅 환경을 포함하지만 이들로 제한되지는 않는다.
본 발명은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터-실행가능 명령어들의 일반적인 문맥으로 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 통신 네트워크를 통해 연결되는 원격 프로세싱 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서도 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하여 로컬 및 원격 컴퓨터 저장 매체 둘 모두에 위치될 수 있다.
도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태로 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포 넌트들을 프로세싱 유닛(120)에 연결하는 시스템 버스(121)를 포함할 수 있지만 이들로 제한되지는 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 제어기, 주변 버스를 포함하는 다양한 유형의 버스 구조 중 임의의 것일 수 있고, 다양한 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스일 수 있다. 제한을 가하지 않는 예로서, 그러한 아키텍처는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 강화된 ISA(EISA) 버스, 비디오 전자 표준 협회(VESA) 로컬 버스, 및 Mezzanine 버스로도 알려진 주변 컴포넌트 인터커넥트(PCI) 버스를 포함한다.
컴퓨터(110)는 전형적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 가용 매체일 수 있으며, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체 모두를 포함한다. 제한을 가하지 않는 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법이나 기술로 구현된 휘발성 및 비휘발성, 분리형 및 비분리형 매체 모두를 포함한다.
컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD 또는 기타 광학 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하기 위해 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 기타 매체를 포함하지만 이들로 제한되지는 않는다. 통신 매체는 전형적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 반송파와 같은 변조된 데이터 신호 상의 기 타 데이터 또는 기타 전송 메커니즘을 포함하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호에 정보를 인코딩하기 위한 방식으로 설정되거나 변경된 하나 이상의 특성을 갖는 신호를 의미한다. 제한을 가하지 않는 예로서, 통신 매체는 유선 네트워크나 직접-유선 연결과 같은 유선 매체, 및 음향, RF, 적외선 및 기타 무선 매체와 같은 무선 매체를 포함한다. 상기 중 임의의 것의 조합 또한 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.
시스템 메모리(130)는 판독 전용 메모리(ROM)(131) 및 랜덤 액세스 메모리(RAM)(132)와 같은 휘발성 및/또는 비휘발성 메모리의 형태로 컴퓨터 저장 매체를 포함한다. 시작할 때 등에 컴퓨터(110) 내의 구성요소들 사이의 정보 교환을 돕는 기본 루틴을 포함하는 기본 입력/출력 시스템(BIOS)(133)은 전형적으로 ROM(131)에 저장된다. RAM(132)은 전형적으로 데이터 및/또는 즉시 액세스가능하고/거나 현재 프로세싱 유닛(120)에 의해 동작되고 있는 프로그램 모듈을 포함한다. 제한을 가하지 않는 예로서, 도 1은 운영 시스템(134), 어플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시한다.
컴퓨터(110)는 또한 기타 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1은 비분리형 비휘발성 자기 매체를 판독하거나 기입하는 하드 디스크 드라이브(141), 분리형 비휘발성 자기 디스크(152)를 판독하거나 기입하는 자기 디스크 드라이브(151), 및 CD ROM이나 기타 광학 매체와 같은 분리형 비휘발성 광학 디스크(156)를 판독하거나 기입하는 광학 디스크 드라이브(155)를 도시한다. 예시적인 운영 환경에서 사용될 수 있는 기타 분리형/비분 리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM 등을 포함하지만 이들로 제한되지는 않는다. 하드 디스크 드라이브(141)는 전형적으로 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 연결되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 전형적으로 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 연결된다.
상술되고 도 1에 도시된 드라이브들과 관련 컴퓨터 저장 매체는 컴퓨터(110)에 대해 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 예를 들어, 도 1에서, 하드 디스크 드라이브(141)는 운영 시스템(144), 어플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이러한 컴포넌트들은 운영 시스템(134), 어플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일할 수도 있고 상이할 수도 있다는 점을 유의해야 한다. 운영 시스템(144), 어플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)는 여기서 최소한 그것들이 상이한 것들이라는 것을 도시하기 위하여 상이한 번호를 부여받는다. 사용자는 키보드(162) 및 마우스, 트랙볼 또는 터치 패드로 흔히 일컫는 무선 포인팅 장치(161)와 같은 입력 장치를 통해 컴퓨터(110)에 명령어 및 정보를 입력할 수 있다. 본 발명의 실시예에서, 무선 포인팅 장치(161)는 마우스의 움직임을 감지하기 위한 광학 센서를 갖는 마우스로서 구현될 수 있다. 기타 입력 장치들(도시되지 않음)은 마이크, 조이스틱, 게임 패드, 위성 디쉬, 스 캐너 등을 포함할 수 있다. 이러한 장치들 및 기타 입력 장치들은 종종 시스템 버스에 연결되는 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)에 연결되는데, 병렬 포트, 게임 포트 또는 USB와 같은 기타 인터페이스 및 버스 구조에 의해 연결될 수 있다. 도 1에서, 무선 포인터(161)는 무선 채널(199)을 거쳐 사용자 입력 인터페이스(160)와 통신한다. 무선 채널(199)은 전자기 신호, 예를 들어, 라디오 프리퀀시(RF) 신호, 적외선 신호, 또는 가시광선을 이용한다. 모니터(191)나 다른 종류의 디스플레이 장치 또한 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 연결된다. 모니터(191) 외에, 컴퓨터는 또한 스피커(197)와 프린터(196) 같은 기타 주변 출력 장치들을 포함할 수 있고, 그것은 출력 주변 인터페이스(195)를 통해 연결될 수 있다.
컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터들로의 논리적 연결을 사용하는 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스나 기타 공통 네트워크 노드일 수 있으며, 메모리 저장 장치(181)만이 도 1에 도시되지만 전형적으로 컴퓨터(110)와 관련되어 상술된 구성요소들 중 다수 혹은 모두를 포함한다. 도 1에 도시된 논리적 연결들은 근거리 통신망(LAN)(171)과 광역 통신망(WAN)(173)을 포함하지만, 다른 네트워크들도 포함할 수 있다. 그러한 네트워크 환경들은 사무실, 기업 규모 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.
LAN 네트워크 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스나 어댑터(170)를 통해 LAN(171)에 연결된다. WAN 네트워크 환경에서 사용될 때, 컴퓨 터(110)는 전형적으로 인터넷과 같은 WAN(173)을 거쳐 통신을 설정하기 위한 모뎀(172)이나 기타 수단을 포함한다. 내장되거나 외장일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160)나 다른 적합한 메커니즘을 통해 시스템 버스(121)에 연결될 수 있다. 네트워크 환경에서, 컴퓨터(110)와 관련되어 기술된 프로그램 모듈이나 그들의 일부는 원격 메모리 저장 장치에 저장될 수 있다. 제한을 가하지 않는 예로서, 도 1은 원격 어플리케이션 프로그램들(185)을 메모리 장치(181)에 상주하는 것으로 도시한다. 도시된 네트워크 연결들은 예시이고, 컴퓨터들 사이에 통신 링크를 설정하기 위한 기타 수단들이 사용될 수 있다는 것을 잘 알 것이다.
주변 인터페이스(195)는 스캐너(도시되지 않음) 또는 디지털 카메라(194)와 같은 비디오 입력 장치에의 인터페이스일 수 있으며, 출력 주변 인터페이스는 USB 인터페이스를 포함하는 표준화된 인터페이스를 지원할 수 있다. 운영 시스템(134) 또는 어플리케이션(135)에 의해 지원될 수 있는 컬러 관리는 사용자가 컴퓨터 장치들 사이에서 원하는 컬러 전환을 획득하는 것을 돕는다. 컴퓨터 장치는 전형적으로 디지털 카메라(194)와 같은 입력 장치, 모니터(191)와 같은 디스플레이 장치, 및 프린터(196)와 같은 출력 장치로 분류된다. 컬러 관리의 동작은 후술되는 논의에서 보다 상세히 설명된다.
도 2는 본 발명의 실시예에 따라 컬러 관리 시스템에 의해 지원되는 정책 레벨들 사이의 계층적 관계(200)를 도시한다. 관계(200)는 6개의 정책 레벨(201-211)을 포함한다. 정책 레벨(201)(레벨 1 - 시스템 레벨)은 시스템-규모 컬러 관리 제어를 펼치는 제어의 가장 높고 굵은 레벨이다. 실시예에서, 컬러 관리 시스 템은 두 개의 활성 스페이스(활성 스페이스는 프로파일 연결 스페이스로 칭해질 수 있음)를 유지하는데, 작은 활성 스페이스(small working space)와 큰 활성 스페이스(large working space)가 그것이다. 작은 활성 스페이스는 컬러 충실도(fidelity) 및 동적 레인지를 희생하여 이미지 파일의 크기를 최소로 유지하는 전형적인 8-bpch(채널 당 비트) 컬러 스페이스이다. 작은 활성 스페이스는 디폴트로 sRGB이다. 큰 활성 스페이스는 높은 충실도를 갖는 활성 스페이스이다. 큰 활성 스페이스는 증가하는 파일의 크기 및 동작 속도를 희생하여 이미지 파일의 품질을 유지하기 위하여 전형적으로 8-bpch보다 크다. 큰 활성 스페이스는 디폴트로 scRGB(32-bpch, 부동 소수점)이다.
컬러 관리 시스템은 표 1에 도시된 바와 같이 작은 활성 스페이스나 큰 활성 스페이스로 이미지 파일을 전환할 때 명기된 범위 맵핑에 대해 3가지 품질 설정을 지원한다.
표 1: 품질 설정 |
품질 설정 |
활성 스페이스로의 맵핑 |
Q1 |
크기에 대한 최적화 |
Q2 |
손실이 없음을 보장 |
Q3 |
품질에 대한 최적화 |
제1 품질 설정 Q1(크기에 대한 최적화)은 명기된 범위 맵핑(논의될 렌더링 인텐트에 대해 논의한 바와 같이)이 이미지 파일을 작은 활성 스페이스로 전환하도록 전환을 최적화한다. 이미지 파일에 대한 모든 동작이 작은 활성 스페이스에서 수행된다. 작은 활성 스페이스의 제한된 8-bpch 충실도는 일반적으로 큰 동적 레인지(큰 범위) 또는 높은 컬러 충실도에 관련되지만 둘 다에 관련되지는 않는다. 이미지 파일이 지나치게 프로세싱되면 충실도가 감소될 수 있다. 8-bpch 이상을 갖는 이미지 파일들은 8-bpch로 스케일이 다운된다. 제2 품질 설정 Q2(손실 없음을 보장) 경우, 8-bpch 이하의 데이터를 갖는 이미지 파일은 작은 활성 스페이스로 전환된다. 8-bpch보다 큰 데이터를 갖는 이미지 파일들은 큰 활성 스페이스로 맵핑된다. 결과적으로, 이미지 파일은 전형적으로 제3 품질 설정 Q3(하기에 설명된 바와 같음)의 품질 이득에 의해 특징지워지지만, 제1 품질 설정에서보다 많은 메모리 자원을 요구한다. 제3 품질 설정 Q3(품질에 대한 최적화)의 경우, 컬러 관리 시스템은 이미지 파일에 대한 모든 동작이 큰 활성 스페이스에서 수행되도록 모든 이미지 파일을 큰 활성 스페이스로 전환한다. 큰 활성 스페이스가 scRGB 컬러 스페이스에 대해 구성되면, 이미지 파일은 수퍼/서브-전광 값 지원(super/sub-luminal value support)을 갖는 클립핑에 대한 더 큰 면역성, 높은 컬러 정밀도로 인한 충실도의 유지, 및 신뢰할 수 있는 컬러 재생성을 갖는다. 그러나, 8-bpch 이미지 파일의 프로세싱은 제1 또는 제2 품질 설정(Q1 또는 Q2)보다 4배 더 큰 메모리(memory footprint)를 요구한다.
제1 및 제3 품질 설정(Q1 및 Q3)의 경우, 이미지 파일의 전환은 이미지 파일이 대응하는 더 작은 활성 스페이스로 전환될 것(예를 들어, scRGB 컬러 스페이스를 갖는 이미지 스페이스가 작은 활성 스페이스로 전환될 것)을 요구하거나 더 큰 활성 스페이스로 전환될 것(예를 들어, RGB 컬러 스페이스를 갖는 이미지 스페이스가 큰 활성 스페이스로 전환될 것)을 요구할 수 있다. 그러한 경우에, 렌더링 인텐트 설정은 표 2에 보여진 바와 같이 더 큰 범위로부터 더 작은 범위로 진행할 때 컬러 스페이스들 사이에 컬러를 전환하는 이슈를 핸들링하는 방법을 컬러 관리 시스템에 알려준다.
표 2 : 렌더링 인텐트 |
범위 스페이스 A,B의 비교 |
조건 |
A>B |
A가 B를 포함함. |
A<B |
A가 B에 의해 완전히 포함됨. |
A는 B와 교차함. |
A,B 모두 서로를 포함하지 않음. |
A는 B에 독립적임. |
공통점 없음. |
범위 A로부터 범위 B로 전환할 때, 범위들의 컬러 스페이스가 고려되어야 한다. 컬러 스페이스들이 동일하지 않으면, 컬러 스페이스는 중간 스페이스로 전환되어야 한다. 범위 A는 범위 B와 비교되는데, 4가지 가능한 조건이 존재한다. 첫째, 범위 A가 범위 B를 완전히 포함하는 경우, 범위 스페이스 A가 범위 B보다 크다. 둘째, 범위 A가 범위 B에 의해 완전히 포함되는 경우, 범위 A가 범위 B보다 작다. 셋째, 둘 중 어떤 범위도 나머지 범위를 완전히 포함하지 않는 경우, 범위 A가 범위 B와 교차한다. 넷째, 범위들 사이에 공통점이 존재하지 않는 경우, 범위 A는 범위 B에 독립적이다.
본 발명의 또다른 실시예에서, 2원 범위 맵핑 동작(binary gamut mapping operation)이 지원된다. 예를 들어, 카메라 제조업자는 카메라의 "보고 느끼는 것"을 복제하기 위하여 소스 파일 및 소스 범위 맵을 제공할 수 있는 반면, 프린터 제조업자는 프린터의 "보고 느끼는 것"을 복제하기 위하여 목적지 프로파일 및 목적지 범위 맵을 제공할 수 있다. 실시예에서, 컬러 관리 시스템은 다음 선택들을 선택하는 기능을 지원한다.
ㆍ소스 범위 맵(source gamut map)을 선택
ㆍ목적지 범위 맵(destination gamut map)을 선택
ㆍ소스 범위 맵 및 목적지 범위 맵 둘 중 하나 또는 둘 모두를 오버라이딩
ㆍ소스 맵 및 목적지 맵의 조합의 가중치 비율(1-100%)
소정의 경우에, 컬러 스페이스가 의미없을 수 있도록 컬러 관리를 완전히 디스에이블(disable)할 수 있다. 그러나, 컬러 관리의 활성화로 의미있는 맵핑들이 존재한다. 그러한 경우에, 전형적인 컬러 관리 문맥없이 단순한 산수적(arithmetic) 동작들이 실행된다. 3-채널 RGB로부터 4-채널 CMYK로의 전환이 한 예이다.
도 2를 참조하면, 사용자는 정책 레벨(201)(시스템 레벨)에서 컬러 관리를 완전히 디스에이블하거나 작은 활성 스페이스 및 큰 활성 스페이스를 선택할 수 있다. 더 낮은 레벨의 정책 레벨(즉, 정책 레벨(203, 205, 207, 209, 또는 211))은 정책 레벨(201)을 오버라이딩할 수 있다. 그러나, 정책 레벨(201)은 더 낮은 정책 레벨의 기능이 정책(201)을 오버라이딩하는 것을 락아웃(lockout)할 수 있다. 게다가, 오버라이딩/락아웃 메커니즘들은 기타 정책 레벨들을 가지고 구성될 수 있다. 각 정책 레벨(201, 203, 205, 207, 및 209)은 더 낮은 정책 레벨이 정책 레벨의 설정을 오버라이딩할 수 있는지, 사용자를 상기시키는지(prompt) 아닌지, 또는 단순히 사용자의 지시에 따라 요구를 수행하는지에 대한 사용자 제어를 제공하기 위하여 락 기능을 갖는다.
정책 레벨(203)(사용자 레벨)에서, 사용자는 다른 사용자들에 대한 정책에 영향을 주지 않고서 사용자에 대한 정책을 구성할 수 있다. 이러한 기능은 컴퓨터 시스템(예를 들어, 컴퓨터(110))에 의해 지원되는 컬러 관리 시스템이 교육 시스템과 같은 것에서 다수의 사용자에 의해 사용되는 경우 중요할 수 있다.
정책 레벨(205)(동작 레벨)에서, 사용자는 컬러 관리 시스템에 의해 지원되는 동작에 기초하여 컬러 관리를 제어하는 기능을 갖는다. (도 3과 함께 설명될 것과 같이, 동작은 "캡쳐", "디스플레이", "프린트", "로드(load)", 및 "저장", "복사" 및 "붙여넣기"를 포함한다.) 예를 들어, 이미지 파일 로딩이 수행되고 있을 때, 컬러 관리 시스템은 이미지 파일을 항상 scRGB로 전환하도록 구성될 수 있다. 이미지 파일을 프린트할 때, 컬러 관리 시스템은 이미지 파일을 Epson 9600-Premium Luster로 전환하도록 구성될 수 있다. 정책들은 각 지정된 동작에 대하여 구성될 수 있다.
정책 레벨(207)(프로파일 레벨)에서, 사용자는 이미지 파일의 포함된 프로파일 또는 포함된 프로파일의 결핍에 기초하여 컬러 관리를 제어하기 위한 능력을 갖는다. 사용자는 특정 정책들이 충돌할 때 특정 전환을 수행하기를 원할 수 있다.
정책 레벨(209)(장치 및 코덱 레벨)에서, 사용자는 장치 및 코덱(이미지 파일의 포맷)에 따라 컬러 관리 시스템에 의한 전환을 제어할 수 있다.
정책 레벨(211)(컬러 관리 API)에서, 어플리케이션은 컬러 동작을 수행하기 위하여 컬러 관리 API에 API 호출을 직접 행할 수 있다. (컬러 관리 API는 도 14 및 15와 함께 보다 상세히 논의된다.) 실시예에서, 정책 레벨(209)은 전형적으로 사용자에게 노출되지 않는다.
도 3은 정책 레벨들(201, 203, 205, 및 209)에 대응하는 계층적 정책 스키마(300)의 스키마를 도시한다. 정책은 시스템(301)에 대해 수립될 수 있다. 만약 정책이 더 낮은 정책 레벨들에 대해 구성되지 않는다면, 시스템 레벨(201)에서 구성된 정책은 컬러 관리 시스템에 의해 이용된다. 그러나, 정책 레벨(201)이 더 낮은 레벨 정책을 락아웃하지 않는다면 더 낮은 레벨 정책이 정책 레벨(201)에 의해 설정된 정책을 오버라이딩할 수 있다.
도 3에 도시된 스키마에서, 사용자 레벨(203)에 관련된 3개의 사용자 엔터티(303, 305, 및 307) 각각은 컴퓨터(110)의 상이한 사용자들에 대응할 수 있고, 각 사용자는 다른 사용자들에게 영향을 주지 않고서 사용자의 환경에 대한 정책을 구성할 수 있다. 그러나, 다른 실시예들에서, 사용자 엔터티들(303, 305, 및 307)은 다른 관련에 대응할 수 있다. 예를 들어, 사용자 엔터티들(303, 305, 및 307)은 사용자의 상이한 고객들에 대응할 수 있고, 각 고객은 상이한 정책 설정을 요구하는 상이한 컬러 관리 목표를 갖는다.
캡쳐 동작(309), 디스플레이 동작(311), 프린트 동작(313), 로드/저장 동작(315), 복사 동작(308), 및 붙여넣기 동작(316)은 동작 레벨(205)에 관련되며, 정책 구성 설정들은 동작의 유형에 따라 다르다. 각 동작은 그 동작을 지원할 수 있는 장치들에 계층적으로 관련된다.
상이한 장치들은 장치/코덱 레벨(209)에서 상이한 정책 설정을 가지고 구성될 수 있다. 예를 들어, 도 3에 도시된 바와 같은 캡쳐 동작(309)은 예를 들어, 카메라(317) 및 스캐너(319)와 같은 다수의 입력 장치에 관련될 수 있고, 각 장치 유형은 상이한 정책 설정에 관련된다. 로드/저장 동작(315)은 JPEG 포맷(321), TIFF 포맷(323), 및 GIF 포맷(325)을 포함하는 상이한 코덱 (포맷) 유형에 관련될 수 있다. 디스플레이 동작(311)은 상이한 모니터 장치들(도시되지 않음)에 관련될 수 있다. 프린트 동작(313)은 상이한 프린터 장치들(도시되지 않음)에 관련될 수 있다. 각 장치 유형에 대하여, 상이한 장치 모델들이 특정 정책 설정을 가지고 구성될 수 있다. 예를 들어, D1X 모델(327) 및 D100 모델(329)은 카메라(317)에 관련된다. 계층적 정책 스키마(300)에 도시되지 않지만, 본 발명의 다른 실시예들은 어플리케이션 레벨 상에서 정책을 지원할 수 있다.
스키마(300)에 따라, 컬러 관리 설정들은 텍스트 파일, 예를 들어, 각 정책 레벨에 대한 컬러 관리 설정들이 적어도 하나의 속성을 가지고 표현되는 확장 마크업 언어(XML) 파일로서 표현될 수 있다. XML 파일은 정책 설정들이 오염되는 경우나 또다른 컴퓨터의 정책 설정에 따르게 하기 위한 경우, 컴퓨터(110) 상에서 정책 구성을 용이하게 한다.
도 4는 본 발명의 실시예에 따른 컬러 관리 시스템(400)의 아키텍처를 도시한다. 컬러 관리 시스템(400)은 컬러 프로세싱 모듈(401), 구성 모듈(411), 사용자 인터페이스(413), 및 인터페이스 모듈(421)을 포함한다. 컬러 프로세싱 모듈(401)은 컬러 관리 모듈(CMM)(407), 선택된 프로파일들(405), 및 활성 스페이스(409)를 포함한다. (소정 실시예에서, 컬러 관리 시스템(400)은 구성 모듈(411)을 통해 정책 설정을 구성함으로써 정책 설정들에 의해 구성된 바와 같은 다수의 컬러 관리 모듈 중 하나로부터 선택할 수 있다.) 컬러 관리 모듈(407)은 선택된 프로파일(405)에 있는 컬러 데이터를 사용하여 RGB 또는 CMYK 값들을 전환하는 소프트웨어 엔진이다. 프로파일은 소스 장치(415)(예를 들어, 디지털 카메라)에 관련될 수 있는 반면, 또다른 프로파일은 목적지 장치(417)에 관련될 수 있다. 그러나, 예를 들어, 디스플레이 장치와 같은 소정 유형의 장치들의 경우, 디스플레이 장치가 입력 및 출력 장치 둘 모두로서 기능할 수 있기 때문에, 프로파일은 2-방향(즉, 장치 스페이스로부터 활성 스페이스로 및 활성 스페이스로부터 장치 스페이스로)일 수 있다. 프로파일이 이미지 파일에 포함되는 경우, 프로파일은 컬러 관리 시스템(400)에 의해 가정되고 선택되거나, 이미지 파일로부터 획득될 수 있다. 프로파일(405)을 사용하여, 컬러 관리 모듈(407)은 컬러들이 프로파일(405)로부터 샘플 포인트들을 사용하여 활성 스페이스에서 어떻게 계산되는지를 결정한다. 컬러 관리 모듈(407)은 전형적으로 프로파일 연결 스페이스(PCS)로 불릴 수 있는 활성 스페이스(409)에서 값들을 결정하기 위하여 프로파일 샘플 포인트들 사이에 보간법(interpolation)을 수행한다. 활성 스페이스(409)는 사용자 인터페이스(413)로부터의 구성 모듈(411)로부터 획득되는 정책 설정들에 따라 범위 맵핑에 의해 결정되는 바와 같이 큰 활성 스페이스 또는 작은 활성 스페이스일 수 있다. 사용자는 일련의 다이얼로그 박스와 상호작용함으로써 사용자 인터페이스(413)를 통하여 정책 설정들을 구성할 수 있다. (정책 설정들을 구성하는 것은 도 5-12와 함께 보다 상세히 논의된다.) 구성 모듈(411)은 인터페이스 모듈(421)을 통하여 컴포넌트(419)로부터의 입력에 포함되는 정책 설정을 수신할 수 있다. 실시예에서, 컴포넌트(419)는 컬러 관리 시스템(400)으로부터 정책 설정들을 설정하거나 얻기 위해 어플리케이션 프로그램 인터페이스(API)를 이용하는 어플리케이션이다.
컬러 관리 모듈(407)에 의해 정의된 보간 알고리즘을 사용하여, 컬러 관리 시스템(400)은 소스 장치(415)에 대한 테이블 및 목적지 장치(417)에 대한 테이블을 형성한다. 컬러 관리 시스템(400)은 공통 활성 스페이스를 통해 두 테이블을 함께 연결하여, 소스 장치(415) 및 목적지 장치(417)로부터 직접 진행하는 결합된 테이블을 형성한다. 그 후 컬러 관리 시스템(400)은 결합된 테이블을 통해 소스 이미지에 있는 각 픽셀을 전달하고, 소스로부터의 값들을 목적지로 전환한다.
컬러 관리 시스템(예를 들어, 컬러 관리 시스템(400))은 사용자가 컬러 관리 워크플로우를 모니터링, 점검(inspect), 문의(interrogate), 정정(correct), 변경(modify), 및/또는 무시(ignore)하도록 허가함으로써 견고한 컬러 관리를 허용한다. 초크 포인트(choke point)의 사용에 의해, 컬러 관리 시스템은 컬러 관리가 수행되었거나 수행될 것이라는 것, 언제 컬러 관리가 수행되었는지 또는 수행될 것인지, 및 누구에 의하여 컬러 관리가 수행되었는지, 수행될 것인지 또는 수행되어야 하는지를 보증한다. 초크 포인트는 배타적인 기능들의 매우 한정된 고정 집합의 한 기능을 통하여 컬러 객체 데이터의 모든 픽셀들이 전송되는 특정 동작에 대한 미리 정의된 접촉 포인트(contact point)로서 정의된다. 실시예에서, 초크 포인트들은 2003년 10월 10일에 출원된 대리인 정리번호 003797.00696, 제목 "충실도를 이용하여 성능의 동적 균형을 가능하게 하는 컬러 관리 시스템(Color Management System That Enables Dynamic balancing of Performance with Flexibility)"인 특허 출원에 개시된 바와 같이 구현되며, 이 특허출원은 전적으로 참고로 통합된다.
도 5는 본 발명의 실시예에 따라 시스템 구성 레벨에서 정책을 설정하기 위한 다이얼로그 박스(500)를 도시한다. 다이얼로그 박스(500)는 사용자 선택 시스템 탭(user selecting system tab)(501)에 응답하여 디스플레이된다. 기타 구성 레벨들은 입력 구성 레벨(탭(503)에 대응함), 디스플레이 구성 레벨(탭(505)에 대응함), 및 출력 구성 레벨(탭(507)에 대응함)을 포함한다. 기타 실시예들에서, 상이한 구성 레벨은 예를 들어, 라디오 버튼과 같은 상이한 구성 지시자를 통하여 선택될 수 있다. 실시예에서, 시스템 구성 레벨은 도 2에 도시된 바와 같이 시스템 정책 레벨(201)에 대응한다. 사용자는 "컬러 관리 인에이블" 객체(509)를 선택함으로써 시스템에 대한 컬러 관리를 전체적으로 인에이블(enable)할 수 있다. 사용자는 "저-정밀도 활성 스페이스" 객체(513)를 통하여 저-정밀도 활성 스페이스(작은 활성 스페이스) 및 "고-정밀도 활성 스페이스" 객체(515)를 통하여 고-정밀도 활성 스페이스(큰 활성 스페이스)를 명기한다. 사용자는 "충실도" 객체(517)를 통하여 시스템-규모 범위 맵핑 알고리즘을 명기한다. 객체(517)를 제공받은 선택들은 이전에 논의된 것과 같은 품질 설정과 일치한다. 또한, 설명 텍스트 객체(519)는 상이한 다이얼로그 박스들을 거쳐 네비게이팅할 때 사용자 조력 및 길잡이를 제공한다.
소정 실시예들에서, 다이얼로그(500)는 또다른 다이얼로그 박스(도시되지 않음)가 디스플레이될 수 있도록 다수의 사용자 탭을 제공하여, 대응하는 사용자가 다른 사용자들에게는 속하지 않고 단지 그 사용자에게만 속하는 정책 설정들을 입력할 수 있다. 다수의 사용자에 의해 공유되는 컴퓨터 시스템에서 이 기능이 유용할 수 있다.
도 6은 본 발명의 실시예에 따라 입력 장치 구성 레벨에서 정책을 설정하기 위한 다이얼로그 박스(600)를 도시한다. 다이얼로그 박스(600)는 입력 구성 탭(503) 및 장치 우선순위 탭(601)을 선택하는 사용자에 응답하여 디스플레이된다. 기타 우선순위 입력 탭들은 사용자에 의해 선택되면 각각 다이얼로그 박스들(700, 800, 및 900)에 대응하는 경로 우선순위 탭(603), 포맷 우선순위 탭(605), 및 프로파일 우선순위 탭(607)을 포함한다. 우선순위 입력 지시자들(우선순위 입력 탭들에 대응)에 대한 우선순위의 순서(가장 높은 우선순위로부터 가장 낮은 우선순위)는 "장치" 다음이 "경로"이고, 그 다음이 "포맷", 그 다음이 "프로파일"이다. 인커밍 이미지(incoming image)들은 낮은 우선순위 규칙들 이전에 높은 우선순위 규칙들에 대하여 매칭된다.
"입력 장치 리스트" 객체(609)는 예를 들어, 컴퓨터(110)와 같은 컴퓨터에 이미지들을 전달할 수 있는 장치들의 리스트이다. 객체(611)는 객체(609)로부터 선택된 입력 장치를 디스플레이한다. "이 입력 장치에 대한 컬러 관리 정책 인에이블" 객체(621)는 장치에 대한 전역 설정(global setting)이다. 객체(621)가 클리어(clear)되면, 모든 다른 제어들(도시되지 않음)이 디스에이블되고, 인커밍 이미지들에 대해 적용되는 규칙들의 집합에 장치가 포함되지 않는다.
"컬러 관리" 객체(623)는 컬러 관리 시스템(400)이 컬러 관리를 묵묵히 핸들링하는지 아니면 컬러 관리 결정에 대하여 사용자가 런타임시에 상기되어야 하는지를 나타낸다. 객체(623)가 "수동"으로 설정된다면, 탭에 대한 나머지 제어들은 디스에이블된다(도시되지 않음). 도 6에 도시된 바와 같이, 객체(623)가 "(정책에 따라) 자동"으로 설정되면, 컬러 관리 결정은 정책에 따라 자동으로 결정된다.
"프로파일을 갖는 이미지" 객체(613)는 포함된 프로파일을 갖는 이미지인 경우 무엇을 할지에 대한 정책을 설정한다. 객체(613)가 "프로파일 존중"으로 설정되면, 컬러 관리 시스템(400)은 이미지의 프로파일에 의해 나타내어진 컬러 스페이스로부터 전환한다. 객체(613)가 "할당"으로 설정되면, 컬러 관리 시스템(400)은 이미지의 포함된 프로파일을 무시하고, 포함된 프로파일 대신 명기된 프로파일을 사용한다.
"프로파일을 갖지 않는 이미지" 객체(615)는 프로파일을 갖지 않는 이미지인 경우 무엇을 할지에 대한 정책을 설정한다. 객체(615)가 "할당"으로 설정되면, 컬러 관리 시스템(400)은 명기된 파일을 사용하고, (만약 선택된다면) 이미지를 할당된 프로파일 컬러 스페이스로부터 활성 스페이스로 전환할 수 있다. 객체(615)가 "무엇을 할지 문의"로 설정되면, 컬러 관리 시스템(400)은 그러한 상황이 발생한 때에 사용자에게 상기시킨다.
"범위 맵핑" 객체(617)는 전환의 주요 구성요소들이 어떻게 발생하는지를 제어한다. 옵션들의 리스트는 "시스템 설정 사용"에 대한 부가적인 선택의 경우인 도 5에 도시된 바와 같이 객체들(513 및 515)에 제공된 옵션들의 리스트에 유사(이 실시예에서는 동일)하다. 객체(619)는 다이얼로그 박스(600)에 관련된 설명 텍스트를 제공한다.
도 7은 본 발명의 실시예에 따라 액세스 경로에 관련된 입력 장치 구성 레벨에 대한 정책을 설정하기 위한 다이얼로그 박스(700)를 도시한다. 다이얼로그 박스(700)는 사용자 선택 입력 구성 탭(503) 및 경로 우선순위 탭(603)에 응답하여 디스플레이된다. 객체들(713, 715, 717, 719, 721, 및 723)은 도 6에 도시된 객체들(613, 615, 617, 619, 621, 및 623)에 대응한다. "경로 리스트" 객체(701)는 이미지 파일에 대해 선택가능한 경로들을 나열한다. "경로 추가" 객체(725)는 사용자가 "경로 리스트" 객체(701)에 경로를 추가할 수 있게 한다. 다이얼로그 박스(700)는 기타 이미지 파일들과 독립적으로 취급되도록 기타 이미지들(예를 들어, 포토그래퍼의 이미지 라이브러리에 있는 파일들)을 취급하도록 사용자가 컬러 관리 시스템(400)에게 지시하는 것을 가능하게 한다. 또한, 경로 지정은 네트워크 이미지 장치들에 적용될 수 있다.
도 8은 본 발명의 실시예에 따라 포맷 유형에 의해 특징지워지는 입력 장치 구성 레벨에 대한 정책을 설정하기 위한 다이얼로그 박스(800)를 도시한다. 다이얼로그 박스(800)는 사용자 선택 입력 구성 탭(503) 및 포맷 우선순위 탭(605)에 응답하여 디스플레이된다. 객체들(813, 815, 817, 819, 821, 및 823)은 도 6에 도시된 객체들(613, 615, 617, 619, 621, 및 623)에 대응한다. "포맷 리스트" 객체(801)는 (코덱으로 불릴 수 있는) 선택가능한 이미지 파일 포맷들을 나열한다. 포맷 유형들은 TIFF(tagged image file format), JPEG(Joint Photographic Experts Group), 및 GIF(graphics interchange format)를 포함한다. "포맷 추가" 객체(825)는 사용자가 "포맷 리스트" 객체(801)에 포맷을 추가하는 것을 가능하게 한다.
도 9는 본 발명의 실시예에 따라 프로파일에 관련된 입력 장치 구성 레벨에 대한 정책을 설정하기 위한 다이얼로그 박스(900)를 도시한다. 다이얼로그 박스(900)는 사용자 선택 입력 구성 탭(503) 및 프로파일 우선순위 탭(607)에 응답하여 디스플레이된다. 객체들(913, 917, 919, 921, 및 921)은 도 6에 도시된 객체들(613, 615, 617, 619, 621, 및 623)에 대응한다. "컬러 관리 프로파일 리스트" 객체(901)는 이미지 파일에 포함될 수 있는 프로파일들을 나열한다.
도 10은 본 발명의 실시예에 따라 디스플레이 장치 구성 레벨에 대한 정책을 설정하기 위한 다이얼로그 박스(1000)를 도시한다. 다이얼로그 박스(1000)는 사용자 선택 디스플레이 구성 탭(505)에 응답하여 디스플레이된다. 객체들(1019, 1021, 및 1023)은 도 6에 도시된 객체들(619, 621, 및 623)에 대응한다. "디스플레이 리스트" 객체(1001)는 사용자에 의해 선택될 수 있는 디스플레이 장치들을 나열한다. 선택된 디스플레이 장치는 객체(1003)에 디스플레이된다. 객체(1025)는 선택된 디스플레이 장치에 대해 대응하는 프로파일을 사용자가 선택하는 것을 가능하게 한다. 부가적으로, 사용자는 객체(1027)로부터의 선택에 따라 디스플레이 장치를 주기적으로 재조정하도록 상기될 수 있다.
도 11은 본 발명의 실시예에 따라 출력 장치 구성 레벨에 대한 정책을 설정하기 위한 다이얼로그 박스(1100)를 도시한다. 다이얼로그 박스(1100)는 사용자 선택 출력 구성 탭(507) 및 장치 우선순위 탭(1101)에 응답하여 디스플레이된다. "출력 장치 리스트" 객체(1107)는 사용자가 선택할 수 있는 출력 장치들을 나열한다. 객체들(1117, 1119, 1121, 및 1123)은 도 6에 도시된 객체들(617, 619, 621, 및 623)에 대응한다. 객체들(1125, 1127, 1129, 및 1131)은 출력 장치의 현재의 프로파일을 사용할지, 또다른 프로파일을 명기할지, 또는 이러한 상황이 발생할 때마다 사용자에게 문의할지를 사용자가 명기할 수 있게 한다.
도 12는 본 발명의 실시예에 따라 액세스 경로에 관련된 출력 장치 구성 레벨에 대한 정책을 설정하기 위한 다이얼로그 박스(1200)를 도시한다. 다이얼로그 박스(1200)는 사용자 선택 출력 구성 탭(507) 및 경로 우선순위 탭(1103)에 응답하여 디스플레이된다. "출력 경로 리스트" 객체(1205)는 사용자가 선택할 수 있는 출력 경로들을 나열한다. 사용자는 "경로 추가" 객체(1233)를 통하여 경로를 추가하거나 "경로 제거" 객체(1235)를 통하여 경로를 제거할 수 있다. 객체들(1117, 1119, 1121, 및 1123)은 도 6에 도시된 객체들(617, 619, 621, 및 623)에 대응한다. 객체들(1225, 1227, 1229, 및 1231)은 도 11에 도시된 객체들(1125, 1127, 1129, 및 1131)에 대응한다.
도 13은 본 발명의 실시예에 따라 포맷 유형에 의해 특징지워지는 출력 장치 구성 레벨에 대한 정책을 설정하기 위한 다이얼로그 박스(1300)를 도시한다. 다이얼로그 박스(1300)는 사용자 선택 출력 구성 탭(507) 및 포맷 우선순위 탭(1105)에 응답하여 디스플레이된다. "출력 포맷 리스트" 객체(1305)는 사용자가 선택할 수 있는 포맷들(도 8에 도시된 포맷들과 유사함)을 나열한다. 사용자는 "포맷 추가" 객체(1333)를 통해 포맷을 추가할 수 있고 "포맷 제거" 객체(1335)를 통해 포맷을 제거할 수 있다. 객체들(1117, 1119, 1121, 및 1123)은 도 6에 도시된 객체들(617, 619, 621, 및 623)에 대응한다. 객체들(1325, 1327, 1329, 및 1331)은 도 11에 도시된 객체들(1125, 1127, 1129, 및 1131)에 대응한다.
다이얼로그 박스들(500-1300)은 도 5-13에 도시된 바와 같은 상이한 구성 레벨들(501-507) 사이 및 도 2-3에 도시된 바와 같은 정책 레벨들(201-211) 사이의 맵핑을 내포하지만, 본 발명의 다른 실시예들은 구성 레벨들과 정책 레벨들 사이의 상이한 맵핑을 이용할 수 있다.
도 14는 본 발명의 실시예에 따라 컬러 관리 시스템(400)으로의 프로그램 인터페이스 호출을 이용하는 요청 컴포넌트(requesting component)(1401)를 도시한다. 실시예에서, 요청 컴포넌트(1401)가 다른 실시예에서 컴퓨터(110)로의 주변 하드웨어 내에 통합되거나 도 1에 도시된 바와 같은 운영 시스템(134) 내에 통합될 수 있지만, 요청 컴포넌트(1401)는 어플리케이션이다.
요청 컴포넌트(1401)는 도 4에 도시된 바와 같이 사용자 인터페이스(413) 및 구성 모듈(411)을 통하여 사용자가 정책 설정들을 입력하는 도 5-13(다이얼로그 박스들(500)-(1300)에 대응함)에 기술된 정책 설정들에 유사할 수 있는 정책 설정들을 설정함으로써 컬러 관리 시스템(400)을 구성할 수 있다. 정책 설정은, 예를 들어, 컬러 스페이스 및 범위 맵핑의 명기와 같이, 도 5-13에서 상이한 객체들에 대응할 수 있다. 요청 컴포넌트(1401)는 컬러 관리 시스템(400)에 입력(1403)(도 14에 도시된 실시예에서는 API 호출 SET(A,B)임)을 전송한다. 입력(1403)은 파라미터(1409)(정책 설정의 값에 대응함) 및 파라미터(1411)(관련 구성 레벨에 대응함)를 포함한다. 입력(1403)에 응답하여, 컬러 관리 시스템(400)은 파라미터(1413)가 정책 설정의 값이 성공적으로 갱신되었는지를 나타내는 결과(RETURN RESULT(1407)에 대응함)를 리턴한다.
또한, 요청 컴포넌트(1401)는 정책 설정의 현재 값을 획득하기 위하여 입력(1405)(실시예에서 API 호출 GET(A,B)임)을 컬러 관리 시스템(400)에 전송할 수 있다. 파라미터(1409)는 정책 설정의 식별에 대응하고 파라미터(1411)는 관련 구성 레벨에 대응한다. 입력(1405)에 응답하여, 컬러 관리 시스템(400)은 파라미터(1413)가 정책 설정의 값을 나타내는 결과(RETURN RESULT(1407)에 대응함)를 리턴한다.
도 15는 본 발명의 실시예에 따라 중간 컴포넌트(1551)를 통해 컬러 관리 시스템(400)으로의 프로그램 인터페이스 호출을 이용하는 요청 컴포넌트(1501)를 도시한다. 도 14에서와 같이, 요청 컴포넌트(1501)는 입력(파라미터(1509 및 1511)를 갖는 입력(1503) 또는 파라미터(1515 및 1517)를 갖는 입력(1505))을 컬러 관리 시스템(400)에 전송한다. 그러나, 입력은 또다른 어플리케이션이거나 유틸리티 프로그램일 수 있는 중간 컴포넌트(1551)를 통해 전송된다. 중간 컴포넌트(1551)는 입력을 컬러 관리 시스템(400)에 전달한다. 또한, 중간 컴포넌트(1551)는 파라미터(1513)가 결과를 나타내는 결과(RETURN_RESULT(1507))를 요청 컴포넌트(1501)에 전달한다.
도 14 및 도 15를 참조하면, 파라미터들(1409, 1415, 1509, 및 1515)이 파라미터 설정들의 리스트를 포함할 수 있는 경우 및 파라미터들(1413 및 1513)이 대응하는 파라미터 설정들 각각에 대한 결과들의 리스트를 포함할 수 있는 경우, 입력들(1403, 1405, 1503, 및 1505)은 각 입력 내에서 다수의 정책 설정을 지원하기 위하여 확장될 수 있다.
프로그래밍 인터페이스(또는 더욱 간략히, 인터페이스)는 코드의 하나 이상의 세그먼트(들)가 코드의 하나 이상의 다른 세그먼트(들)에 의해 제공된 기능과 통신하거나 액세스하는 것을 가능하게 하기 위한 임의의 메커니즘, 프로세스, 프로토콜로 보여질 수 있다. 대안적으로, 프로그래밍 인터페이스는 다른 컴포넌트(들)의 하나 이상의 메커니즘(들), 메소드(들), 함수 호출(들), 모듈(들) 등에 통신으로 연결할 수 있는 시스템의 컴포넌트의 하나 이상의 메커니즘(들), 메소드(들), 함수 호출(들), 모듈(들), 객체(들) 등으로 보여질 수 있다. 앞 문장에서 "코드의 세그먼트"라는 용어는 코드의 하나 이상의 명령어 또는 라인을 포함하고자 하는 것이며, 적용된 기술, 코드 세그먼트들이 개별적으로 컴파일되는지, 또는 코드 세그먼트들이 런타임 시스템이나 프로세스에서 이용되는지, 또는 동일하거나 상이한 기계들에 위치되거나 다수의 기계들에 걸쳐 분산되는지, 또는 코드의 세그먼트들에 의해 표현된 기능이 전적으로 소프트웨어로, 전적으로 하드웨어로, 또는 하드웨어와 소프트웨어의 조합으로 구현되는지에 관계없이, 예를 들어, 코드 모듈, 객체, 서브루틴, 함수 등을 포함한다.
개념적으로, 도 16 또는 17에 도시된 바와 같이, 프로그래밍 인터페이스가 총칭적으로 보여질 수 있다. 도 16은 제1 및 제2 코드 세그먼트들이 통신하는 통로(conduit)로서 인터페이스 Interface1을 도시한다. 도 17은 인터페이스 객체들 I1 및 I2(제1 및 제2 코드 세그먼트들의 부분일 수도 있고 아닐 수도 있음)를 포함하는 인터페이스를 도시하는데, 그것은 시스템의 제1 및 제2 코드 세그먼트들이 매체 M을 통해 통신하는 것을 가능하게 한다. 도 17의 관점에서, 인터페이스 객체 I1 및 I2를 동일한 시스템의 개별 인터페이스들로서 고려할 수 있고, 객체들 I1 및 I2와 매체 M이 인터페이스를 구성하는 것으로 고려할 수도 있다. 도 16 및 17이 플로우의 각 측면에서 양방향 플로우 및 인터페이스를 도시하지만, 특정 구현들은 단지 한 방향으로의 정보 플로우를 가질 수 있고(또는 상기에 기술된 바와 같이 정보 플로우가 없을 수도 있음) 또는 한 측면에서 인터페이스 객체만을 가질 수도 있다. 제한을 가하지 않는 예로서, 어플리케이션 프로그래밍 인터페이스(API), 엔트리 포인트, 메소드, 함수, 서브루틴, 원격 프로시져 호출, 및 컴포넌트 객체 모델(COM) 인터페이스와 같은 용어들은 프로그래밍 인터페이스의 정의 내에 포함된다.
그러한 프로그래밍 인터페이스의 양상들은 제1 코드 세그먼트가 정보("정보"는 가장 넓은 의미로 사용되며 데이터, 명령어, 요청 등을 포함함)를 제2 코드 세그먼트에 전송하는 방법, 제2 코드 세그먼트가 정보를 수신하는 방법, 및 정보의 구조, 시퀀스, 구문(syntax), 조직, 스키마, 타이밍 및 내용을 포함할 수 있다. 이러한 점에서, 인터페이스에 의해 정의된 방식으로 정보가 전달되는 한, 근원을 이루는 전송 매체 자체는 인터페이스의 동작, 매체가 유선인지 무선인지 또는 둘의 조합인지에 중요하지 않을 수 있다. 특정 상황들에서, 하나의 코드 세그먼트가 단순히 제2 코드 세그먼트에 의해 수행된 기능을 액세스할 때와 같이, 정보 전달이 또다른 메커니즘을 통해서(예를 들어, 코드 세그먼트들 사이의 정보 플로우로부터 분리된 버퍼, 파일 등에 놓여진 정보)이거나 존재하지 않을 수 있기 때문에, 정보는 기존의 의미에서는 한 방향 또는 양방향으로 전달될 수 없다. 이러한 양상들 중 임의의 것 또는 모두, 예를 들어, 코드 세그먼트들이 느슨하게 결합된 구성의 시스템의 부분인지 단단히 결합된 구성의 시스템의 부분인지에 의존하는 경우와 같이 주어진 상황에서 중요할 수 있고, 따라서 이 리스트는 예시적이고 제한을 가하지 않는 것으로 고려되어야 한다.
프로그래밍 인터페이스의 이러한 개념은 본 분야에서 숙련된 기술을 가진 자들에게 공지된 것이며, 본 발명의 전술한 상세 설명으로부터 명백하다. 그러나, 프로그래밍 인터페이스를 구현하기 위한 다른 방식들이 존재하고, 명백히 배제되는 경우를 제외하면, 이들 또한 본 상세설명의 끝에 언급된 특허청구범위에 의하여 포함되도록 의도된다. 그러한 다른 방식들은 도 16 및 17의 단순화된 관점보다 더 정교하거나 복잡한 것으로 보일 수 있지만, 그럼에도 불구하고 동일한 전체 결과를 달성하기 위해 유사한 기능을 수행한다. 이제 프로그래밍 인터페이스의 소정 예시적이고 대안적인 구현을 간략히 기술할 것이다.
하나의 코드 세그먼트로부터 또다른 코드 세그먼트로의 통신은 통신을 다수의 개별적인 통신으로 나눔으로써 간접적으로 달성될 수 있다. 이것은 도 18 및 도 19에 스키마적으로 도시된다. 도시된 바와 같이, 소정 인터페이스들은 기능에 대한 분리가능한 집합의 용어로 기술될 수 있다. 따라서, 마치 수학적으로 24를 제공할 수 있고 또는 2*2*3*2를 제공할 수 있는 것과 같이, 도 16 및 17의 인터페이스 기능은 동일한 결과를 달성하도록 분해될 수 있다. 따라서, 도 18에 도시된 바와 같이, 인터페이스의 통신을 전환하기 위하여 동일한 결과를 달성하면서 인터페이스 Interface1에 의해 제공된 기능이 다수의 인터페이스 Interface1A, Interface1B, Interface1C 등으로 세분화될 수 있다. 도 19에 도시된 바와 같이, 인터페이스 I1에 의해 제공된 기능이 동일한 결과를 달성하면서 다수의 인터페이스 I1a, I1b, I1c 등으로 세분화될 수 있다. 유사하게, 제1 코드 세그먼트로부터 정보를 수신하는 제2 코드 세그먼트의 인터페이스 I2는 다수의 인터페이스 I2a, I2b, I2c등으로 분해될 수 있다. 분해할 때, 제1 코드 세그먼트에 포함된 인터페이스들의 수는 제2 코드 세그먼트에 포함된 인터페이스들의 수와 매칭할 필요는 없다. 도 18 및 도 19 중 어떠한 경우에든지, 인터페이스 Interface1 및 I1의 기능적 취지는 각각 도 16 및 도 17에서와 동일하다. 인터페이스들의 분해는 또한 분해가 인지하기 어려울 수 있도록 결합적이고, 교환적이며, 기타 수학적인 속성들을 따를 수 있다. 예를 들어, 동작들의 순서는 중요하지 않을 수 있고, 결과적으로, 인터페이스에 의해 수행된 기능은 인터페이스에 도달하기에 앞서서 코드나 인터페이스의 또다른 일부에 의하여 잘 수행될 수 있거나 시스템의 독립적인 컴포넌트에 의하여 수행될 수 있다. 게다가, 프로그래밍 분야에서 숙련된 기술을 가진 자는 동일한 결과를 달성하는 상이한 함수들을 호출하는 다양한 방식이 존재한다는 것을 잘 알 수 있다.
소정 경우들에, 여전히 의도한 결과를 달성하면서 프로그램 인터페이스의 특정 양상들(예를 들어, 파라미터들)을 무시, 추가 또는 재정의하는 것이 가능할 수 있다. 이것이 도 20 및 21에 도시된다. 예를 들어, 도 16의 인터페이스 Interface1이 3개의 파라미터 입력, 정밀도 및 출력을 포함하고 제1 코드 세그먼트로부터 제2 코드 세그먼트로 발행된 호출인 함수 호출 Square(입력, 정밀도, 출력)을 포함한다고 가정한다. 도 20에 도시된 바와 같이, 만약 주어진 시나리오에서 중간 파라미터 정밀도가 중요하지 않다면, 그것은 무시되거나 의미없는(이 시나리오의 경우) 파라미터로 대체될 수도 있다. 또한, 중요하지 않은 부가적인 파라미터를 추가할 수도 있다. 어떠한 경우에든, 입력이 제2 코드 세그먼트에 의하여 제곱된 후에 출력이 리턴되는 한, Square의 기능은 달성될 수 있다. 정밀도는 컴퓨터 시스템의 소정 다운스트림(downstream) 또는 기타 부분에 매우 의미있는 파라미터일 수 있다. 그러나, 정밀도가 제곱을 계산하는 협소한 목적을 위해 필수적이지 않다는 점이 인지되면, 그것은 대체되거나 무시될 수 있다. 예를 들어, 유효한 정밀도 값을 전달하는 대신, 결과에 거꾸로 영향을 주지 않고서 생일과 같은 의미없는 값이 전달될 수 있다. 유사하게, 도 21에 도시된 바와 같이, 인터페이스 I1은 파라미터들을 무시하거나 인터페이스에 추가하기 위하여 재정의된 인터페이스 I1'에 의해 대체된다. 유사하게 인터페이스 I2는 불필요한 파라미터들, 또는 다른 곳에서 프로세싱될 수 있는 파라미터들을 무시하도록 재정의된 인터페이스 I2'로서 재정의될 수 있다. 여기서 중요한 점은 소정의 경우에 프로그래밍 인터페이스는 소정 목적에 대해 필요로 되지 않는 파라미터와 같은 양상들을 포함할 수 있고, 그래서 그들이 무시되거나 재정의될 수 있으며, 또는 다른 목적을 위하여 다른 곳에서 프로세싱될 수 있다는 점이다.
코드 모듈 사이의 "인터페이스"가 형태를 변화시키도록 두 분리된 코드 모듈의 기능 중 일부 또는 모두를 병합하는 것도 가능할 수 있다. 예를 들어, 도 16 및 17의 기능은 각각 도 22 및 23의 기능으로 전환될 수 있다. 도 22에서, 도 16의 이전의 제1 및 제2 코드 세그먼트가 그들 모두를 포함하는 모듈로 병합된다. 이러한 경우에, 코드 세그먼트들은 여전히 서로 통신할 수 있지만 인터페이스는 하나의 모듈에 더욱 적합한 형태로 적응될 수 있다. 따라서, 예를 들어, 형식적인 Call 및 Return 명령문이 더이상 필요하지 않을 수 있지만, 인터페이스 Interface1에 따르는 유사한 프로세싱 또는 응답(들)이 사실상 여전히 존재할 수 있다. 유사하게, 도 23에 도시된 바와 같이, 도 17로부터의 인터페이스 I2의 일부(또는 모두)는 인터페이스 I1"를 형성하기 위하여 인터페이스 I1 내에 인라인(inline)으로 쓰여질 수 있다. 도시된 바와 같이, 인터페이스 I2는 I2a 및 I2b로 나뉘어지고, 인터페이스 부분 I2a는 인터페이스 I1"을 형성하기 위하여 인터페이스 I1과 함께 인라인(in-line)으로 코딩된다. 구체적인 예를 들면, 도 17로부터의 인터페이스 I1이 함수 호출 square(입력, 출력)을 수행한다고 고려하는데, 이것은 인터페이스 I2에 의해 수신되고, 제2 코드 세그먼트에 의해 입력으로 전달된 값을 (제곱하기 위하여) 프로세싱한 후, 제곱된 결과를 출력으로 다시 전달한다. 그러한 경우에, 제2 코드 세그먼트에 의해 수행된 프로세싱(입력 제곱)은 인터페이스로의 호출없이 제1 코드 세그먼트에 의하여 수행될 수 있다.
하나의 코드 세그먼트로부터 또다른 코드 세그먼트로의 통신은 통신을 다수의 개별적인 통신으로 나눔으로써 간접적으로 달성될 수 있다. 이것은 도 24 및 25에 스키마적으로 도시된다. 도 24에 도시된 바와 같이, 미들웨어의 하나 이상의 부분(들)(본래의 인터페이스로부터 기능 및/또는 인터페이스 기능들을 분리하기 때문에, 분리 인터페이스(Divorce Interface)(들))은 상이한 인터페이스, 이 예에서 인터페이스 Interface2A, Interface2B 및 Interface2C에 맞도록 제1 인터페이스 Interface1 상의 통신을 전환하기 위하여 제공된다. 예를 들어, Interface1 프로토콜에 따라 통신하기 위해 설계되어 설치된 기본 어플리케이션, 즉, 운영 시스템이 존재하지만 운영시스템이 상이한 인터페이스, 이 경우에는 인터페이스 Interface2A, Interface2B 및 Interface2C를 사용하기 위하여 변경되는 경우에, 이것이 행해질 수 있다. 중요한 점은 제1 코드 세그먼트에 의해 사용된 인터페이스와 더이상 호환되지 않도록 제2 코드 세그먼트에 의해 사용된 본래의 인터페이스가 변경되고, 따라서 기존 인터페이스와 새로운 인터페이스들이 호환되도록 하기 위하여 중개자(intermediary)가 사용된다는 점이다. 유사하게, 도 25에 도시된 바와 같이, 제3 코드 세그먼트가 인터페이스 I1으로부터 통신을 수신하기 위한 분리 인터페이스 DI1, 및 인터페이스 기능을 예를 들어, DI2와 동작하고 동일한 기능적 결과를 제공하도록 재설계된 인터페이스 I2a 및 I2b에 전송하기 위한 분리 인터페이스 DI2와 함께 도입될 수 있다. 유사하게, DI1 및 DI2는 도 17의 인터페이스 I1 및 I2의 기능을 동일하거나 유사한 기능적 결과를 제공하면서 새로운 운영 시스템으로 변형하기 위하여 함께 동작할 수 있다.
또다른 가능한 변형은 동일한 전체 결과를 달성하는 것을 제외한 다른 무언가로 인터페이스 기능을 대체하도록 코드를 동적으로 재작성하는 것이다. 예를 들어, 중간 언어(예를 들어, 마이크로소프트 IL, 자바 바이트코드 등)로 표현된 코드 세그먼트가 실행 환경에서 저스트-인-타임(JIT) 컴파일러나 인터프리터에 제공되는 시스템이 존재할 수 있다(.Net 프레임워크, 자바 런타임 환경, 또는 기타 유사한 런타임 유형 환경에 의해 제공된 바와 같이). JIT 컴파일러는 제1 코드 세그먼트로부터 제2 코드 세그먼트로 통신을 동적으로 전환하도록, 즉, 제2 코드 세그먼트(본래의 제2 코드 세그먼트이든지 상이한 제2 코드 세그먼트이든지)에 의해 요구될 수 있는 상이한 인터페이스로 통신을 맞추도록 작성될 수 있다. 이것이 도 26 및 27에 도시된다. 도 26에서 볼 수 있는 바와 같이, 이러한 접근법은 상술된 분리 시나리오와 유사하다. 예를 들어, 설치된 기본 어플리케이션들이 Interface1 프로토콜에 따라 운영 시스템과 통신하도록 설계되었지만 운영 시스템이 상이한 인터페이스를 사용하기 위해 변경된 경우에 행해질 수 있다. 설치된 기본 어플리케이션들로부터 진행중인 통신을 운영 시스템의 새로운 인터페이스에 맞도록 하기 위하여 JIT 컴파일러가 사용될 수 있다. 도 27에 도시된 바와 같이, 인터페이스(들)를 동적으로 재작성하는 이러한 접근법은 인터페이스(들)를 동적으로 분해하거나 그렇지 않으면 변경하기 위해서도 적용될 수 있다.
대안적인 실시예들을 통한 인터페이스로서 동일하거나 유사한 결과를 달성하기 위한 상술된 시나리오들이 다양한 방식들, 직렬 및/또는 병렬, 또는 기타 개입하는 코드를 이용하여 결합될 수도 있다는 점을 주목해야 한다. 따라서, 상기에 제공된 대안적인 실시예들은 서로 배타적이지 않고, 도 16 및 17에 제공된 총칭적인 시나리오들에 동일하거나 동등한 시나리오들을 생성하기 위하여 혼합, 조화 및 결합될 수 있다. 대부분의 프로그래밍 구조를 이용하는 경우와 같이, 여기에 기술될 수 없지만 그럼에도 불구하고 본 발명의 취지 및 범위에 의해 표현되는 인터페이스의 동일하거나 유사한 기능을 달성하는 기타 유사한 방식들이 존재한다는 점 또한 주목해야 하며, 즉, 적어도 부분적으로 인터페이스의 가치의 기초가 되는 인터페이스에 의해 표현된 기능 및 인터페이스의 가치의 기초가 되는 인터페이스에 의해 가능해진 유익한 결과들이란 점을 주목해야 한다.
본 발명을 수행하는 현재의 바람직한 모드들을 포함하는 특정 예들에 관하여 기술하였지만, 본 분야에서 숙련된 기술을 가진 자들은 첨부되는 특허청구범위에서 언급된 본 발명의 취지 및 범위에 속하는 상술된 시스템 및 기술의 다양한 변형 및 순열이 존재한다는 점을 잘 알 것이다.