D70, ёмкость буфера - разъясните дураку...

Оговорюсь сразу - на какчество снимков не влияет, вопрос, наверно, чисто риторический, но всё-таки интересно - чего я тут, дурак, не понимаю?
При качестве изображения Fine, Normal или Basic ёмкость буфера при выбранном размере изображения Мedium (M) вмещает в себя меньшее коликчество кадров, чем при размере Large (L), при том что размер файла при "М" меньше почти в два раза - что за чертовщина? Казалось бы, что должно быть наоборот. Как этот ларчик открывается?
Заранее благодарю.

так что jpeg - нефотография, и законы физеки на него не действуют фф пятьнецу

Так ведь в уик-енд тем более. Что-ж теперь, ждать до понедельника?

Цитата:

от:ValmaN
Оговорюсь сразу - на какчество снимков не влияет, вопрос, наверно, чисто риторический, но всё-таки интересно - чего я тут, дурак, не понимаю?
При качестве изображения Fine, Normal или Basic ёмкость буфера при выбранном размере изображения Мedium (M) вмещает в себя меньшее коликчество кадров, чем при размере Large (L), при том что размер файла при "М" меньше почти в два раза - что за чертовщина? Казалось бы, что должно быть наоборот. Как этот ларчик открывается?
Заранее благодарю.

Подробнее

У меня на минолте а1, серия в jpg состовляла 3 кадра, а в raw 5 кадров. Смею предположить, что камера занимает буфер, на такие операции как уменьшение размера и компрессия.

Тогда почему при размере снимка Small (S) количество помещаемых в буфере кадров больше таки (как и напрашивается), чем при L и M? Что здесь сжимать и обрабатывать не надо? Не понимаю ... Так где же собака зарыта, кто знает?

А что, таки никто и не знает?

Ну нудник я - так что-ж? А с ответом на вопрос помочь слабо???

а почему бы вам не спросить у самого Никона ?

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

Фотошоп тоже из 3008х2000 делает 1504х1000 быстрее, чем 2240х1488. У меня комп древний (селерон 766).
Так вот в два раза уменьшает за 2,32 сек, а до 2240х1488 за 3,41 сек.
Наверное из-за этого и буфер медленней очищается в М режиме.

Спасибо.
Но Вы привели факты, а почему это ТАК происходит, вот в чём вопрос :!:

так у вас МЕДЛЕННЕЕ или меньше ЁМКОСТЬ?

да сравнивалось кстати с Large.. которое не требует дополнительного машштабирование.. ну видимо товарищь который песал праграму прагуливал арефметеку в 3 класе, где учут in-place машштабированию

Вопрос сформулирован в самом начале. Речь идёт о ёмкости буферной памяти. При размере снимков "L" она (буф.пам. то бишь) вмещает в себя большее количество снимков (кадров, файлов - как хотите, так и называйте), чем при размере "M", но меньше чем при "S". Мне показалось это странным и непонятным.
Ну и ладно, снимать это никак не мешает, а плохо - тем более.

так лезем фф спецыффекацыйи.. и штош там написсанно

Large 3008 x 2000
Medium  2240 x 1488
Small 1504 x 1000

так вот small ето ровно половина.. и видимо было невлом зделать по нормальному ибо ето елементарно.. так а что же такое 2240*1488.. а ето 0.75 похоже.. а гляньте ка границы кадра одни и теже на medium и на large? если на medium чуть больше срезаеться то ето ровно 0.75..воттутвот видимо аффтара и проломало на in-place.. добавить в буффер пару строчек на разгон.. а если ето не ровно 0.75 то тем более проломало. и алгоритма быстрого уже не бывает.. да и для фиксированного 3/4 он уже не такой быстрый как для 1/2 или 2/3

А что, разъяснение таки впечатляет.
Я, инж. стр. по специальности, в кибернетиках как и в термоядерных физиках разбираюсь одинаково хорошо, и в чём отличие двуричной системы от десятичной, как и В.И. Чапаев: "...квадратный трёхчлен? - не только описать, даже представить себе не могу, тов. профессор" и поэтому осмеливаюсь предположить, что из вышеизложенного я понял, что медленный алгоритм преобразует обрабатываемый файл в больший по размеру а посему и вмещается их меньшее количество в тот же объём памяти - или я опять чего-то не понимаю?

нет файл меньший по размеру
но
алгоритм в принципе медленнее. быстрое масштабирование на 0.75 преобразует 16 пикселей (4*4) в 9 (3*3) . каждые идут со своими коэффициентами если нарисуете две сетки увидите. коэфф. соответствуют площади перекрытия пикселей результата и исходника. хорошо пойдёт только на процессоре с неслабым кол-вом регистров.
чем больше знаменатель и чем меньше регистров тем быстрее алгоритм вырождается в масштабирование общего вида (совсем медленное если оно качественное)

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

а масштабирование пополам просто прибавляет к пикселю ещё 3 соседних и всё. результат может быть положен точно на тоже место и значительно быстрее.

не знаю что там они тормознули у меня в D7D вообще одинаково 9 во всех режимах что raw что jpeg.. хотя может просто больше 9 не показывает

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

Самое интересное, что размер буфера в режиме "М" равен 7 при любом качестве сжатия FINE. NORM, BASIC
В остальных режимах он увеличивается с увеличением сжатия (в режиме "L" соответственно 9,12,19 в "S"= 19,27,49 )

S можно делать сразу из RAWа и сразу уменьшить требуемый размер памяти
что M меньше L вот ето реально странно.

по идее масштабирование не сильно по принципу работы отличается от скажем внутрикамерного шарпа.

Моя исключительная признательность за обстоятельный ответ и введение в основы программирования. Где-то забрезжил свет в конце тоннеля для меня, вполне возможно, что при хорошем учителе и ученик не совсем д-к. :D
Теперь можно снова идти спокойно снимать, абстрогируясь на природе от алгоритма и несчастных пикселей.
Спасибо.