이미지 파일의 메모리 요구 사항 이해


9

240x400 해상도 디스플레이에 표시되는 이미지 리소스 파일의 메모리 요구 사항을 이해하고 싶습니다.

디스플레이에는 다음 사양이 있습니다.

명세서

최대 18 비트 색 심도를 지원하며 ILI9327 디스플레이 드라이버를 사용합니다.

크기가 각각 10mm X 10mm 인 50 개의 서로 다른 아이콘을 표시해야한다고 가정하면 필요한 저장 공간은 무엇입니까?

내 계산은 다음과 같습니다.

mm 당 픽셀 = 400 / 61.2 = 6.536

한 이미지의 픽셀 수 = 65.36 x 65.36 = 4272 픽셀

각 픽셀에는 18 비트 X 3 (R, G 및 B의 경우) = 54 비트가 필요합니다.

필요한 총 비트 = 4272 x 54 = 230688 비트 = 28.16 킬로바이트

50 개 이미지의 경우 1.375MB의 스토리지가 필요합니다.

내 계산이 정확합니까?


2
상위 스토리지 요구 사항을 계산하고 있습니다. 일반적으로 이미지는 압축되며 압축되지 않은 파일에서 여분의 바이트를 읽는 것보다 SD 카드 등으로 즉석에서 읽고 압축하는 것이 더 빠릅니다. 장치 I / O에 병목 현상이 발생하기 때문입니다.
Kingsley

답변:


17

mm 당 픽셀 = 400 / 61.2 = 6.536

예.

한 이미지의 픽셀 수 = 65.36 x 65.36 = 4272 픽셀

글쎄, 당신은 아이콘 당 픽셀을 의미합니다. 그러나 그럼에도 불구하고 분수 픽셀을 생성 할 수 없으므로 숫자는 65 x 65 또는 66 x 66이어야합니다. 그러면 더 단순화됩니다. 아이콘을 64 x 64로 만드십시오. 이렇게하면 메모리에 대한 주소 계산이 간단 해지고 약 2 %의 "수축률"만 생성됩니다. 그리고이 크기로 아무도 눈치 채지 못할 것입니다. 그러면 아이콘 크기는 4096 픽셀입니다.

각 픽셀에는 18 비트 X 3 (R, G 및 B의 경우) = 54 비트가 필요합니다.

아니. jms가 방금 대답했듯이 픽셀 당 총 18 비트 또는 색상 당 6 비트입니다. 그러나 비트 수준에 대해서는 크게 걱정하지 않아야합니다. 색상 값을 색상 당 별도의 바이트와 함께 부분 바이트 (바이트 당 6 비트)로 저장하십시오. 이것은 33 % 더 많은 메모리를 필요로하지만 메모리에서 화면으로 전송할 때 처리로드를 크게 줄입니다.

필요한 총 비트 = 4272 x 54 = 230688 비트 = 28.16 킬로바이트

총 비트는 4096 x 24 또는 98304 비트 또는 12288 바이트입니다.

50 개 이미지의 경우 1.375MB의 스토리지가 필요합니다.

12288 x 50은 614400 바이트를 제공합니다.


1
그러나 영구 저장소에 대해 이야기하고 있다면 아이콘을 PNG 또는 JPEG로 압축하여 저장 하시겠습니까? 또는 우리가 framebuffer를 말하고 있다면 그것은 단순히 (display_width * display_height * bpp) / 8바이트입니까?
aroth

@aroth-이것은 트레이드 오프의 영역으로 직결됩니다. 더 중요한 메모리 크기 또는 처리 요구 사항은 무엇입니까? 압축되지 않은 이미지를 사용하면 큰 파일 비용으로 스크린에 실질적으로 고통없이 전송할 수 있습니다. 더 큰 단어에서 색상 데이터의 압축을 풀지 않아도 훨씬 쉽습니다. 압축 된 이미지의 압축을 풀거나 색상 표를 적용하면 데이터 파일 크기가 훨씬 작아 지지만 초보자에게는 처리 노력이 어려울 수 있습니다. 그것은 우선 순위와 취향의 문제입니다.
WhatRoughBeast

11

아이콘을 64 × 64 픽셀로 만들어서 생활을 단순하게 만드십시오. 더 크게 보이려면 주변에 테두리를 그립니다.

16 비트 색상 형식의 경우 아이콘 당 8kB 또는 50 세트의 경우 400kB 만 필요합니다.

간단한 압축 형식 중 하나는 모든 픽셀의 색상을 직접 저장하는 대신 색상 표를 사용하는 것입니다. 특히 창의적인 디더링을 약간 적용 할 경우 16 색이 아이콘에 충분할 때가 많습니다. 이렇게하면 스토리지가 아이콘 당 2kB와 색상 표의 32 바이트로 줄어 듭니다. 모든 아이콘에 고유 한 색상 표가있는 경우 총 저장 용량은 101kB를 약간 넘습니다.


내 호기심을 만족시키기 위해 다음과 같은 "최악의 사례"이미지를 가져 왔습니다 ( 여기에서 ).

색상의 힘

이 ImageMagick 명령 줄

convert image.jpg -crop 267x267+66+0 -resize 64x64 -colors 16 final.png

이것을 이것으로 바꿨습니다 :

여기에 이미지 설명을 입력하십시오

나쁘지 않으며 물론 더 제한된 범위의 색상을 가진 소스 이미지가 훨씬 나아질 것입니다. 예를 들어, Olin은 다음과 같은 방식으로 처리됩니다.

여기에 이미지 설명을 입력하십시오 여기에 이미지 설명을 입력하십시오


2
키워드 : 색인 색상 . 예를 들어 비트 맵당 16 개의 색상이 충분하지 않은 경우 아이콘을 각각 다른 팔레트가있는 여러 개의 작은 비트 맵으로 나눌 수 있습니다. 디더링을 적용 해도 도움이 될 수 있습니다.
jms 2016 년

9

색상 심도에 대한 추가 정보

Dave Tweed의 답변을 확장하면 자신이 보여준 것보다 더 잘 할 수 있습니다.

그가 사용한 것과 같은 대형 원본은 다음과 같습니다.

정사각형으로 자르고 64 x 64 픽셀로 축소되었지만 전체 (빨간색, grn, 블루 당 8 비트) 색상을 사용하는 경우 :

채널당 8 비트에서 6 비트로 색상 정보를 반올림하면 다음이 발생합니다.

그것이 18 비트 색 심도를 지원한다고 말했기 때문에 디스플레이가 할 수있는 일입니다.

총 16 비트 / 픽셀 수로 색상 정보를 빨간색의 경우 5 비트, 녹색의 경우 6, 녹색의 경우 5로 반올림합니다.

이것은 아이콘에 충분할 정도로 충분해야합니다.

압축이 없어도이 형식의 아이콘은 64 x 64 x 2 = 8192 바이트 만 사용합니다. 이러한 이미지 50 개에는 409,600 바이트가 필요합니다.


2
내 이미지는 픽셀 당 4 비트 (16 색)-아이콘 당 2k 바이트 및 32 바이트 조회 테이블로 압축됩니다. 제한된 색상 세트로 디더링이 어떻게 보이는지 보여주고 싶었습니다.
Dave Tweed

서로 다른 색 심도를 비교하고 있으므로 8 비트 컬러 맵을 사용하여 색 심도를 추가해야합니까? 이것은 우리가 이미 가지고있는 4 비트와 16 비트 변형 사이의 절반 (논리적으로)입니다.
ilkkachu 2018 년

@ 데이브 : 그것은 당신의 대답에서 명확하지 않지만 디더링 유물을 설명합니다.
Olin Lathrop 2018 년

8

각 픽셀에는 18 비트 X 3 (R, G 및 B의 경우) = 54 비트가 필요합니다.

견적이 잘못되었습니다. "18 비트"값은 색상이 아니라 픽셀 당입니다. 빨강, 녹색 및 파랑 채널은 각각 최대 비트 심도가 6 비트 (64 개의 다른 값)이며 총 18 비트입니다.
이 디스플레이 컨트롤러는 16 비트 모드 (픽셀 데이터에는 빨강의 경우 5 비트, 초록의 경우 6, 파랑의 경우 5 만 있음)를 지원하므로 각 픽셀을 2 바이트로 쉽게 묶을 수 있습니다. 따라서 비트 맵을 효율적으로 저장하기 쉽고 디스플레이에 초당 쓸 수있는 픽셀 수가 증가합니다.

여기에 이미지 설명을 입력하십시오

한 이미지의 픽셀 수 = 65.36 x 65.36 = 4272 픽셀

실제로 소수 픽셀을 저장할 수 없으므로 실제 비트 맵 (이미지 / 스프라이트 / 캐릭터 / 무엇이든)은 아마도 65 2 = 4225 픽셀 일 것입니다.

쉬운 경로 (16 비트 R5G6B5 픽셀 형식)로 이동하면 4225 * 16 비트는 비트 맵당 67600 비트 또는 비트 맵당 8450 바이트에 해당합니다. 50 개의 이미지에는 423kB가 필요합니다 (압축 없음).

전체 색상 심도를 원한다면 픽셀 당 2 바이트 이상이 필요합니다. 이 단계에서 각 색상에 대해 1 바이트를 할당 할 수 있으며 (WhatRoughBeast가 제안한 바와 같이) 스토리지 요구 사항을 3/2 (50 65x65 비트 맵의 ​​경우 634kB)로 추가로 증가시킬 수 있습니다.

또한 비트를 낭비하지 않고 18 비트 픽셀을 메모리 (바이트 경계와 정렬되지 않은 서브 픽셀 비트)에서 서로 바로 옆에 패킹 할 수 있습니다. 50 개의 65x65 18 비트 비트 맵에는 476kB 만 있으면되지만 프로그래밍이 어려워 처리 속도가 느려집니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.