ทำความเข้าใจกับข้อกำหนดหน่วยความจำสำหรับไฟล์รูปภาพ


9

ฉันต้องการเข้าใจข้อกำหนดหน่วยความจำสำหรับไฟล์ทรัพยากรรูปภาพที่จะแสดงบนจอแสดงผลความละเอียด 240x400

จอแสดงผลมีข้อกำหนดดังต่อไปนี้:

รายละเอียด

รองรับความลึกของสีสูงสุด 18 บิตและใช้ไดรเวอร์การแสดงผล ILI9327

สมมติว่าฉันต้องการแสดงไอคอนที่แตกต่าง 50 รายการแต่ละขนาด 10 มม. X 10 มม. จำเป็นต้องใช้พื้นที่เก็บข้อมูลอะไร

นี่คือการคำนวณของฉัน:

พิกเซลต่อมม. = 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.375 เมกะไบต์

การคำนวณของฉันถูกต้องหรือไม่


2
คุณกำลังคำนวณความต้องการพื้นที่เก็บข้อมูลระดับบน โดยทั่วไปแล้วรูปภาพจะถูกบีบอัดและบ่อยครั้งที่การอ่านและคลายการบีบอัดทำได้รวดเร็วกว่า (จากการพูดใน SD การ์ด) มากกว่าการอ่านไบต์พิเศษจากไฟล์ที่ไม่บีบอัด ปัญหานี้มักเกิดขึ้นเนื่องจากอุปกรณ์ I / O เป็นคอขวด
Kingsley

คำตอบ:


17

พิกเซลต่อมม. = 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 บิต

Nope ดังที่ jms เพิ่งตอบไปมันคือ 18 บิตต่อพิกเซลรวมหรือ 6 บิตต่อสี อีกครั้งแม้ว่าคุณควรพิจารณาไม่ต้องกังวลมากเกี่ยวกับระดับบิต เก็บค่าสีของคุณเป็นไบต์บางส่วน (6 บิตต่อไบต์) โดยแยกไบต์ต่อสี ซึ่งจะใช้หน่วยความจำเพิ่มขึ้น 33% แต่จะลดภาระการประมวลผลของคุณลงอย่างมากเมื่อถ่ายโอนจากหน่วยความจำไปยังหน้าจอ

บิตทั้งหมดที่ต้องการ = 4272 x 54 = 230688 บิต = 28.16 กิโลไบต์

บิตทั้งหมดคือ 4096 x 24 หรือ 98304 บิตหรือ 12288 ไบต์

สำหรับ 50 ภาพฉันจะต้องใช้พื้นที่จัดเก็บ 1.375 เมกะไบต์

12288 คูณ 50 ให้ 614400 ไบต์


1
แต่แน่นอนถ้าเรากำลังพูดถึงการจัดเก็บแบบถาวรแล้วคุณจะต้องเก็บไอคอนของคุณบีบอัดเป็น PNG หรือ JPEG ของ? หรือถ้าเรากำลังพูดถึง framebuffer มันเป็นเพียง(display_width * display_height * bpp) / 8ไบต์?
aroth

@aroth - สิ่งนี้ทำให้คุณได้เข้าสู่ขอบเขตของการแลกเปลี่ยนอย่างเต็มที่ ขนาดหน่วยความจำหรือความต้องการในการประมวลผลสำคัญกว่าอะไร การใช้ภาพที่ไม่มีการบีบอัดช่วยให้สามารถถ่ายโอนไฟล์ไปยังหน้าจอได้อย่างไม่เจ็บปวดโดยใช้ไฟล์ขนาดใหญ่ ง่ายยิ่งขึ้นโดยไม่จำเป็นต้องแกะข้อมูลสีจากคำที่ใหญ่ขึ้น การคลายการบีบอัดอิมเมจและ / หรือการใช้ตารางสีจะช่วยให้ไฟล์ข้อมูลมีขนาดเล็กลงมาก มันเป็นเรื่องของลำดับความสำคัญและรสชาติ
WhatRoughBeast

11

ทำให้ชีวิตของคุณง่ายขึ้นด้วยการทำไอคอน 64 × 64 พิกเซล วาดเส้นขอบรอบ ๆ หากคุณต้องการให้ดูใหญ่ขึ้น

ด้วยรูปแบบสี 16 บิตต้องใช้เพียง 8 kB ต่อไอคอนหรือ 400 kB สำหรับชุด 50

รูปแบบการบีบอัดอย่างง่ายอย่างหนึ่งคือการใช้ตารางสีแทนการเก็บสีทุกพิกเซลโดยตรง 16 สีมีมากเกินพอสำหรับไอคอนโดยเฉพาะอย่างยิ่งถ้าคุณใช้ความคิดสร้างสรรค์เล็กน้อย สิ่งนี้จะลดพื้นที่จัดเก็บลงเหลือ 2 kB ต่อไอคอนบวกกับ 32 ไบต์สำหรับตารางสี พื้นที่เก็บข้อมูลรวมน้อยกว่า 101 kB หากทุกไอคอนมีตารางสีของตัวเอง


เพียงเพื่อสนองความอยากรู้อยากเห็นของฉันเองฉันคว้าภาพ "กรณีที่เลวร้ายที่สุด" ต่อไปนี้ (จากที่นี่ ):

พลังแห่งสีสัน

บรรทัดคำสั่ง ImageMagick นี้

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

เปลี่ยนเป็น:

ป้อนคำอธิบายรูปภาพที่นี่

ไม่เลวและแน่นอนว่าแหล่งรูปภาพที่มีช่วงสีที่ จำกัด กว่าจะออกมาดียิ่งขึ้น ตัวอย่างเช่นที่นี่แลงประมวลผลในลักษณะเดียวกัน:

ป้อนคำอธิบายรูปภาพที่นี่ ป้อนคำอธิบายรูปภาพที่นี่


2
คำสำคัญ: ดัชนีสี ถ้าเช่น 16 สีต่อบิตแมปไม่เพียงพอคุณสามารถแบ่งไอคอนให้เป็นบิตแมปขนาดเล็กหลาย ๆ อันแต่ละอันมีจานสีต่างกัน การใช้ditherอาจช่วยได้เช่นกัน
jms

9

เพิ่มเติมเกี่ยวกับความลึกของสี

ขยายคำตอบของ Dave Tweed คุณสามารถทำได้ดีกว่าสิ่งที่เขาแสดงให้เห็น

นี่คือต้นฉบับขนาดใหญ่เดียวกันกับที่เขาใช้:

ตัดให้เป็นสี่เหลี่ยมจัตุรัสและหดเป็น 64 x 64 พิกเซล แต่ใช้สีแบบเต็ม (8 บิตต่อแดง, grn, blu):

การปัดเศษข้อมูลสีจาก 8 บิตต่อช่องสัญญาณเป็น 6 บิตจะทำให้:

นั่นคือสิ่งที่จอแสดงผลของคุณสามารถทำได้เนื่องจากคุณบอกว่ามันรองรับความลึกของสี 18 บิต

การปัดเศษข้อมูลสีให้มากขึ้นถึง 5 บิตสำหรับสีแดง, 6 สำหรับสีเขียวและ 5 สำหรับสีน้ำเงินรวมทั้งหมด 16 บิต / พิกเซลผลผลิต:

นี่ควรจะดีพอสำหรับไอคอน

แม้ว่าจะไม่มีการบีบอัดไอคอนรูปแบบนี้ใช้เวลาเพียง 64 x 64 x 2 = 8192 ไบต์ 50 ภาพดังกล่าวจะต้องมี 409,600 ไบต์


2
ภาพของฉันถูกบีบอัดลง 4 บิตต่อพิกเซล (16 สี) - 2k ไบต์ต่อไอคอนรวมถึงตารางการค้นหาขนาด 32 ไบต์ ฉันต้องการแสดงให้เห็นว่าการทำสีที่มีสี จำกัด มีลักษณะอย่างไร
Dave Tweed

เนื่องจากเรากำลังเปรียบเทียบความลึกของสีที่แตกต่างกันคุณควรเพิ่มความเข้มของสีด้วยบิตแมป 8 บิตหรือไม่ นั่นจะครึ่งทาง (ลอการิทึม) ระหว่างตัวแปร 4 บิตและ 16 บิตที่เรามีอยู่ที่นี่
ilkkachu

@Dave: นั่นยังไม่ชัดเจนจากคำตอบของคุณ แต่มันอธิบายสิ่งประดิษฐ์ที่ทำให้โกรธ
Olin Lathrop

8

แต่ละพิกเซลจะต้องมี 18 บิต X 3 (สำหรับ R, G และ B) = 54 บิต

ค่าประมาณของคุณไม่ถูกต้อง ค่า "18 บิต" คือต่อพิกเซลไม่ใช่ต่อสี ช่องสีแดงเขียวและน้ำเงินแต่ละช่องมีความลึกบิตสูงสุด 6 บิต (64 ค่าแตกต่างกัน) รวม 18 บิต
คอนโทรลเลอร์การแสดงผลนี้ยังรองรับโหมด 16 บิต (ซึ่งข้อมูลพิกเซลมีเพียง 5 บิตสำหรับสีแดง, 6 สำหรับสีเขียวและ 5 สำหรับสีน้ำเงิน) ซึ่งทำให้ง่ายต่อการบรรจุแต่ละพิกเซลเป็นสองไบต์ สิ่งนี้ทำให้การจัดเก็บบิตแมปง่ายขึ้นและเพิ่มจำนวนพิกเซลที่คุณสามารถเขียนไปยังจอแสดงผลต่อวินาทีได้ง่ายขึ้น

ป้อนคำอธิบายรูปภาพที่นี่

จำนวนพิกเซลในหนึ่งภาพ = 65.36 x 65.36 = 4272 พิกเซล

คุณไม่สามารถเก็บพิกเซลที่เป็นเศษส่วนได้จริงดังนั้นบิตแมปที่แท้จริงของคุณ (รูปภาพ / สไปรท์ / ตัวอักษร / อะไรก็ตาม) อาจเป็น 65 2 = 4225 พิกเซล

การไปตามเส้นทางที่ง่าย (รูปแบบพิกเซล R5G6B5 16 บิต), 4225 * 16 บิตจะเท่ากับ 67600 บิตต่อบิตแมปหรือ 8450 ไบต์ต่อบิตแมป 50 ภาพจะต้องใช้ 423 kB (โดยไม่มีการบีบอัด)

หากคุณต้องการความลึกของสีอย่างแท้จริงคุณต้องมีมากกว่า 2 ไบต์ต่อพิกเซล ในขั้นตอนนั้นคุณอาจอุทิศหนึ่งไบต์สำหรับแต่ละสี (ตามที่ WhatRoughBeast แนะนำ) ซึ่งจะทำให้ความต้องการที่เก็บข้อมูลเพิ่มขึ้นอีก 3 เท่า (634 kB สำหรับ 50 65x65 บิตแมป)

คุณสามารถแพ็คพิกเซล 18 บิตได้ทันทีถัดจากกันในหน่วยความจำ (บิตพิกเซลย่อยที่ไม่มีการจัดแนวกับขอบเขตไบต์) โดยไม่สูญเสียบิตใด ๆ คุณต้องการเพียง 476 kB สำหรับบิตแมป 50 65x65 18 บิต แต่มันเป็นความเจ็บปวดในการเขียนโปรแกรมและประมวลผลช้ากว่า

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.