Định dạng hình ảnh nào hiệu quả hơn về bộ nhớ: PNG, JPEG hoặc GIF?

Định dạng hình ảnh nào hiệu quả hơn để tiết kiệm bộ nhớ? PNG, JPEG hay GIF?

"Bộ nhớ" và "hiệu quả" là những thuật ngữ thường bị sử dụng sai, vì vậy tôi sẽ đưa ra câu trả lời cho bốn yếu tố khác nhau có thể ảnh hưởng đến hiệu suất trò chơi của bạn.

Tôi sẽ quá đơn giản hóa quá nhiều thứ để giữ cho nó ngắn gọn và súc tích, nhưng có rất nhiều điểm không chính xác trong văn bản dưới đây, vì vậy hãy dùng nó với một chút muối. Tuy nhiên, các khái niệm chính nên dễ hiểu.

Lưu trữ

Đây là kích thước hình ảnh của bạn tiêu thụ trên bản phân phối phần mềm của bạn. Tài nguyên của bạn càng tiêu tốn nhiều dung lượng, thời gian tải xuống (như từ trang web của bạn) sẽ càng dài. Nếu bạn đang phân phối trên phương tiện vật lý, chẳng hạn như CD hoặc DVD, có lẽ bạn sẽ phải thực hiện một số tối ưu hóa nghiêm trọng ở mặt trước này.

Nói chung, JPEG nén tốt nhất cho ảnh và ảnh không có viền sắc nét. Tuy nhiên, hình ảnh của bạn sẽ bị giảm chất lượng vì JPEG sử dụng nén mất dữ liệu (bạn có thể tinh chỉnh mức độ nén / xuống cấp khi xuất hình ảnh dưới dạng JPEG. Tham khảo tài liệu của phần mềm hình ảnh của bạn để biết thêm thông tin về điều này).

Tuy nhiên, tốt như JPEG, nó không hỗ trợ độ trong suốt . Điều này rất quan trọng nếu bạn muốn có hình ảnh hiển thị thông qua người khác hoặc nếu bạn muốn hình ảnh có hình dạng không đều. GIF là một lựa chọn tốt, nhưng phần lớn được thay thế bởi PNG (chỉ có một vài điều GIF hỗ trợ mà PNG không có, nhưng chúng hầu như không liên quan đến lập trình trò chơi).

PNG hỗ trợ độ trong suốt (và bán trong suốt), nén dữ liệu mà không suy giảm chất lượng (nghĩa là nó sử dụng nén không mất dữ liệu) và nén khá tốt, nhưng không nhiều như JPG.

Vấn đề phát sinh khi bạn cần nén tốt, cũng như minh bạch. Nếu bạn không bận tâm đến những hình ảnh hơi xuống cấp, bạn có thể sử dụng các chương trình lượng tử hóa PNG như pngquant , bạn có thể kiểm tra trực tuyến tại TinyPNG . Hãy nhớ rằng sự xuống cấp hình ảnh được thực hiện bằng cách lượng tử hóa khác với JPEG (bao gồm lượng tử hóa cũng như các kỹ thuật tích cực khác), vì vậy hãy chắc chắn thử cả hai, với nhiều cài đặt khác nhau.

Nếu bạn muốn giảm thiểu kích thước phân phối của mình, bạn có thể xử lý thủ công mọi hình ảnh như thế này:

if the image has transparency then
    try pngquant on the image
    if the results are not satisfactory then
        revert to the non-quantized image
    end
    store as PNG
else
    try storing it as JPG with different quality settings
    if no single setting yields an image of an acceptable quality then
        try pngquant on the image
        if the results are not satisfactory then
            revert to the non-quantized image
        end
        store as PNG
    else
        store as JPG
    end
end

Mẹo: bạn có thể lưu trữ một số hình ảnh ở một định dạng và những hình ảnh khác ở định dạng khác.

Có các định dạng chuyên biệt khác như DXT, ETC và PVRTC. Chúng hỗ trợ nén và cũng có thể được nén vào bộ nhớ, nhưng chúng chỉ được hỗ trợ bởi các GPU cụ thể và hầu hết các GPU này chỉ hỗ trợ một trong số chúng, vì vậy trừ khi bạn biết thông số kỹ thuật phần cứng chính xác của phần cứng mục tiêu của bạn (một trường hợp đáng chú ý là iPhone / iPad, hỗ trợ kết cấu PVRTC), bạn nên tránh các định dạng này.

Bộ nhớ chương trình

Tôi đã đưa nó vào đây, bởi vì đây là thứ thường được biết đến bởi "bộ nhớ". Tuy nhiên, nếu trò chơi của bạn sử dụng tăng tốc đồ họa (và nếu bạn tạo trò chơi sau năm 1998, rất có thể là bạn), thì điều duy nhất sẽ tiêu tốn bộ nhớ là mô tả kết cấu của bạn (chỉ một vài byte cho mỗi hình ảnh), chỉ có ảnh hưởng bởi số lượng hình ảnh, và không phải kích thước hoặc định dạng của chúng (điều này có một vài cảnh báo, nhưng chủ yếu là không liên quan).

Nếu nền tảng của bạn không có bộ nhớ video chuyên dụng, không được tăng tốc phần cứng hoặc các trường hợp không phổ biến khác, thì phần tiếp theo về VRAM sẽ xảy ra hoàn toàn hoặc một phần trong RAM, nhưng các nguyên tắc chính sẽ giống nhau.

Bộ nhớ video

Đây là nơi hình ảnh của bạn sẽ được lưu trữ khi chương trình của bạn đang chạy. Nói chung, định dạng mà bạn lưu trữ chúng sẽ không có sự khác biệt ở đây, vì tất cả các hình ảnh đều được giải nén trước khi tải chúng vào bộ nhớ video.

Bây giờ, VRAM được tiêu thụ bởi hình ảnh của bạn sẽ đại khái width * height * bitdepth cho từng hình ảnh được tải trong VRAM. Có một vài điều cần chú ý ở đây:

1. Chiều rộng và chiều cao mà hình ảnh của bạn được lưu trữ trong VRAM sẽ không nhất thiết phải khớp với hình ảnh gốc của bạn. Một số GPU chỉ có thể xử lý kết cấu với kích thước ở mức 2, vì vậy hình ảnh 320x240 của bạn thực sự có thể được lưu trữ trong không gian 512x256 trong VRAM, với bộ nhớ không sử dụng bị lãng phí một cách hiệu quả. Đôi khi, bạn thậm chí không được phép tải họa tiết với kích thước không phải là 2 (như trong GLES 1.1).

   Vì vậy, nếu bạn muốn giảm thiểu việc sử dụng VRAM, bạn có thể muốn xem xét việc tạo hình ảnh của mình và định cỡ chúng với quyền hạn bằng 2, điều này cũng sẽ có lợi thế là ít thay đổi trạng thái kết xuất khi kết xuất. Thêm về điều này sau.

2. Các bitdepth là rất quan trọng. Thông thường họa tiết được tải vào VRAM trong ARGB 32 bit hoặc XRGB 32 bit, nhưng nếu phần cứng của bạn có thể hỗ trợ độ sâu 16 bit và bạn không ngại có bitdepth thấp hơn, bạn có thể giảm một nửa lượng VRAM được tiêu thụ cho mỗi hình ảnh , có thể là một cái gì đó thú vị để xem xét.

3. Nhưng bất kể bạn làm gì, yếu tố quan trọng nhất khi xem xét lượng VRAM mà trò chơi của bạn sử dụng, là lượng hình ảnh bạn có trong VRAM tại một thời điểm nhất định. Đây là con số mà bạn rất muốn giữ ở mức thấp nhất có thể nếu bạn muốn một trò chơi hoạt động tốt. Tải và dỡ họa tiết vào VRAM rất tốn kém, vì vậy bạn không thể tải từng hình ảnh bất cứ khi nào bạn sẽ sử dụng nó. Bạn phải tìm sự cân bằng giữa việc tải trước các hình ảnh mà bạn sẽ sử dụng nhiều nhất và hủy tải chúng khi bạn chắc chắn rằng bạn sẽ không sử dụng chúng nữa. Làm điều này đúng là không tầm thường, và bạn phải nghĩ ra chiến lược của riêng mình cho trò chơi cụ thể của bạn.

Tốc độ thực hiện

Mặc dù không phải là "bộ nhớ", nhưng nó rất liên quan đến hiệu suất trong các trò chơi. Vẽ hình ảnh rất tốn kém và bạn muốn đảm bảo kết xuất của bạn chạy nhanh nhất có thể. Tất nhiên, ở đây, định dạng không thành vấn đề, nhưng những thứ khác thì có:

1. Kích thước hình ảnh (thực tế, nó sẽ là "kích thước lấy mẫu"): khu vực lớn nhất của hình ảnh bạn sẽ vẽ, sẽ mất nhiều thời gian hơn để vẽ nó. Kết xuất một hình ảnh khổng lồ trong một phần nhỏ của màn hình không hiệu quả lắm, do đó, có một kỹ thuật gọi là mipmapping , bao gồm giao dịch VRAM cho tốc độ kết xuất, bằng cách lưu trữ hình ảnh của bạn nhiều lần ở độ phân giải và sử dụng hình ảnh nhỏ nhất có thể cung cấp bạn chất lượng cần thiết tại bất kỳ thời điểm nào. Mipmapping có thể được thực hiện khi hình ảnh được tải, điều này sẽ ảnh hưởng đến tốc độ tải và sử dụng VRAM hoặc khi tiền xử lý (bằng cách lưu trữ thủ công các phiên bản khác nhau của cùng một hình ảnh hoặc sử dụng định dạng hỗ trợ mipmapping như DDS), sẽ ảnh hưởng đến việc lưu trữ và sử dụng VRAM, nhưng sẽ có ít ảnh hưởng đến tốc độ tải.

2. Kết xuất thay đổi trạng thái. Bạn rất có thể muốn vẽ một số hình ảnh khác nhau trên màn hình cùng một lúc. Tuy nhiên, GPU chỉ có thể sử dụng một hình ảnh nguồn duy nhất tại bất kỳ thời điểm nào (điều này không đúng, nhưng vui lòng đồng ý với tôi ở đây). Hình ảnh hiện đang được sử dụng để kết xuất là một trong nhiều trạng thái kết xuất và nó rất tốn kém. Vì vậy, nếu bạn sẽ sử dụng cùng một hình ảnh nhiều lần (bạn có nhớ khi tôi đề cập đến các kết cấu không?), Bạn sẽ thấy hiệu suất tăng rất lớn nếu bạn sử dụng lại một hình ảnh nhiều nhất có thể trước khi bạn thay đổi trạng thái kết xuất và bắt đầu sử dụng hình ảnh khác nhau (có các trạng thái kết xuất khác ngoài điều này và tinh chỉnh thứ tự bạn vẽ nội dung của mình để giảm thiểu thay đổi trạng thái kết xuất là một hoạt động rất phổ biến khi nâng cao hiệu suất của trò chơi)

Tuy nhiên , tối ưu hóa sử dụng hình ảnh là một chủ đề rất phức tạp và những gì tôi viết ở đây là một tổng quan rất rộng và đơn giản về một số yếu tố bạn sẽ phải xem xét khi viết một trò chơi, vì vậy tôi nghĩ chắc chắn là tốt nhất nếu bạn giữ nó đơn giản, và chỉ tối ưu hóa bất cứ khi nào bạn thực sự cần làm như vậy. Hầu hết thời gian, tối ưu hóa sớm là không cần thiết (và đôi khi thậm chí gây bất lợi), vì vậy hãy thực hiện nó dễ dàng.

Khi một hình ảnh được tải ra khỏi đĩa và được định dạng để kết xuất, nó sẽ sử dụng cùng một lượng bộ nhớ bất kể hình ảnh đó đã được lưu vào đĩa bằng PNG, JPEG hay GIF.

Nguyên tắc chung: JPEG là định dạng mất dữ liệu và sẽ làm giảm chất lượng hình ảnh để làm cho hình ảnh nhỏ hơn trên đĩa. Mặt khác, PNG là định dạng hình ảnh không mất dữ liệu và do đó thường sẽ dẫn đến kích thước tệp lớn hơn trên đĩa. GIF về mặt kỹ thuật cũng là định dạng lossless, nhưng chỉ hỗ trợ tối đa 256 màu cho mỗi hình ảnh và do đó, hình ảnh màu cao thường sẽ bị mất chất lượng nặng nếu được lưu dưới dạng GIF.

Điều đó chỉ dành cho đại diện trên đĩa của họ, mặc dù. Trong bộ nhớ, cả hai sẽ mở rộng thành cùng một định dạng kết cấu, sử dụng cùng một lượng bộ nhớ, bất kể bạn đã lưu chúng vào đĩa dưới dạng PNG, hay JPEG, hoặc dưới dạng GIF.

Nó phụ thuộc.

Jpeg là hiệu quả nhất cho hình ảnh. Nó không phải là lossless, nhưng các tạo phẩm được giới thiệu bởi nén ít thấy nhất trong trường hợp sử dụng này.

PNG là lossless và hiệu quả nhất cho nghệ thuật pixel với các đường nét và ít màu sắc. Nó cũng hỗ trợ tính minh bạch alpha.

GIF không thể làm bất cứ điều gì PNG không thể làm tốt hơn, ngoại trừ khả năng lưu trữ hình ảnh động. Nhưng điều này chỉ có liên quan trong bối cảnh của các ứng dụng web. Trong phát triển trò chơi, bạn thường tạo ra hình ảnh động bằng cách sử dụng một spritesheet.

Lưu ý rằng khi bạn sử dụng một công cụ đồ họa như Libgdx, rất có thể nó sẽ giải nén các hình ảnh ngay sau khi tải chúng và sau đó giữ chúng trong bộ nhớ dưới dạng các giá trị RGBA không nén. Vì vậy, định dạng hình ảnh chỉ quan trọng đối với tốc độ tải và có dung lượng ổ đĩa (hoặc sử dụng băng thông khi bạn gửi chúng qua mạng).

Tôi không biết nhiều về libgdx, nhưng về định dạng hình ảnh và đồ họa:

JPEG là rất tốt trong trường hợp ảnh thế giới thực. Chúng bị mất nhưng bạn sẽ không nhìn thấy đồ tạo tác trên ảnh trừ khi bạn chụp ảnh các cạnh sắc nét với không gian màu đơn giản, ví dụ như văn bản viết hoặc truyện tranh. Sử dụng chúng cho đồ họa nền lớn.

GIF đã lỗi thời, nó chỉ có thể lưu trữ các màu nhạt (tối đa 8 bit mỗi pixel) với một màu chuyên dụng để hoàn toàn trong suốt. Nó cho phép hình ảnh động nhỏ dựa trên khung. Một khi đã có bằng sáng chế về thuật toán đóng gói của nó để nó không thể được sử dụng ở mọi nơi một cách hợp pháp. Vì bằng sáng chế đó, PNG đã được phát triển.

PNG ít nhiều là một bitmap nén có thể lưu trữ RGB + alpha (tối đa 32 bit) và các định dạng pixel khác. Nó chuyên dùng để giải nén tốc độ các phần nhỏ của bức tranh, thuận tiện cho các thiết bị rất nhỏ và chậm (như điện thoại di động 10 năm tuổi), nhưng các thư viện ngày nay chỉ giải nén chúng thành bitmap khi tải.

PNG tốt hơn GIF về kích thước và tốc độ và tính năng, nhưng nếu bạn muốn lưu trữ ảnh bitmap hiệu quả, tôi khuyên bạn nên: .PNM.BZ2 ([sửa] Vì phương pháp đóng gói khác nhau, .PNM.BZ2 không phải lúc nào cũng hiệu quả hơn hơn .PNG. [/ chỉnh sửa])

PNM / PBM / PGM / PAM là các định dạng bitmap đơn giản với các tiêu đề KISS trong văn bản thuần túy. Sử dụng gzip trên những cái đó sẽ dẫn đến kích thước tệp tương tự như PNG, vì vậy bzip2 là giải pháp tốt hơn cho điều đó. Nếu bạn định sử dụng bitmap trong nội bộ chương trình của mình, bạn có thể muốn sử dụng bitmap nén bzip2 trong một thùng chứa .tar hoặc .zip. Nếu bạn không có bzip2, sử dụng PNM trong thùng chứa zip (zip có nén tối đa) có thể tương tự như sử dụng PNG. - Vì vậy, lưu trữ PNG trong tệp ZIP có thể chỉ có lợi ích nhỏ hoặc không có lợi - rất có thể chỉ cần tăng thời gian tải hình ảnh.

Bên cạnh đó, đó là một lựa chọn tốt để lưu trữ một số họa tiết / hình ảnh nhỏ trong một bitmap, đặc biệt là khi bạn cần tất cả chúng trong cùng một tình huống.

Vì định dạng lưu trữ JPEG có lẽ là lựa chọn tốt nhất cho một số kết cấu như cỏ hoặc tường, nơi mà việc mất thông tin có lẽ không thể phát hiện được. Tiếp theo là PNG khi bạn cần minh bạch hoặc khi bạn không thể thanh toán khi bị mất thông tin, ví dụ như các sprite trong trò chơi 2D (người chơi, kẻ thù, rương kho bạc), bạn có thể muốn sử dụng PNG cho hình ảnh đó.

Khi nói về chi phí bộ nhớ, định dạng được sử dụng để lưu trữ đồ họa trò chơi trong hệ thống tệp hoàn toàn không liên quan. Nếu bạn lưu trữ bộ đệm pixel trong VRAM hoặc RAM (trình kết xuất phần mềm), bạn có thể đã lưu trữ chúng không bị nén, vì các trò chơi ưu tiên đọc nhanh pixel so với bộ nhớ được sử dụng bởi mỗi bộ đệm pixel.

Có dữ liệu nén được lưu trữ trong bộ nhớ không có ý nghĩa gì ngoại trừ việc bạn duy trì một số loại bộ đệm để lưu đĩa đọc, nhưng có lẽ bạn phải đọc từ bộ đệm đó đến trạng thái không nén cho các hình ảnh được sử dụng tại một thời điểm nhất định trong trò chơi của bạn.

Dữ liệu hình ảnh nén có ý nghĩa hơn một chút nếu có thể giải mã phần cứng nhanh. Đối với ánh xạ bình thường ít nhất, tôi nhớ http://en.wikipedia.org/wiki/3Dc này . Với điều đó bạn có thể lưu một số VRAM. Tôi không biết các ví dụ khác về giải mã phần cứng.

Trong sơ yếu lý lịch: bất kỳ định dạng nào được sử dụng cho trò chơi của bạn để lưu trữ đồ họa trong bộ lưu trữ liên tục, bạn sẽ phải giải mã và duy trì phiên bản không nén trong bộ nhớ động, bộ nhớ video hoặc cả hai, để có thể hiển thị nhanh khi cần.

Cuối cùng: Tôi là một anh chàng để bàn. Khi tôi nói "bộ nhớ", tôi luôn đề cập đến bộ nhớ động. Khi tôi nói "đĩa", "hệ thống tệp" hoặc "lưu trữ liên tục", tôi luôn đề cập đến bất cứ thứ gì thiết bị của bạn sử dụng làm bộ nhớ liên tục, thông thường tôi nghĩ trong các đĩa cứng. Khi bạn nói "hiệu quả bộ nhớ", tôi đã lấy nó cho "bộ nhớ động" chứ không phải "lưu trữ liên tục". Gần đây, tôi thấy rất nhiều người sử dụng từ "bộ nhớ" để chỉ "lưu trữ liên tục" (có thể đó là thuật ngữ của thiết bị di động?).