Ну вообще dpreview имело предпродажный сэмпл А700 за несколько недель до презентации, и Фил написал, что не выложил в общем-то готовый тест, только потому что из Сони попросили подождать чтобы они прислали ему продажный экземпляр. Ушлый мужик с cameralbs вполне мог себе вытребовать сэмпл в то же время, и щелкать в середине августа с А700 тесты. ИМХО оснований для того, чтобы считать это фэйком - минимум.
Файлы ARW практически не жмутся. Лучшие архиваторы показывают сжатие на уровне 5%. Т.е. ARW — уже сжатый формат. М.б. обычные архиваторы сумели бы сжать распакованный ARW лучше, чем внутрикамерный алгоритм, но врядли сильно лучше. Может % на 20, не больше. Ведь скорее всего в камере используется какая-нибудь модификация алгоритма LZW, а он довольно неплохо жмет. Т.е. все равно приходим к мысли о том, что cRAW — сжатие с потерями, аналог JPG.
В принципе, все может быть не так грустно. В камере для сжатия может использоваться какой-нибудь простенький алгоритм типа RLE, и использование в формате cRAW алгоритма типа LZW может здорово повысить эффективность сжатия. P.S. Провел простенькие эксперименты с конвертацией ARW. Что-то на RLE не очень похоже, даже LZW не дает такого сжатия. Хотя, зная структуру сенсоров на матрице, и проведя небольшое предварительное преобразование, можно сильно повысить эффективность работы алгоритмов сжатия.
Я просто не представляю себе, каким образом можно "урезать" RAW, в конце концов это ведь сырой формат, там на мой згляд просто нет шанса отхватить кусок - скажем разрешения, битности и т.п. Понятно что в каком нибудь JPEG это сделать ещё можно, но в RAW то как? Или я ошибаюсь? Единственное что я могу предположить, это то что в (сжатый raw) записывается не вся информация и скажем при этом могут появится какие либо ограниченя... Может так?
Ну все не совсем так. 1) Размер нежатого RAW с 12 Мп матрицы при использовании 12-битного АЦП вычисляется крайне просто. На один пиксел уходит 1.5 байта. В итоге 18 мегабайт, сколько и занимают ARW с А700 = ОНИ НЕСЖАТЫЕ. 2) Сжатие без потерь RAW файлов обычно использует более сложные методы чем LZH\LZW и пр., поэтому обычные архиваторы тут совершенно неэффективны. Сжатие без потерь может давать 20-30% уменьшения размера файла по опыту Кэнона и Никона. 3) Cжатие с потерями применял Никон в свое время (да и сейчас есть) в младших камерах. Ни грамма похожести на джпег там нет. Сжатие это основано на том, что ДД кропнутых матриц не так и высок, и реально больше 10 бит полезной инфы там почти всегда нет. Алгоритм сжатия Никона полностью раскрыт благодарю доступности исходников dcraw. Очень грубо говоря на выходе там получается эквивалент 9.5 бит инфы за счет сжатия информации в светах. Заметить разницу с несжатым NEF ОЧЕНЬ тяжело в обычных условиях конвертации, и можно ее найти только при серьезном подтяге пересвета.
Чтобы ответить на этот вопрос, нужно отлично знать механизмы работы с изображениями. У меня такой квалификации нет. Но, в принципе, для более сильного сжатия можно использовать малораспространенные алгоритмы. Типа тех же вейвлетов, хотя тут возникают серьезные вопросы насчет мощности процессора.
Да, если нужно подробно как это у Никона: Весь диапазон возможных значений от 0 до 2 в 12 степени - 1, разбивается на группы. Причем группы для малых значений (тени) состоят из одного значения, а группы для больших значений (света) включают несколько значений. И если сенсор выдает на выходе значение N, то в NEF файл пишется не N, а граница группы. Получаем, что в тенях нет сжатия, а для "светов" оно есть. Вместо 12 бит получаем 9.5 бит.
В общем у меня уже сейчас появляется предположение, что ничего хорошего от этого сжатого RAW ждать не прийдётся, видимо лучше уже сейчас позаботится о быстрых и больших флешках, к стати интересны новые флешки от Сони 300X, это если не ошибаюсь на уровне 4-го Сандиска?
10 миллионов пикселей по 12х3 бит. Т.е. 10 миллионов по 36 бит = 4,5 байта. Несжатый файл должен получиться порядка 45 мегабайт. Однако он менее 10 мегабайт, обычно 8-9 мегабайт. Использование никоновского алгоритма даст экономию порядка 11%. Очевидно, что используется другой алгоритм. RAR жмет 8-битный TIFF примерно до 12 мегабайт. 12-битный TIFF (буде такой существовал бы), жался бы еще хуже, до 16-18 мегабайт. Следовательно, перед использованием алгоритма сжатия, изображение должно подвергаться какой-либо реструктуризации, для улучшения степени сжатия. Или же используется комбинация алгоритмов: например типа никоновского + LZW-подобный. Хотя вполне возможно, что существуют другие типы алгоритмов, построенных на точном знании структуры матрицы и возможности работы с ее данными.
300 х 150 кбайт/с = 45 Мбайт/с. Если не ошибаюсь, то у Sandisk Extreme IV этот параметр порядка 40 Мбайт/с. Т.е. новая Сонька будет быстрее. Но тут надо смотреть еще на разного рода задержки при работе с флешкой, и, собственно, понимать, что такое х300 — скорость чтения, записи, или и то и то.
А! Так я неправильно понимал парамерт "пиксел"? Под пикселом что понимается — группа RGGB или один член этой группы? Я полагал, что 10 или 12 мегапикселов — это уже цветной пиксел RGB.
Ну главное теперь поняли ? . RAW - это данные с матрицы, 12 бит*количество сенсоров, на этом этапе это просто данные с RGGB массива, "цветными" они становятся только после байеровской интерполяции . Кстати, NEF, сжтый с потерями, имеет коэффициент сжатия 1.5, так для сведения.
еще семплы с ISO1600 (http://a700club.com/bbs/data/sample/DSC08091_resize.JPG) и ISO6400 (http://a700club.com/bbs/data/sample/DSC08092_resize.JPG). все более чем гуд на мой взгляд. цвета немного блекнут на 6400, но совсем чуть-чуть. ISO6400 шумодавится отлично.
человек с dpreview.com, владеющий Е-500 и 30D говорит что наш видоискатель на А700 чуть больше и ГОРАЗДО ярче, чем на его двух аппаратах. Это радует. И еще ему понравилась работа АФ. про хорошую скорость он аж большими буквами написал... http://forums.dpreview.com/forums/read.asp?forum=1022&message=24833414 блин. быстрее бы уже она в Москву приехала, эта А700. Покрутить ее в руках и подумать "брать А700 или ждать ФФ". А то я тут у Кена Роквела наткнулся на статью о преимуществах ФФ над кропом. Там так вкусно все про ФФ написано...
Ну наконец то добрадись до этого пункта А может ну его нафик, этот ФФ. Многие ли из нас зарабатывают фотосъемкой деньги? ИМХО для песронального потребления уже 6Мп на кропе 1,5 выше крыши. И А700 со своей ценой 1400 гульденов не больно то доступная тушка, плюс все остальные прибамбасы на сколько тянут Может подождать чего нибудь типа А500 (должно же что то на смену А100 появиться)? Пусть там не будет 12МП (хотя теперь уже вряд ли), не будет 2-го колесика, не будет исо 6400, ладно пусть верт. ручки не будет, пусть п.призму уберут, пусть один слот для памяти будет, не будет ИК пультика в комплекте, не будет выхода на ТВ, но что бы стоила 900-1000$? Реальная же цена после таких обрезаний. Самое главное чтобы все остальное от А700 сохранилось !!! Если такого чуда не произойдет, то лучше взять А700, ФФ все же кажеться нужон больше для профи.
У 12Мп 1,5 кропа тоже есть преимущества над 12МП ФФ, например, по ФР в некоторых случаях (кроп макро лучшее даёт - более близкое). Но при ФФ 24МП в кропе 1,5 на 12МП смысла конечно же нет! Если наш ФФ будет 12 МП, то я скорее всего возьму и ФФ, и А700.
не, нафиг-нафиг. мне в Д5Д как раз сейчас нехватает 2-го колесика, рабочих исо 1600, верт. ручки и светлой пентапризмы. и еще хорошего (быстрого и точного) АФ. В 700-ке это все есть и на меньшее я не согласен. Но ФФ мне интересен пока только в теории. Пока никаких очертаний новой ФФ Сони нет и не понятно сколько это все будет стоить.
а вот мне как раз эти безумные мегапиксели не нужны. Мне понравился сенсор в Никоне Д3. Я как раз ФФ с 24Мп не возьму.
Пытаюсь сообразить. Был уверен, что на 10-Мпкс матрице — 10 миллионов триад (или "квадрад"). Т.е. 30-40 миллионов фотодетекторов, группа которых (3 или 4 штуки) отвечает за один пиксел. Ну, примерно так, как это устроено с экраном монитора или телевизора. А тут получается, что на 10-Мпкс матрице всего 10 миллионов фотодетекторов? И 10 миллионов цветных (RGB) точек получаются пересчетом с нескольких соседних фотодетекторов?
