Сообщений в теме: 62

[Dmitry Rubinshteyn]

Вопрос: Знаете ли вы, как уменьшить вдвое пентаксовский рау файл (*.pef), который обычно занимает около 13 Мб?
Ответ: Обжать WinRar'ом, он станет вдвое меньше.

Утверждение: Рау файл Canon 10D (*.crw) без обжатия вдвое меньше по объему чем пентаксовский при том же размере матрицы и он WinRar'ом практически не обжимается.
Вопросы: Почему владельцы пентакса должны мучатся из-за явно не оптимального алгоритма сжатия? Нельзя ли что-то изменить в прошивке?

Ну и еще один вопрос, раз уж я тут начал про рау файлы.
Вопрос: Какой просмотрщик, кроме Pentax Photo Browser позволяет просматривать рау файлы пентакса? Кто-нибудь сумел научить ACDSee просматривать эти файлы?

Заранее благодарен />

(Edited by Dmitry Rubinshteyn at 2:28 pm on June 7, 2004)

[Vladimir P]

Dmitry Rubinshteyn   Почему владельцы пентакса должны мучатся из-за явно не оптимального алгоритма сжатия?

    Как я понимаю, вся идея raw файла в том, что пользователь получает непосредственно данные с матрицы, без какого-то либо их преобразования и интерполяции в камере (hint: посмотрите перевод слова raw). Поэтому требование иметь "упаковку" файла для этого формата как бы выходит за рамки его исходных функций. Нравится хранить в упакованном виде - так кроме Rar-а есть и еще много других архиваторов.
  Вопрос о том, почему у Кэнона файл меньше - нужно смотреть структуру данных там и там, а потом думать, почему именно так сделали. Скорее всего, Кэнон применяет для этого формата файла какой-нибудь алгоритм сжатия без потерь (просто другого варианта, при котором клиент с 6-метровой матрицы получает 6-метровый файл и при этом имеет в каждой точке более 8 бит на цветность, я придумать не могу). А дальше есть море вариантов. Экономим на дисковом пространстве, но проигрываем на "скорострельности" в этом режиме (время на сжатие нам нужно затратить?) и в токопотреблении (процессору нужно больше операций совершить). Короче, за всеми этими решениями стоЯт конкретные компромиссы в тех. задании. Я не думаю, что дело в трудности программирования (JPEG-то они делают), просто так обе эти фирмы считают для себя правильным.
    Из чисто философских соображений - raw формат предназначен для тех случаев, когда фотограф сам серьезно занимается постобработкой снимков и/или печатает фотографии с предельно большим для данной матрицы качеством. В нормальном обществе (а упомянутые камеры производится для людей, живущих в нормальном обществе) такие фотографы вряд ли ограничены в дисковом и архивном пространстве для снимков. Да и даже прикинуть, сколько места на диске может занимать один снимок в окончательной редакции (с учетом различных промежуточно сохраненных шагов и разных вариантов обработки). Иногда это даже не сотни мегабайт.

Успехов.                                  Владимир.

[AbdullA]

Вообще-то я в одной теме уже пытался посчитать немножко.... На матрице 6 с небольшим млн. монохромных точек, АЦП 12тиразрядный, соответственно имеем чуть больше 9МБ сырых данных. Но откуда размер фалйа 13МБ - мне совершенно непонятно.

[Genrih]

Похоже, они в raw еще и jpeg засунули. Порушилась однажды файловая система на битком забитой флешке, и утилита, которая тупо сканирует по секторам, нашла на каждый raw-файл еще и jpeg.
Эта тема как-то обмусоливалась на dpreview.  
Насчет просмотровщиков: Acdsee пока не собирается PEF поддерживать, вроде бы Breeze Browser обещался

[Max]

Кажется, читал в PDML, что в RAW сохраняются 16 бит, при этом 4-пустые (во всяком случае, не используются). Отсюда 12 мегов и набегает.

[Vladimir P]

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

Успехов.                             Владимир.

[AbdullA]

Мдя... Если там действительно 16 бит и jpeg внутри - то ИМХО руки им поотшибать и больше программировать ничего не давать.

[Vladimir P]

Стоп! Откуда взялся jpeg? То, про что пишет Genrih, может вообще никак к собственно raw отношения не иметь. Ну, скажем, пишут они на карточку еще небольшой файлик как превьюшку для того, чтобы было проще файловую навигацию на "телевизоре" камеры устраивать, и все тут. Или там этот jpeg серьезный по параметрам? Подробности - в студию, плиз!

Успехов.                          Владимир.

[Genrih]

Подробности таковы, что все jpegи "недецкие" - от 700кб до двух мегов примерно, снимал только в raw, и до обрушения там были только .pef файлы. Но это, в общем, не очень интересно, поскольку наличие jpeg'a становится очевидным при сопоставлении размера pef'a и его содержания.  То, что он не фикс, уже должно настораживать, правда? />

[Dmitry Rubinshteyn]

Спасибо всем!
Владимир, я прекрасно понимаю, что такое рау и с чем его едят />. Архивирование данных не подразумевает их искажения. Встроенного в pef jpeg'а не замечал. Мне все же кажется, что такой большой размер файла это пентаксовский баг. Архивирование rar'ом дал как пример, любой другой архиватор тоже обожмет и довольно существенно. Видимо пентакс просто не стал заморачивать себе голову оптимизацией файлов и все тут. Кэнон не проигрывает по скорострельности и скорости расходования батарей, но файл получается сжатый.
И я ни в коем случае не призываю переходить на кэнон.

Может этот форум читает кто-нибудь, кто сможет повлиять на разработчиков следующей прошивки, если это вообще возможно в прошивке исправить. Ну, а если нет, то WinRar никто не отменял. />

А так, если кто-нибудь может разобрать структуру рау файлов, я готов дать образцы от кэнона и пентакса. Сам не могу по причине малограмотности в программировании, уж извините />. Могу только сказать, что если через любой дос-вьювер просматривать два рау файла зажав и не отпуская при просмотре кнопку PageDown, то в пентаксовском видно очень много пустых мест, в кэноновском их почти нет. Просто наблюдение.

[AbdullA]

Дмитрий, а можно мне файлик (пожатый зипом или раром />) на dmagalyas на itmvt.ru
Будет время - изучу "поглубже" />

[Hobbymaker]

Скажу сразу: я не знаю наверняка, в чём там суть. Но выскажу гипотезу.

Возможно размер RAW файлов выбирается на компромиссной основе. Можно забацать грамотную компрессию, но тогда от момента считавания данных с матрицы до появления готового RAW-файла на флэшке будет проходить довольно много времени (по электронным меркам, понятное дело). А можно безо всяких оптимизаций и сжатия по быстренькому скидывать RAW-данные на носитель. Места такой файл будет занимать ощутимо больше, но зато камера будет скорее готова для съемки следующего кадра.

Сильно не ругайтесь. /> /> /> Это всего лишь гипотеза. />

[AbdullA]

Та ни, это всё понятно... Но добивать 12бит до 2х байт нулями - это ж чем надо думать? ИМХО тут просто из-за скорости работы с памятью всё будет медленнее, нежели перепаковать 2х12бит в три байта (или больше, если слово 16 или 32 бит). Про LZW пока даже и речи нет (хотя у всех остальных и с этим никаких проблем).

[Hobbymaker]

1. Я не такой компьютерный спец., ув. Abdulla, поэтому не совсем понял Вашу реплику. Почему бы не добить 12 бит нулями ( или единицами />  ) до нужного размера вместо того, чтобы тратить время на переупаковку?  

2. "...у всех остальных и с этим никаких проблем."

А как скоро "у всех остальных" камеры готовы делать следующий снимок после записи RAW на носитель? (При одинаковом числе пикселей на матрице.) Если везде время одинаковое, то тогда -- да. Тогда я с Вами согласен.  

[AbdullA]

Почему бы не добить 12 бит нулями ( или единицами    до нужного размера вместо того, чтобы тратить время на переупаковку
Потому что в наши дни, "когда космические корабли борздят просторы Большого Театра" (С), быстрее перепаковать эти данные (да и вообще это по сути потоковая запись), чем записать на треть(!) данных больше, т. к. основной "тормоз" - как раз флэшка. Да и не для того люди гигабайтные карточки покупают, чтоб по 200 метров мусора на них таскать.

Если везде время одинаковое, то тогда -- да. Тогда я с Вами согласен.
Я ими не снимал, но судя по обзорам - примерно одинаковое. Да и Дмитрий выше пишет, что проблем со скорострельность нет.

[CyrilTheGreat]

Абсолютно сагласен с Abdulla - память дешевая - перетасовать 12Мб в памяти занимает милисекунды, а если нужна скорострельность, то добавим буфер на несколько кадров с параллельной обработкой (как в 10D - там на 9 кадров буфер). А вот экономия места на флешке - это серьезная проблема.

(Edited by CyrilTheGreat at 4:51 pm on June 9, 2004)

[Hobbymaker]

...быстрее перепаковать эти данные (да и вообще это по сути потоковая запись)...

Не факт. Для столь категоричных заявлений надо знать подробнее аппаратную часть. ИМХО. Потоковая-то она потокавая. Но как этот поток обрабатывается? Что-то ведь берут на себя "железки"... Не все программно делается...

... примерно одинаковое.
Насколько "примерно"? Я вот и говорю, что тут надоть конкретные циферки озвучить... В смысле: было бы неплохо их озвучить для предметности разговора...

[Hobbymaker]

Вдогонку: кстати интересен и такой вопрос: "насколько быстродействующи процессоры на борту цифровых камер?" Универсальны ли те процессоры? Имеют ли оптимизацию для потоковых операций? Может, все дело в "бортовых" процессорах? Просто еще одна гипотеза...

[CyrilTheGreat]

Цитата

Quote: from Hobbymaker on 4:53 pm on June 9, 2004
...быстрее перепаковать эти данные (да и вообще это по сути потоковая запись)...

Не факт. Для столь категоричных заявлений надо знать подробнее аппаратную часть. ИМХО. Потоковая-то она потокавая. Но как этот поток обрабатывается? Что-то ведь берут на себя "железки"... Не все программно делается...

... примерно одинаковое.
Насколько "примерно"? Я вот и говорю, что тут надоть конкретные циферки озвучить... В смысле: было бы неплохо их озвучить для предметности разговора...

Вот только что провел тест 12Мб в памяти скомпрессилось за 0.012 сек - написал программу на java использовал в ней библиотеку zip. Основной затык всегда процессы ввода-вывода (в данном случае запись/считывание на флешь). Потоки всегда обрадатываются программно - в случае аппаратно-зависимых вещей - микропрограммами прописаннами где-то в аналоге bios'a. Цифровая камера - это же компьютер с объективом, а вместо видеокарты -  сенсор, я не удивлюсь, если года через два туда засунут графический процессор и программеры всех мастей начнут писать программы на java для фотоаппаратов.


(Edited by CyrilTheGreat at 5:10 pm on June 9, 2004)

[AbdullA]

Насколько "примерно"? Я вот и говорю, что тут надоть конкретные циферки озвучить...
Озвучиваю />:
Для ЕОС 300Д - 2,5 к/с (до 4х кадров в серии) - взято с кэнон.ру
Для *истД - 2,6 к/с (до 6ти кадров в серии) - пентакс.ком

Разница только в длине серии - это говорит наверняка только о том, что у иста в два раза больше буфер (сказал бы в полтора, но нет - как раз с лишней третью в два раза получается />).

Может, все дело в "бортовых" процессорах?
Сильно сомневаюсь. Так уж получается, что я уже не первый год занимаюсь обработкой цифровых потоков - потому и не верю />
Тем больее что конкуренты LZW на лету применять успевают - это сильно сложнее, чем просто перепаковывать биты.

[Hobbymaker]

1. "Вот только что провел тест 12Мб в памяти скомпрессилось за 0.012 сек"  -- CyrilTheGreat

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

2. 2 Abdulla

Дык, я не спорю. Может оно так и есть. Я всего лишь гипотезы высказываю...  Кстати, вопрос: конкуренты успевают LZW применить на лету чисто программно? Или железочки им помогают?

[AbdullA]

Или железочки им помогают?
А какая разница? Всё это - вопрос цены. Цена решения (что железного, что программного) в пересчёте на одну выпущенную камеру - единицы долларов (т. е. доли процента от цены камеры). Плюсы - в буфер полезет больше кадров (длиннее серия) и экономия места на флэшке. ИМХО существенно. Весьма.

[Hobbymaker]

"А какая разница?"

Смотря для чего и/или для кого? Для понимания сути это важно. А про экономию места на флэшке речь не идет. Это очевидно.

Интересней понять почему дела обстоят именно так, а не иначе. Дело не в цене. Мне, к примеру, интересней понять глубинную суть. Типа: Сапоп аппаратно помогает процу потоки обрабатывать, а Рептах не смог железку сделать. Шибко торопился. Все в лоб программно делает. В резалте, фигня получилась...  Вот такого рода выводы мне были бы интересны...

[AbdullA]

Типа: Сапоп аппаратно помогает процу потоки обрабатывать, а Рептах не смог железку сделать. Шибко торопился. Все в лоб программно делает. В резалте, фигня получилась...  

Интересно, что вне зависимости от причин, "в резалте фигня и получилась". Увы, на причины мы уже не повлияем, а результат пожинать некоторым приходится.

(Edited by AbdullA at 5:50 pm on June 9, 2004)

[CyrilTheGreat]

Цитата

Quote: from Hobbymaker on 5:25 pm on June 9, 2004
1. "Вот только что провел тест 12Мб в памяти скомпрессилось за 0.012 сек"  -- CyrilTheGreat
Ну это не очень показательно. Вы ведь за десктопом, поди, современным сидите. А не за бортовым процем...

Как раз это и показательно, т.к. для обработки большого массива данных критичным ресурсом является память иначе своп, а в кеноне используется именно большой буфер (например, в 10Д - на 9 RAW, т.е. микруха на 128Мб). Даже если он будет обрабатывать фубер последовательно, а не параллельно, то все равно основное время - это время на запись.

[Hobbymaker]

2 Abdulla

Это да. Правда, мы не только на причины НЕ повлияем, но и некоторым НЕ поможем... тем, которые резалты пожинают... "Жнецам" может (может ли?) помочь только сам Рептах... Об том и исходный вопрос топика... А наш спич -- это, по любому, лишь ветер, поднимаемый крыльями бабочки.


(Edited by Hobbymaker at 6:17 pm on June 9, 2004)

[Hobbymaker]

2 CyrilTheGreat
...основное время - это время на запись.

Да тут спору нет.  Вопрос в другом: столь ли быстродействующая память внутри камеры стоит? По сравнению с компом. Есть ли подобие быстрого кэша? Сколько таких кэшей? Как все это организовано? И т.д. и т.п.

[AbdullA]

столь ли быстродействующая память внутри камеры стоит?
Наверняка сравнимая по производительности. Ибо ассортимент памяти сейчас невелик. У нас на работе везде используют чипы SDRAM 133Мгц 32Мбит - меньше и дешевле уже просто ничего нет.

Но вернёмся к криворукости разработчиков :biggrin:
Ме вот интересно, достигается ли та же скорость серийной съёмки при записи в формат тифф? Если да - то думаю все вопросы снимаются. Ибо "упаковка" в 8бит тифф с расчётом цветов, гаммы, шарпа и прочего заметно сложнее перепаковки из 12тибитных слов в 8 - 16 - 32битные.

И ещё о криворукости /> К сожалению я сейчас на дайалапе, поэтому прямую ссылочку не дам, но тем не менее. На сайте пентакс.ру почитайте инструкцию по установке программного обеспечения для *истД. Обратите внимание на сриншоты с крокозяблами. Программиста, который это сделал, должны бы уволить без выходного пособия. ИМХО />

[Hobbymaker]

1. У нас на работе везде используют чипы SDRAM 133Мгц 32Мбит - меньше и дешевле уже просто ничего нет.

"Везде" -- это где? В писюках? В "бортовых" микроконтроллерах ВСЕ может быть иначе...  

2. О криворукости разработчиков ничего сказать не могу. Лень время тратить чтоб эту криворукость констатировать. :biggrin: Тут я вполне доверяю Вашей экспертной оценке. />

[AbdullA]

"Везде" -- это где? В писюках? В "бортовых" микроконтроллерах ВСЕ может быть иначе...
Не, не в писюках /> Я ж выше написал - в устройствах разуплотнения цифровых потоков. А память медленнее сейчас просто не производят и не продают />

Да, кстати, вот, с пентакс.ру:


И кнопочку заботливо обвели, чтоб пользователь не промахулся... Уродцы />

(Edited by AbdullA at 10:25 am on June 10, 2004)