2010-12-29 27 views
7

Có một thuật toán nén nhanh hơn JPEG chưa được hỗ trợ tốt không? Tôi biết về jpeg2000 nhưng từ những gì tôi đã nghe nó không thực sự nhanh hơn nhiều.Có độ nén mất nhanh hơn JPEG không?

Chỉnh sửa: để nén.

Chỉnh sửa2: Nó sẽ chạy trên Linux 32 bit và lý tưởng nó phải ở trong C hoặc C++.

+1

để giải nén hoặc nén? – tenfour

+0

Chỉ tò mò, tại sao các hình ảnh cần phải được nén? Và bao nhiêu? –

+0

@Mark Ransom: Vâng, tôi cần chúng được nén để gửi chúng từ rô bốt hình người nhỏ với CPU 500Mhz và RAM 256MB trên UDP tới máy tính để xử lý. Tôi cần phải nhận được ít nhất 20 hình ảnh mỗi giây và thanh wifi không đủ nhanh để gửi nhiều dữ liệu hơn 1 giây vì vậy tôi đang sử dụng JPEG để giảm băng thông. –

Trả lời

3

Mã hóa và giải mã Jpeg phải là cực kỳ nhanh chóng. Bạn sẽ gặp khó khăn trong việc tìm kiếm một thuật toán nhanh hơn. Nếu nó chậm, vấn đề của bạn có lẽ không phải là định dạng mà là việc triển khai bộ mã hóa kém. Thử bộ mã hóa từ libavcodec trong dự án ffmpeg.

+0

Mã hóa JPEG được thiết kế để giải mã nhanh. Điều này không phải lúc nào cũng có nghĩa là nó cũng có mã hóa nhanh (trên thực tế, nhiều lần mã hóa chậm hơn nhiều). –

+0

Cả hai đều cực kỳ nhanh nếu bạn không phấn đấu để mã hóa tối ưu. Một x86 cấp thấp từ trong vài năm qua sẽ có thể mã hóa jpeg với tốc độ 30 megapixel mỗi giây hoặc tốt hơn (ước tính sơ bộ khỏi đỉnh đầu của tôi). –

+0

Bộ mã hóa dành cho việc mã hóa video nhất định được tối ưu hóa cho tốc độ. Tôi biết rằng MJPEG đã được rất nhiều nhanh chóng trong nhiều năm, mặc dù tôi luôn luôn nghĩ rằng nó đã phần cứng chuyên ngành để đạt được điều đó. –

2

Trong ngữ cảnh nào? Trên PC hoặc thiết bị di động?

Từ kinh nghiệm của tôi bạn đã có định dạng JPEG, JPEG2000, PNG, và ... uh, đó là về nó với nhiều loại "cũng hỗ trợ" hình ảnh trong một bối cảnh rộng (lossy hay không!)

(Hoan hô GIF đang trên đường ra.)

+0

Tôi muốn đi xa như vậy để nói JPEG2000 không phải là phổ quát, vì vậy danh sách thực sự xuống chỉ JPEG và PNG. –

+0

Bằng sáng chế trên LZW đã hết hạn ít nhất ở một số khu vực của Châu Âu, vì vậy không có lý do thực sự nào để tránh GIF ngoại trừ không gian màu hạn chế. Và điều đó có thể được phá vỡ (mặc dù khá xấu xí). – onemasse

+0

Nó dành cho một rô-bốt Linux nhúng. –

2

JPEG2000 không nhanh hơn chút nào. Có mã hóa hoặc giải mã không đủ nhanh với jpeg không? Bạn có thể có thể nhanh hơn rất nhiều bằng cách chỉ 4x4 FDCT và IDCT trên jpeg. Thật khó để tìm thấy bất kỳ tài liệu nào về libjpeg của IJG, nhưng nếu bạn sử dụng nó, hãy thử hạ thấp cài đặt chất lượng, nó có thể làm cho nó nhanh hơn, cũng có vẻ là một lựa chọn FDCT nhanh.

Ai đó đã đề cập đến libjpeg-turbo sử dụng hướng dẫn SIMD và tương thích với libjpeg thông thường. Nếu đó là một lựa chọn cho bạn, tôi nghĩ bạn nên thử nó.

+0

Mã hóa hình ảnh nhị phân thành JPEG quá chậm trên robot linux nhúng của tôi. –

+0

@Richard Knop: Nhị phân? Như màu đen/trắng không có màu xám và không có màu? Điều đó thay đổi mọi thứ đáng kể. –

+0

@Mark Ransom Tôi đã chuyển hình ảnh nhị phân thành hình ảnh "thô". Chúng đầy màu sắc. –

1

Tôi nghĩ thuật toán nén dựa trên wavelet thường chậm hơn so với các thuật toán sử dụng DCT. Có lẽ bạn nên xem các định dạng JPEG XR và WebP.

3

Bạn có hướng dẫn MMX/SSE2 có sẵn trên kiến ​​trúc đích của mình không? Nếu có, bạn có thể thử libjpeg-turbo. Ngoài ra, bạn có thể nén các hình ảnh với một cái gì đó như zlib và sau đó giảm tải thực tế để máy khác? Có bắt buộc nén thực sự mất dữ liệu của hình ảnh diễn ra trên thiết bị nhúng không?

+0

giấy phép cho libjpeg-turbo là lgpl = không phù hợp với các dự án nguồn mở thực sự hoặc thương mại/thực tế. –

+0

Nén 'zlib' chậm hơn vài lần so với nén jpeg. –

+0

png sử dụng nén zlib. zlib là đau đớn với nhúng, mã không thực sự 32/64 bit sạch và cross biên dịch kém cũng như đòi hỏi rất nhiều ram trong cấu hình mặc định của nó. phụ thuộc vào cách bạn nhúng. –

1

Bạn chỉ cần thay đổi kích thước hình ảnh thành hình ảnh nhỏ hơn nếu bạn không yêu cầu độ trung thực của hình ảnh đầy đủ. Tính trung bình mỗi khối 2x2 vào một pixel đơn lẻ sẽ giảm kích thước xuống 1/4 rất nhanh.

+0

Trừ khi bạn viết một số mã cực kỳ được tối ưu hóa để thực hiện downscaling, việc thực hiện nén jpeg với 'libavcodec' có thể sẽ mất ít thời gian hơn mã rút gọn của bạn. –

+0

@R, không phải là thuật toán tôi đề xuất có khả năng được tối ưu hóa cực kỳ dễ dàng? –

+0

Có nếu bạn viết nó trong asm, nhưng tôi nghi ngờ một thực hiện C thuần túy của thuật toán downscaling có thể đánh bại bộ mã hóa jpeg libavcodec, ít nhất là không với công nghệ trình biên dịch hiện tại. –

Các vấn đề liên quan