래스터 연산은 트루 컬러 이미지(픽스맵)나, 단색 이미지(비트맵)을 표현하기 위해서 광범위하게 사용된다. 이 기능은 이미지 프로세싱 기능이나, 폰트 출력 시에 강하게 요구된다. 반면에, OpenGLES 하드웨어 등을 포함하는, 현재의 모바일 그래픽스 플랫폼들에서는 이 기능을 직접 제공하지는 않는다. 모바일 그래픽스 플랫폼들에서 이러한 래스터 연산을 완벽히 제공하기 위해서, 본 논문에서는 그래픽스 이미지들을 3차원 점들의 집합으로 해석하고, 풀-소프트웨어 구현 방식으로, 이들 3차원 점들을 전형적인 3차원 기하 파이프라인으로 처리하게 했다. 구현 결과는 충분한 실행 속도를 보였고, 정확도를 증명하기 위한 공식 검증 테스트(conformance test)들을 모두 통과하였다.
래스터 연산은 트루 컬러 이미지(픽스맵)나, 단색 이미지(비트맵)을 표현하기 위해서 광범위하게 사용된다. 이 기능은 이미지 프로세싱 기능이나, 폰트 출력 시에 강하게 요구된다. 반면에, OpenGL ES 하드웨어 등을 포함하는, 현재의 모바일 그래픽스 플랫폼들에서는 이 기능을 직접 제공하지는 않는다. 모바일 그래픽스 플랫폼들에서 이러한 래스터 연산을 완벽히 제공하기 위해서, 본 논문에서는 그래픽스 이미지들을 3차원 점들의 집합으로 해석하고, 풀-소프트웨어 구현 방식으로, 이들 3차원 점들을 전형적인 3차원 기하 파이프라인으로 처리하게 했다. 구현 결과는 충분한 실행 속도를 보였고, 정확도를 증명하기 위한 공식 검증 테스트(conformance test)들을 모두 통과하였다.
Raster operations are widely used to display full-color graphics images (or pixmaps) and single-color images (or bitmaps). These features are strongly needed for image processing applications and font output. However, current mobile graphics platforms, including OpenGL ES hardware implementations, d...
Raster operations are widely used to display full-color graphics images (or pixmaps) and single-color images (or bitmaps). These features are strongly needed for image processing applications and font output. However, current mobile graphics platforms, including OpenGL ES hardware implementations, do not directly support these features. To fully support those raster operations on the mobile graphics platforms, we interpreted the graphics images as a set of 3D points, and processed those 3D points through the typical 3D geometry pipelines, in a full-software implementation. Our implementation shows sufficient execution speeds, and passed the official conformance tests to show its correctness.
Raster operations are widely used to display full-color graphics images (or pixmaps) and single-color images (or bitmaps). These features are strongly needed for image processing applications and font output. However, current mobile graphics platforms, including OpenGL ES hardware implementations, do not directly support these features. To fully support those raster operations on the mobile graphics platforms, we interpreted the graphics images as a set of 3D points, and processed those 3D points through the typical 3D geometry pipelines, in a full-software implementation. Our implementation shows sufficient execution speeds, and passed the official conformance tests to show its correctness.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
본 논문에서는 래스터 파이프라인이 별도로 제공되지 않는 모바일 그래픽스 표준들에서, 픽스맵과 비트맵의 출력을 비롯한 래스터 파이프라인의 기능들을 제공하는 방법을 제시한다. 기존의 문헌에서는 텍스처 매핑기법으로 처리가 가능하다고 간단히 언급되어 있었지만[10], 저자들이 아는 한, 실제적 구현 방법이나, 상세한 처리 내용들이 출판된 적은 없었다.
이런 문제점들을 피하기 위해, 본 논문에서는 래스터 연산을 구현하는 새로운 방법으로, 점들의 집합을 출력하는 방식을 제안했다. 이 방식에서는 픽스맵이나 비트맵 이미지마다 점들의 집합을 생성한 후, 전통적인 3차원 기하 파이프라인에서 이들 점들을 처리해서 화면에 표시하게 했다.
본 논문에서는 알고리즘의 세부 사항들과 구현 결과를 보였다. 현재까지의 결과로는 OpenGL ES 하드웨어와 같이, 래스터 처리 기능이 전혀 없고, 기하 파이프라인만 제공하는 플랫폼에서도, 소프트웨어 기능의 첨가만으로도 요구되는 래스터 연산들을 모두 제공한다.
제안 방법
이들은 표준의 제정 당시부터 상대적으로 열악한 저수준 하드웨어에서의 사용을 상정하였다. 그 결과로, 이들 표준에서는 불필요하거나, 상대적으로 사용 빈도가 떨어지는 기능들을 제거하여, 생산비를 낮추고, 제한된 자원을 효율적으로 사용하도록 하였다. 이 선택 과정에서, 래스터 파이프라인은 의도적으로 제거되었다[5].
) 함수는 물체 좌표계(object coordinate system)에서 좌표를 설정하지만, 픽스맵의 출력 시에는 윈도우 좌표계(window coordinate system)에서의 2차원 좌표를 필요로 한다. 본 논문의 구현에서는 최종 위치를 계산해 내기 위해서, OpenGL의 좌표 변환 과정을 그대로 에뮬레이션했다. 즉, [그림 2](b)에서와 같이, modelview matrix, projection matrix, perspective division, viewport transformation 등의 연산을 각 단계별로 차례로 적용하여, 최종적인 윈도우 좌표를 구하였다.
본 논문의 구현에서는 최종 위치를 계산해 내기 위해서, OpenGL의 좌표 변환 과정을 그대로 에뮬레이션했다. 즉, [그림 2](b)에서와 같이, modelview matrix, projection matrix, perspective division, viewport transformation 등의 연산을 각 단계별로 차례로 적용하여, 최종적인 윈도우 좌표를 구하였다.
즉, [그림 5]에서와 같이, 주어진 2차원 이미지를 픽셀들의 집합으로 보고, 대응되는 윈도우 좌표 상에, DrawArrays(…)와 같은 3차원 그래픽스 출력요소(3D graphics primitive)를 사용해서, 점집합(point set)을 출력하게 했다.
이것들을 해결하는 방법으로, 본 논문에서는 픽스맵, 비트맵에서 출력이 필요한 픽셀들에 대해서만 각 픽셀에 대응하는 점(point)을 출력하는 방식을 택하였다. 즉, [그림 5]에서와 같이, 주어진 2차원 이미지를 픽셀들의 집합으로 보고, 대응되는 윈도우 좌표 상에, DrawArrays(…)와 같은 3차원 그래픽스 출력요소(3D graphics primitive)를 사용해서, 점집합(point set)을 출력하게 했다.
RasterPos(···) 함수에서는 주어진 물체 좌표(object coordinates)로부터 대응되는 윈도우 좌표(window coordinate)를 계산해야 한다. 본 논문에서는 OpenGL 좌표 변환 파이프라인을 소프트웨어로 그대로 구현해서, 윈도우 좌표를 정확히 계산하도록 했다. 다음 단계로, DrawPixel(···) 함수는 다음 단계들을 수행한다.
본 논문에서는 3절에서 소개한 알고리즘들에 기초해서 래스터 파이프라인 기능을 구현했다. 우리의 구현은 이미 설명한 바와 같이, 점들의 집합을 출력하는 방식으로 구현되었다.
본 논문에서는 3절에서 소개한 알고리즘들에 기초해서 래스터 파이프라인 기능을 구현했다. 우리의 구현은 이미 설명한 바와 같이, 점들의 집합을 출력하는 방식으로 구현되었다. 따라서, 하드웨어 래스터 파이프라인의 지원이 전혀 필요하지 않고, 기하 파이프라인의 기능만을 필요로 한다.
이 방식에서는 픽스맵이나 비트맵 이미지마다 점들의 집합을 생성한 후, 전통적인 3차원 기하 파이프라인에서 이들 점들을 처리해서 화면에 표시하게 했다. 즉, 우리의 방식에서는 픽스맵이나 비트맵 이미지를 색상값을 가지는 3차원 점들의 집합으로 해석해서, 최종적으로는 화면 상에 2차원 이미지를 출력하게 했다.
이론/모형
구현의 정확성을 보이기 위해, 본 논문에서는 크로노스 그룹에서 제공하는 공식 CTS(conformance test suites)[13]의 일부를 사용했다. 본 논문의 구현은 이들 테스트를 모두 통과해서, 표준 문서에서 요구하는 대로, 정확히 구현되었음을 보였다.
성능/효과
본 논문이 제안하는 방법이 가지고 있는 잠재적인 문제점은 전송해야 하는 자료의 양이 늘어날 수 있다는 것이다. 이미지는 보통 픽셀의 색상값들만 전송하면 되지만, 본 논문이 제안하는 방법에서는 점의 3차원 좌표와 색상값들이 모두 필요하고, 그래픽 카드로 전송해야 하는 자료양이 증가한다.
본 논문이 제안하는 방법이 가지고 있는 잠재적인 문제점은 전송해야 하는 자료의 양이 늘어날 수 있다는 것이다. 이미지는 보통 픽셀의 색상값들만 전송하면 되지만, 본 논문이 제안하는 방법에서는 점의 3차원 좌표와 색상값들이 모두 필요하고, 그래픽 카드로 전송해야 하는 자료양이 증가한다. 하지만, 비트맵의 경우는 투명한 픽셀들의 존재로 인해, 실제 늘어나는 자료양은 그렇게 많지 않다.
구현의 정확성을 보이기 위해, 본 논문에서는 크로노스 그룹에서 제공하는 공식 CTS(conformance test suites)[13]의 일부를 사용했다. 본 논문의 구현은 이들 테스트를 모두 통과해서, 표준 문서에서 요구하는 대로, 정확히 구현되었음을 보였다. 수행 속도는 출력하려는 픽스맵, 비트맵의 수나 내용에 따라 차이가 나지만, [그림 6](b)의 예제 프로그램을 Freescale i.
수행 속도는 출력하려는 픽스맵, 비트맵의 수나 내용에 따라 차이가 나지만, [그림 6](b)의 예제 프로그램을 Freescale i.MX6 그래픽스 칩에서 테스트한 결과로는 평규적으로 초당 113.47 프레임을 기록하는 등, 현재까지의 실험 결과로는 문제가 될 정도의 속도 저하는 보이지 않았고, 실시간 응용에서 사용하기에 문제가 없었다.
질의응답
핵심어
질문
논문에서 추출한 답변
래스터 이미지는 정보의 내부 저장 방식에 따라 어떻게 구분되는가?
자주 사용하는 래스터 이미지들은 정보의 내부 저장 방식에 따라, 크게 픽스맵(pixmap)과 비트맵(bitmap)으로 구분한다. 픽스맵은 보통 [그림 1](a)에서와 같이, 픽셀마다 RGBA(red, green, blue, alpha) 또는 RGB(red, green blue) 형태의 트루 컬러(true color) 색상 값을 저장한다.
래스터 이미지는 일반적으로 어떻게 표현되는가?
컴퓨터 그래픽스 분야에서는 [그림 1]에서와 같이, 래스터(raster) 형태로 저장된 이미지(image)를 화면에 그대로 보여주는, 래스터 출력 기능이 반드시 요구된다. 래스터 이미지는 일반적으로 픽셀(pixel) 값들의 2차원사각형 배열로 표현된다. 이러한 이미지들을 화면에 그대로 표현하는 방식은 웹 브라우저(web browser)나 워드 프로세서(word processor)등의 일반적인 프로그램들에서도 제공되는 기능이다.
OpenGL ES 표준에서 래스터 파이프라인이 제거된 이유는?
현재의 모바일 그래픽스용 그래픽스 표준들로는 OpenGL ES 표준들이 주로 사용되고 있다. 이들은 표준의 제정 당시부터 상대적으로 열악한 저수준 하드웨어에서의 사용을 상정하였다. 그 결과로, 이들 표준에서는 불필요하거나, 상대적으로 사용 빈도가 떨어지는 기능들을 제거하여, 생산비를 낮추고, 제한된 자원을 효율적으로 사용하도록 하였다. 이 선택 과정에서, 래스터 파이프라인은 의도적으로 제거되었다[5]. 당시에는 다른 고급 3차원 그래픽스 기술의 발전으로, 래스터 기능들에 대한 요구가 점차 줄어들 것으로 예상하였으나, 비트맵 폰트의 출력이나, 이미지 프로세싱 연산들에서는 지금도 여전히 래스터 연산들이 요구되고 있다.
참고문헌 (13)
E. Angle, Interactive Computer Graphics, A top-down approach with OpenGL, 6th Ed., 2012.
최홍준, 김철홍, "범용 응용프로그램 실행 시 하드웨어 구성과 분기 처리 기법에 따른 GPU 성능 분석", 한국콘텐츠학회논문지, 제13권, 제3호, pp.9-21, 2013.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.