1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

RAW или сRAW? Вот в чём вопрос.

Тема в разделе "SONY с байонетом А", создана пользователем Коллаж, 8 июл 2009.

?

В каком формате вы чаще предпочитаете снимать?

  1. cRAW

    86 голосов
    55,5%
  2. RAW

    69 голосов
    44,5%
  1. действительно, шумность просто пипец ;)
    вот ИСО 1600 тыц при конвертации - люминисцентный шум -0, цветовой 25 (вообщем по дефолту).
     
  2. Господа, Коллеги....

    Да нет в cRAW никакого сжатия... Это же очевидно.... Там не сжатие, а количество записанных БИТ на канал... ХОть это нигде прямо СОНЕЙ не говорится, но мы то, извените, тоже соображаем... ДАвайте считать...

    А900.
    Простой RAW - 36Мбт
    Компакт RAW - 24Мбт

    Простейшая арифметика

    Итак в кадре из А900 содержится 6048х4032 = 24385536 точек. Умножаем на 12 бит на канал, получаем 292626432 бит с каждого кадра... Теперь делим на 8 = 36578304 байт, что собственно надо два раза разделить на 1024 и получить 34,8837890625 мегобайт... Вот Вам и примерный размер обычного РАВа... Ну ещё пара мегобайт на служебную информацию...

    А теперь всё то же самое, только не 12 бит на канал, а 8... Получаем 23,255859375 Мегобайта с кадра..., Опять же немного служебной информации .... Это и есть размер cRAW....

    Разницу между 8 и 12 битами на канал обсуждали немерянное количество раз... Как бы основная идея такая, что в принципе разница должна проявляться в большой степени при наличии сложных градиентных переходах и в частности при редактировании таких изображений... ОДНАКО!!! Вроде бы как никто так и не смог представить реального изображения с соответствующим экшеном в фотошопе, где разница между 8-ю и 16-ю бит на канал проявилось бы в реале.... Вроде бы сам Маргулис заключил, что разница эфимерная и обрабатыват и тем более хранить что-либо в 16(12 в нашем случае) битах не имеет смысла...


    Мой личный опыт также подсказывает мне, что никакой разницы между сRAW и RAW нет...
     
  3. гхм. откуда же оно тогда тянется при коррекции ошибок экспозиции? из 8 бит?
     
  4. Господа, ну оценивать шумы-то надо на одинаковых выдержках! А то у одного, может, 1/1000, а у другого - 1/15...
     
  5. А еще не мешало бы оценивать шумы на одинаковых объективах и объектах снятых в одном поле ;). Это все понятно, просто это уже размышления на тему кто/как/для чего юзает высокие ИСО...
     
  6. Fyarik, для полноты еще бы пояснить, почему RAW файлы одинакового размера, а cRAW - разного ...
     
  7. Ан нихрена... RAWы тоже отличаются по размеру.... Смотрите внимательнее...
     
  8. А что мешает тянуть из 8-ми бит?


    Я же говорю.
    Это вечный баян. 8 бит против 16 бит... Я слышал даже такую весч... Было объявлено вознаграждение за пример фактического практического влияния 16 или 8 бит на картинку. Никто ничего такого представить не смог и сошлись на том, что 8 бит фактически достаточно для любой коррекции... Никакой фактической необходимости в коррекции изображений (тем более в хранении) в 16-ти битах нет. Даже вроде бы Маргулис это именно и подтвердил...
     
  9. Дело в том, что СОНИ вообще ничего в инструкции про это не написала... Она ничего не написала про метод снижение размера...


    В любом случае сжадтие с потерей... (8 бит против 12 это тоже потеря)...


    Если сжимать РАВ на компьютере с помощью того же РАР, то получается как правило примерно те же 24-26 Мбт... То есть РАР это сжатие без потерь...У моего КОР2КВАД на 3,2 Ггц занимает 18 секунд на кадр.., Я конечно верю в технологии СОНИ, но не могу представить, что БИОНЗ может делать то же самое внутри камеры, но мгновенно... От сюда я могу сделать однозначный вывод, что ни о каком сжатии без потерь (аналог ЗИПа, РАРа и т.д.) речь идти не может...

    Моё объяснение самое правдоподобное.... Не правда ли? И самое логичное... Зачем изобретать велосипед? Самое логичное это просто записать 8 бит вместо 12.
     
  10. Не, ну о том, что сжатие с потерями помоему во всех спорах с этим соглашались, вроде и ссылки приводились где на листочках какую-то разницу днем с огнем еле нашли.

    Совсем другой вопрос, тупо ли режет он последние биты, или делает чтото более разумное. Скажем, таже конвертация в jpg качества 12 на моем компе (Athlon X2 4200+) занимает от силы пару секунд включая время на запись файла, а ведь при этом я верю в технологии СОНИ ;)
     
  11. Какой-нибудь простенький RLL-алгоритм способен неплохо сжимать графические файлы, а времени на работу потребует куда меньше, чем что-то типа LZW.

    Плюс к тому недорогая специализированная микруха способная работать над конкретными видами преобразований в разы быстрее, чем быстрый и современный проц, озабоченный, ко всему прочему, ещё и нуждами ОС и пользовательского интерфейса.

    Короче, на некоторых типах задач BIONZ вполне способен работать в разы быстрее какого-нибудь C2DUO. Так что тупо резать биты не обязательно. можно резать их умно.

    :)
     
  12. Всё правильно говорите... Но всё же даже при всём этом... При том, что в камере может быть специализированный процессор, который только и умеет, что сжимать соневские РАВы, при том, что ЦПУ в компьютере ещё и озабочен, как Вы правильно подметили, нуждами ОС и пользовательского интерфейса, всё равно, я не верю, что в камере можно сделать то же самое, что делают 4 ядра на частоте 3,2Ггц за 20 секунд... Вы учтите, что эта микросхема должна не только это делать быстрее в 200 раз, чем КОР2, но ещё и быть во столько же раз меньше по размеру и во столько же раз меньше потреблять энергии...

    Ну хрен его знает... Я в это не верю.... И моя справка о том, что я - лаборант программист, мне также верить в это не даёт.. ))))))))


    Да!!!! Тот же даблБИОНЗ умудряется сконвертить РАВ в джипег мгновенно, при том, что мой присловутый КОР2КВАД на 3,2Ггц делает это целых 3 секунды. Однако тут надо иметь в виду, что БИОНЗ может применять совсем иные алгоритмы нежели АДОБ КАМЕРА РАВ... Бесспорно БИОНЗ это специализированный процессор, который только и умеет что делать это конвертить РАВы... КОР2 умеет делать всё, что угодно... Мы все это понимаем... Но у КОР2 грубая сила, у него перевес в банальной частоте и количестве транзисторов, энергопотреблении наверное в 3-4 порядка... Тут хоть обосрись, как говорится.... БИОНЗ банально может халтурить... Он банально просто алгоритм конвертации берёт значительно менее трудозатратный... Те же шумы у БИОНЗА отвратительные получаются )))))))) Мы все это знаем...


    А сжатие без потерь - другое дело.... тут ничего не придумаешь. Либо ты это делаешь, либо нет..... Тут не схалтуришь... Нельзя сжать до того же размера при этом посчитать неправильно...


    А тупо отрезать лишние биты - фактически самый эффективный вариант. Он эффективен как в контексте вычислительных ресурсов, так и в контексте потерь... ФАКТИЧЕСКИ РЕАЛЬНО 8-ми бит достаточно за глаза... 12 и выше бит это пижёнство чистой воды.....

    Собственно, СОНИ сделало очень грамотно, мне кажется. Объявило, что у них РАВ 12-ти битный, чтобы ей на каждом углу всякие умники с форума ФОТО.РУ не тыкали этим обстоятельства, но при этом инженеры, осознавая чётко отсутствие какой-либо реальной необходимости иметь РАВ с разрядностью выше, чем 8 бит, сделали режим cRAW... При этом пойди - найди разницу... )))))


    Согласитесь.., Эта версия - наиболее правдоподобная...
     
  13. Ну я уже говорил...

    Самое разумное как раз, это отрезать биты... Это разумное во всех смыслах...
     
  14. #54 7 сен 2009 в 01:23 | RAW или сRAW? Вот в чём вопрос. | Страница 3
    Последнее редактирование модератором: 7 сен 2009
    Я тут скажу свое слово, как владелец диплома математика и системного программиста ;)

    Во первых, фотки этого бионза заставляют меня усомнится в том, что он действительно в 200 раз меньше по размеру чем проц Кор2дуо (учитывая, что сами "кристаллы" при этом реально еще меньше, чем весь проц вместе с оболочкой, ТЫц ).

    А во вторых, "специализированная микруха" может реально "жарить" в специфических задачах по сравнению с обычными процами стандартной архитектуры. Поинтересуйтесь например, технологиями вычислений на графических процессорах (архитектура Cuda например). На ряде приложений простая GForce 9600 за 4 тыри _легко_ уделывает любой современный проц (стандартной архитектуры) за 20тыщ, причем в 100 раз - легко, даже при КПД массивно-параллельных вычислений ниже 30-40%.

    Так что у меня нет сомнений в том, что если б тётя соня захотела, она б могла организовать чтото более мудреное в свой cRAW, чем просто обрезание битов. Но стала ли она это делать я не знаю. Никонисты, афаик, разницу между 12 битами и 14 битами (что подтверждено официально) разницы значительной не видят, так зачем усложнять казалось бы
     
  15. Fyarik, спасибо вам огромное. Улыбнулся так улыбнулся. ;)

    Сразу вспомнился Фоменко с "Альтернативной хронологией", а также сделанные по мотивам шутки "альтернативные цифр" и "альтернативная история войны в Ираке". Теперь вот будет четвёртая хохма "альтернативный RAW".

    Реально спасибо за хохму - теперь спать пойду улыбаясь. :)
     

  16. Уважаемый Кллега... Идитека вы в жо.....
    Если Вы такой умный, то, может быть, как-нибудь обоснуете свою весёлость? Если же Вы смеётесь без причины, то это признак слабоумия...
     

  17. Ну собственно про спецмикруху и её соотношение с ЦПУ всё понятно...
    Хотя не понятно... Всё же мне не верится... Та же 9600 питается от отдельного коннектора и просит БП от 350 честных Вт.... Ну или типа того... А этому гипотетическому процессору в фотоаппарате надо делать это сжатие "на лету" (4 ядра КОР2 делают это не 1, не 2, а 20 секунд) при этом она потреблять электричества в 300 раз меньше....... ... Ну да хрен с ней..... )))))))))))))))))))))

    Тут не в этом дело... Вопрос такой: на кой болт делать какую-то там МИКРУХУ, если можно просто округлить полученные 12 бит до 8-ми всё это дело записать в файл.... Проще и эффективнее не придумаешь... Ну конечно сжать без потерь было бы ещё эффективнее, но не проще уж точно...
     
  18. Fyarik, вам зря не верится. Специализированный проц, заточенный под решение вполне конкретной задачи, в наше время легко может жрать на два порядка меньше, а то и более, при этом работая на порядок быстрее. Пример из жизни, который у всех под рукой - MPEG-декодеры (DVD-плееры, мобилы, фотики).
    Сжатие CRW - задача вполне конкретная, в отличие от абстрактного сжатия без потерь, и под нее можно "заточиться", впендюрить в бионз отдельный модулёк и т.п.
    Если взять в качестве примера опять же MPEG, то используемое ныне в MPEG-4 AVC (h.264) сжатие CABAC не шибко-то бодро отрабатывается на архитектуре x86 (до четверти времени при декодировании!), зато в спецпроцах (под которые и было задумано) отдельный модулёк где-то на задворках кристалла работает "за копейки" и не жужжит :)

    Для увеличения эффективности сжатия могут чутка править битики, тут плюс один, там минус один. Именно по мере сжатия, а не предобработкой данных целиком. Вот и выйдет эффективность рар-а при высокой скорострельности.
    Причем жать можно в отдельном модуле этого бионза (кто сказал, что он не многоядерный?), в момент перевода данных их ОЗУ на флэшку, что вообще никак не отразится на производительности системы в целом.
     
  19. #59 7 сен 2009 в 08:29 | RAW или сRAW? Вот в чём вопрос. | Страница 3
    Последнее редактирование модератором: 7 сен 2009
    хорошо, простой экперимент.

    допустим jpeg и cRaw 8-битные. т.е. примем что грубо динамический диапазон jpeg'a и cRaw'a составляет грубо 8 стопов. так же допустим что стоп = удвоение экспозиции и каждый дополнительный бит тоже удвоение количества информации.

    фотографируем сцену в режиме dro off, cRaw+jpeg сцену с экспокоррекцией +2.
    грузим обе картинки в фотошоп с коррекцией экспозиции -2.
    если вы правы, кардинальной разницы в картинках быть не должно.

    ЗЫ. кстати, вопрос как программисту. почему в конверторах нет коррекции экспозиции больше чем на 4 стопа?
     
  20. Да нет... Это в общем не вопрос... Это на уровне эмоций ))))) :D


    А при чём тут, простите, динамический диапазон и количество БИТ?

    Количество БИТ влияет, грубо говоря, на количество возможных оттенков... А при чём тут динамический диапазон?
     

Поделиться этой страницей