реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> LPC для обработки видео
kiv121
сообщение Mar 30 2011, 12:55
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586



Прошу прощения у модератора за повтор темы от AVR.
Проектируем плату для обработки и передачу чб фото с видеокамеры.
Входная часть от ПАЛ на АЦП и плисине сделана, надо медленно передать фото очень далеко
по медленному радиоканалу. Хотелось бы это все сжать. Какие решения на этот счет есть?
Почему?: не хотим поиметь гемр из-за вероятности ошибки и большой времени передачи,
а рядом еще идет и телеметрия.
Go to the top of the page
 
+Quote Post
Aner
сообщение Mar 30 2011, 13:14
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



LPC не очень то, плисины те что пошустрее очень.
Go to the top of the page
 
+Quote Post
kiv121
сообщение Mar 30 2011, 13:20
Сообщение #3


Участник
*

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586



Плисина занимается только оцифровкой видео в любой момент времени,
и записью быстро в озу. А стоит еще море задач и мешать ей нельзя
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Mar 30 2011, 13:27
Сообщение #4


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Дык фото или видео?

Если у AVR хватает силёнок сжать фото кадр, то любой кортекс в 10 раз быстрее может.


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
kiv121
сообщение Mar 30 2011, 13:42
Сообщение #5


Участник
*

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586



Раз в ~5 мин сформировать сжатое фото в чб пале. Вот и спрашиваю про алгоритм и время его выполнения
Go to the top of the page
 
+Quote Post
Aner
сообщение Mar 30 2011, 13:53
Сообщение #6


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



Опять забавно чб пал, нет там пала. Просто видео сигнал. Пал - это цвет, с поднесущими в спектре видео и тд итп.
Если ч/б это просто видео. Сжать без потери качества трудно, но можно. все зависит от требований к мелким деталям. Выбор алгоритма тоже.
Ставьте еще плисину, дешевле и быстрее. LPC под компрессию видео не заточены, ни ARM-7, ARM-9, Cortex-ы просто медленны и бесполезны для сжатия видео.
Либо видео процы с DSP либо плисина.
Go to the top of the page
 
+Quote Post
kiv121
сообщение Mar 30 2011, 14:20
Сообщение #7


Участник
*

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586



Согласен. Но из-за через ж-ной задачи плисина уберает цвет (пока) из пал камеры и хотелось
бы сжать это всё оставшееся без потерь качества. Да это мы всё и сделали. Вот советуюсь
по поводу компресси остатка от пала чб сигнала. Понимаю что всё... Просто идеи

а весело читающий blackfin что про блекфин чего говорит?
любая ифо нужна.
Go to the top of the page
 
+Quote Post
kiv121
сообщение Mar 30 2011, 14:46
Сообщение #8


Участник
*

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586



Да всё просто - сроки убийственные... LPC знаю, кортекс нет. На это дело, хоть и хоршее, времени нет.
А всё наладить, развести и запрограммировать, увести и поставить ... Мне уже до этой скорости. Просто спрашиваю
в этих рамках - реализуемо аль нет. Да вот и всё. Собственно разговор был просто о сжатии файла, а потом его разжать...
Go to the top of the page
 
+Quote Post
blackfin
сообщение Mar 30 2011, 15:02
Сообщение #9


Гуру
******

Группа: Свой
Сообщений: 3 106
Регистрация: 18-04-05
Пользователь №: 4 261



Цитата(kiv121 @ Mar 30 2011, 17:20) *
а весело читающий blackfin что про блекфин чего говорит?

С задачей сжатия одного ч/б кадра 720*576 за 5 мин. справится любой МК, и даже AVR.
Кроме того, на форуме работает функция поиска: JPEG.
И, наконец, сайт ADI дает глубокий повод для раздумий: JPEG Encoder.
Go to the top of the page
 
+Quote Post
kiv121
сообщение Mar 30 2011, 15:25
Сообщение #10


Участник
*

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586



Вопрос: объясните бестолковому - сжать, передать без абсолютного потери качества!!!
и потом восстановить - это подойдет?

Да вся проблема не голых баб наблюдать, а снежные лавины у ЖД РФ, вот и советуюсь...
Go to the top of the page
 
+Quote Post
andrewkrot
сообщение Mar 30 2011, 15:55
Сообщение #11


Местный
***

Группа: Участник
Сообщений: 306
Регистрация: 11-11-04
Из: Москва
Пользователь №: 1 106



Цитата(kiv121 @ Mar 30 2011, 15:55) *
надо медленно передать фото очень далеко
по медленному радиоканалу

Огласите плс. числа - скорость канала, сколько раз в час нужно кадры передавать, качество оцифровки видео. А то как-то трудно без этого советы давать
Go to the top of the page
 
+Quote Post
andrewlekar
сообщение Mar 31 2011, 04:53
Сообщение #12


Знающий
****

Группа: Участник
Сообщений: 837
Регистрация: 8-02-07
Пользователь №: 25 163



Жмите кадр в джипег, передавайте. В чем проблема то? Кортекс прекрасно справится, только внешней памяти надо побольше.
Go to the top of the page
 
+Quote Post
kiv121
сообщение Mar 31 2011, 08:34
Сообщение #13


Участник
*

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586



Утомился. Есть подход сжать и весело посмотреть. А есть подход реально детально рассмотреть.
Это разные вещи: делитанские или любительские.
Поэтому промышленное оборудование - одна цена а... другая
JPEG можно без потери качества восстановить в первоиссточник???
Блин вопрос был про алгоритм типа зип и унзип и на си

Сообщение отредактировал kiv121 - Mar 31 2011, 08:39
Go to the top of the page
 
+Quote Post
Aner
сообщение Mar 31 2011, 08:41
Сообщение #14


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



Цитата(andrewlekar @ Mar 31 2011, 07:53) *
Жмите кадр в джипег, передавайте. В чем проблема то? Кортекс прекрасно справится, только внешней памяти надо побольше.

Какой Кортекс?
Go to the top of the page
 
+Quote Post
scifi
сообщение Mar 31 2011, 09:02
Сообщение #15


Гуру
******

Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136



Цитата(kiv121 @ Mar 31 2011, 12:34) *
JPEG можно без потери качества восстановить в первоиссточник???

Да, может. При правильных настройках.

Цитата(kiv121 @ Mar 31 2011, 12:34) *
Блин вопрос был про алгоритм типа зип и унзип и на си

Алгоритмы типа зип не дадут существенного сжатия картинки с камеры.

Это не обсуждение, а какое-то переливание из пустого в порожнее. Сказано же, любой процессор справится с сжатием кадра в JPEG за 5 минут. Лишь бы памяти хватало.
Go to the top of the page
 
+Quote Post
andrewkrot
сообщение Mar 31 2011, 09:39
Сообщение #16


Местный
***

Группа: Участник
Сообщений: 306
Регистрация: 11-11-04
Из: Москва
Пользователь №: 1 106



Цитата(scifi @ Mar 31 2011, 12:02) *
Да, может. При правильных настройках.


Алгоритмы типа зип не дадут существенного сжатия картинки с камеры.

Это не обсуждение, а какое-то переливание из пустого в порожнее. Сказано же, любой процессор справится с сжатием кадра в JPEG за 5 минут. Лишь бы памяти хватало.

1 кадр видео с качеством 8бит 15МГц передается на скорости 115200 бит/сек прибл. 41 секунду (если я не ошибся в расчетах). С полным качеством и безо всякого сжатия за 5 минут. Вопрос - зачем себе городить проблемы со сжатием и распаковкой JPEG на AVR или еще на чем, если для этого нужно время >41 сек.+ время на передачу этого сжатого кадра? Просто пишите кадр в буфер и передавайте себе спокойно. Быстрее передать на меньшей скорости, чем кодировать и раскодировать видео на микроконтроллерах. И к тому же еще и дешевле будет. И еще не понятно, каким образом это видео в цифру кодируется - простым АЦП, или как?

Сообщение отредактировал andrewkrot - Mar 31 2011, 09:44
Go to the top of the page
 
+Quote Post
khach
сообщение Mar 31 2011, 10:41
Сообщение #17


Гуру
******

Группа: Свой
Сообщений: 3 439
Регистрация: 29-12-04
Пользователь №: 1 741



Меняйте АРМ- STM32F2xx (именно F2) имеет параллельный интерфейс видео входа- до 14 бит 30 Мгц. Можно сразу видео АЦП цеплять. DMA разложит кадр в память, а дальше-программно. ОЗУ только маловато для работы с кадром- прийдется экономить или поджимать на-ходу по строчкам.
Go to the top of the page
 
+Quote Post
Aner
сообщение Mar 31 2011, 10:54
Сообщение #18


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



Цитата(khach @ Mar 31 2011, 13:41) *
Меняйте АРМ- STM32F2xx (именно F2) имеет параллельный интерфейс видео входа- до 14 бит 30 Мгц. Можно сразу видео АЦП цеплять. DMA разложит кадр в память, а дальше-программно. ОЗУ только маловато для работы с кадром- прийдется экономить или поджимать на-ходу по строчкам.

А кто будет заниматься синхронизацией, уовнями белого черного итд.?
Вы сами хоть делали такое, перед тем как советовать.
Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть.
MPEG для чего то придумали, ну и как его на F2 сделать?
Go to the top of the page
 
+Quote Post
khach
сообщение Mar 31 2011, 11:58
Сообщение #19


Гуру
******

Группа: Свой
Сообщений: 3 439
Регистрация: 29-12-04
Пользователь №: 1 741



Цитата(Aner @ Mar 31 2011, 12:54) *
А кто будет заниматься синхронизацией, уовнями белого черного итд.?
Вы сами хоть делали такое, перед тем как советовать.
Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть.
MPEG для чего то придумали, ну и как его на F2 сделать?

Вообще то видео-ацп обычно имеет схемы синхронизации внутри. И уровни белого-черного тоже он привязывает. Именно на STM32F2xx- нет, не делал. Семплы только недавно приехали, юзерманул только появился, а аппликух по DCMI (Digital Camera Interface) тоже еще нет. Пока макетную плату разводим на свой страх и риск. Чтобы MPEG жать надо внешнюю память ставить. Для этого у STM32F2xx есть FSMC - прийдется внешнюю SRAM цеплять. Для наших задач оно ненадо, поэтому не разводим.
Go to the top of the page
 
+Quote Post
Aner
сообщение Mar 31 2011, 17:14
Сообщение #20


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



Да нет STM32F2xx никакого MPEG или H264, непотянет, нет в них видео ацп, медленный проц, архитектура проца вообще для работы с обработкой видео потока не годиться.
Какая там еще внешняя память, если проц не тот. Если не хочется делать то можно и готовый чип купить.
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Mar 31 2011, 17:31
Сообщение #21


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Цитата(kiv121 @ Mar 31 2011, 13:34) *
JPEG можно без потери качества восстановить в первоиссточник???

Можно сжать раз в 5 и на глаз не отличить от оригинала. На кортексе.
Только как уже все задавали вопрос - зачем сжимать, если со скоростью 19200 бод можно свободно передавать картинку 768*576 ч/б в несжатом виде.


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
Aner
сообщение Mar 31 2011, 18:52
Сообщение #22


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



Но это же долго. При большом расстоянии, как указывалось, большая вероятность потери данных. Передавать желательно за короткое время.
Сжимать раз 20...100 желательно. Это позволяет и MPEG и H264 и ряд других алгоритмом. В 5 раз не очень интересно. Потери части информации не избежать.
Просто нужно оговорить, какие потери информации приемлемы. Обычно это мелкие детали на ч/б изображении.
Go to the top of the page
 
+Quote Post
M_Andrey
сообщение Mar 31 2011, 19:59
Сообщение #23


Частый гость
**

Группа: Свой
Сообщений: 158
Регистрация: 15-10-07
Из: Й-Ола
Пользователь №: 31 376



Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр.
Go to the top of the page
 
+Quote Post
Aner
сообщение Apr 1 2011, 10:49
Сообщение #24


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



Цитата(M_Andrey @ Mar 31 2011, 22:59) *
Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр.

Это не верно. Вы просто не знаете как это упаковывается, распаковывается. Вообщето если это чб картинка, то лучше подходит формат GIF или TIFF или RAW.
В JPEG при потери пары байт вы получите несколько 8x8 квадратиков с неправильными пикселями по ярости.
И то это маловероятно в канале передаче, где есть коды исправляющие ошибки.
Go to the top of the page
 
+Quote Post
pofikus
сообщение Apr 5 2011, 13:04
Сообщение #25


Участник
*

Группа: Участник
Сообщений: 22
Регистрация: 8-12-10
Пользователь №: 61 494



для черно-белой картинки хорошо должна подойти простенькая RLE компрессия.
http://en.wikipedia.org/wiki/Run-length_encoding
Go to the top of the page
 
+Quote Post
ar__systems
сообщение Apr 5 2011, 13:31
Сообщение #26


self made
****

Группа: Свой
Сообщений: 855
Регистрация: 7-03-09
Из: Toronto, Canada
Пользователь №: 45 795



Цитата(pofikus @ Apr 5 2011, 08:04) *
для черно-белой картинки хорошо должна подойти простенькая RLE компрессия.
http://en.wikipedia.org/wiki/Run-length_encoding

Вы попробуйте для начала, прежде чем советовать. RLE подойдет если у вас что-то типа гравюры - т.е. есть всего два цвета -- черный, и белый. Ни для каких нормальных фоток и видео с полутонами RLE работать не будет.

Цитата(Aner @ Apr 1 2011, 05:49) *
Это не верно. Вы просто не знаете как это упаковывается, распаковывается. Вообщето если это чб картинка, то лучше подходит формат GIF.

Опять-таки -- только если это графика без полутонов. На любой нормальной фотографии JPEG будет работать существенно лучше. Он был сделан именно для компресссии фоток, в отличии от гифа, который вообще не в курсе, что сжимаемый поток байтов -- картинка.

Сообщение отредактировал ar__systems - Apr 5 2011, 13:32
Go to the top of the page
 
+Quote Post
pofikus
сообщение Apr 5 2011, 19:04
Сообщение #27


Участник
*

Группа: Участник
Сообщений: 22
Регистрация: 8-12-10
Пользователь №: 61 494



Цитата(ar__systems @ Apr 5 2011, 16:31) *
Вы попробуйте для начала, прежде чем советовать. RLE подойдет если у вас что-то типа гравюры - т.е. есть всего два цвета -- черный, и белый. Ни для каких нормальных фоток и видео с полутонами RLE работать не будет.




пробовал, по этому и советую.... но предварительно надо подготовить картинку....
В данном случае так как радио канал наверно зашумлен, я бы картинку не компресировал, а редко передавал бы полную картинку, а в промежутках изменения происшедшие с момента передачи полной картинки....

Сообщение отредактировал pofikus - Apr 5 2011, 19:49
Go to the top of the page
 
+Quote Post
Aner
сообщение Apr 5 2011, 19:19
Сообщение #28


Гуру
******

Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463



ar__systems чёт не то пишет.
GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. GIF хорош тем, что можно потерять более половины картинки (кадра), но распознавание сюжета остается высокое, в отличии от JPEGа.
... сжимаемый поток..., вообще не отсюда. Причем сдесь это, если говорим о стандартах сжатия.
LPC и обработка видео как то не стыкуются все же. Не для этого LPC_шки разрабатывали.
Go to the top of the page
 
+Quote Post
NetTracer
сообщение Apr 5 2011, 19:42
Сообщение #29





Группа: Участник
Сообщений: 6
Регистрация: 16-12-05
Пользователь №: 12 291



Цитата(M_Andrey @ Mar 31 2011, 23:59) *
Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр.


Какие потери байт? О чем вы?
Передача данных разве не подразумевает протокол?
Пакеты, кадры, CRC. итд итп.
Go to the top of the page
 
+Quote Post
pofikus
сообщение Apr 5 2011, 19:46
Сообщение #30


Участник
*

Группа: Участник
Сообщений: 22
Регистрация: 8-12-10
Пользователь №: 61 494



Цитата(Aner @ Apr 5 2011, 22:19) *
ar__systems чёт не то пишет.
GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. GIF хорош тем, что можно потерять более половины картинки (кадра), но распознавание сюжета остается высокое, в отличии от JPEGа.
... сжимаемый поток..., вообще не отсюда. Причем сдесь это, если говорим о стандартах сжатия.
LPC и обработка видео как то не стыкуются все же. Не для этого LPC_шки разрабатывали.



у автора сжатие потока - глобальная задача, а ваши GIF, TIF, JPEG - тоже методы сжатия потока...
Go to the top of the page
 
+Quote Post
ar__systems
сообщение Apr 5 2011, 20:49
Сообщение #31


self made
****

Группа: Свой
Сообщений: 855
Регистрация: 7-03-09
Из: Toronto, Canada
Пользователь №: 45 795



Цитата(Aner @ Apr 5 2011, 14:19) *
GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью.

Вы, извините, что-то где-то слышали, но понятия не имеете, о чем говорите. Да, гиф 8 бит, JPEG 24. Ну и что? Вы для начала тупо возьмите и поэксперементируйте, как сжимает Гиф и JPEG. Например, следующая картинка:



После того как я ее в черно-белую переделал и сконвертил в GIF, JPEG -- 17KB, GIF -- 150KB. И меньше гиф уже никак не станет, а JPEG eще может жать и жать, при 17КB никаких артефактов еще нет.

А после экспериментов почитайте как они оба сжимают, чтобы не писать в следующий раз нелепицу.

Цитата(NetTracer @ Apr 5 2011, 14:42) *
Какие потери байт? О чем вы?
Передача данных разве не подразумевает протокол?
Пакеты, кадры, CRC. итд итп.

+1.


Сообщение отредактировал ar__systems - Apr 5 2011, 20:46
Go to the top of the page
 
+Quote Post
sasamy
сообщение Apr 6 2011, 02:59
Сообщение #32


Знающий
****

Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858



Цитата(ar__systems @ Apr 6 2011, 00:49) *
После того как я ее в черно-белую переделал и сконвертил в GIF, JPEG -- 17KB, GIF -- 150KB. И меньше гиф уже никак не станет, а JPEG eще может жать и жать, при 17КB никаких артефактов еще нет.


Удивительно - что только не советуют кроме того что было специально разработано для таких целей
http://en.wikipedia.org/wiki/Portable_Network_Graphics
Go to the top of the page
 
+Quote Post
blackfin
сообщение Apr 6 2011, 03:10
Сообщение #33


Гуру
******

Группа: Свой
Сообщений: 3 106
Регистрация: 18-04-05
Пользователь №: 4 261



Цитата(sasamy @ Apr 6 2011, 06:59) *
Удивительно - что только не советуют кроме того что было специально разработано для таких целей
http://en.wikipedia.org/wiki/Portable_Network_Graphics
Ага.. По Вашей же ссылке:
Цитата
Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize (often 5–10 times) with negligible gain in quality.
Go to the top of the page
 
+Quote Post
sasamy
сообщение Apr 6 2011, 04:42
Сообщение #34


Знающий
****

Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858



Цитата(blackfin @ Apr 6 2011, 07:10) *
Ага.. По Вашей же ссылке:



А Вы отмотайте тему на пару страниц - речь идет о ч/б изображении - на них jpeg вообще теряет все свои преимущества в компрессии.
Go to the top of the page
 
+Quote Post
sasamy
сообщение Apr 6 2011, 05:44
Сообщение #35


Знающий
****

Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858



Цитата(sasamy @ Apr 6 2011, 08:42) *
А Вы отмотайте тему на пару страниц - речь идет о ч/б изображении - на них jpeg вообще теряет все свои преимущества в компрессии.


Все же я не прав похоже, нашел сравнение как раз по теме в гугле
Lossless Compression of Grayscale Medical Images - Effectiveness of Traditional and State of the Art Approaches

там jpeg нахваливают sm.gif

Go to the top of the page
 
+Quote Post
etoja
сообщение Apr 6 2011, 13:05
Сообщение #36


Профессионал
*****

Группа: Свой
Сообщений: 1 121
Регистрация: 14-01-05
Из: Москва
Пользователь №: 1 952



Цитата(sasamy @ Apr 6 2011, 08:42) *
А Вы отмотайте тему на пару страниц - речь идет о ч/б изображении - на них jpeg вообще теряет все свои преимущества в компрессии.


Вы сами придумали эту чушь?

GIF - алгоритм сжатия без потерь (качества).
JPEG - алгоритм сжатия с потерями. В нём применяется дискретное косинусное преобразование (DCT). Из всех преобразований оно имеет наиболее быстро спадающие коэффициенты, поэтому обеспечивает наибольшее сжатие среди алгоритмов, разбивающих изображение на квадраты 8х8 точек.

Большее сжатие может обеспечить лишь вейвлет-алгоритм, но только потому, что обрабатывает всё изображение целиком, не разбивая на квадраты.
А коэффициенты вейвлет-алгоритма спадают медленнее, чем у DCT.
Go to the top of the page
 
+Quote Post
sasamy
сообщение Apr 6 2011, 17:24
Сообщение #37


Знающий
****

Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858



Цитата(etoja @ Apr 6 2011, 17:05) *
Вы сами придумали эту чушь?


Сходите-ка в FAQ
http://www.faqs.org/faqs/jpeg-faq/part1/
Цитата
Gray-scale images do not compress by such large factors. Because the human
eye is much more sensitive to brightness variations than to hue variations,
JPEG can compress hue data more heavily than brightness (gray-scale) data.
A gray-scale JPEG file is generally only about 10%-25% smaller than a
full-color JPEG file of similar visual quality. But the uncompressed
gray-scale data is only 8 bits/pixel, or one-third the size of the color
data, so the calculated compression ratio is much lower. The threshold of
visible loss is often around 5:1 compression for gray-scale images.
Go to the top of the page
 
+Quote Post

3 страниц V   1 2 3 >
Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th July 2025 - 16:52
Рейтинг@Mail.ru


Страница сгенерированна за 0.01701 секунд с 7
ELECTRONIX ©2004-2016