Версия для печати темы

Автор: Alekseyg 20.11.2004 - 21:35

Дмитрий, прочитал твою статью про поля - очень позновательно, спасибо.

В ней ты говоришь, что 3DSMax неверно считает поля. Если это так, то как же в нем вывести с нижним полем?

Автор: DimSUN 21.11.2004 - 12:21

Вероятно ты будешь удивлён, но то, что там вероятно неправильные поля я НЕ знал лет 6 и узнал об этом только полгода назад . Я начинал работать с полями ещё с MiroVideo DC30, она работала только с первым полем (first). Все проекты, что в Премьере, что в Афтере были тоже естественно же с первым полем (Upper, Top, First). Поэтому когда я начал работать в Максе, то после экспериментов с Odd/Even был выбран Even. Вот так и проработал 6 лет, не задумываясь переводе слова Even.

Потом у меня были Тарги и Матроксы (платы работающие с тем же первым полем) и всегда и я и мои коллеги везде, где я только знал работали в Максе с полем Even.

И только при написании этой статьи, я полез в словарь посмотреть перевод слова Even и упал со стула - НИЖНЕЕ!! Позже, я даже убрал эти названия из списка полей в статье (Top, First, Upper..)

В срочном порядке были проведены максовые рендер-тесты с полем Odd (ну раз Even - это по переводу нижнее, то выходит, что Odd должен быть верхним. Логично?) Все 4 разные платы у меня на работе работают с первым полем и везде такие максовые рендеры били строки - поля были явно не те.

Для полноты эксперимента, были проведены тесты такого материала и в Афтере (подробнее о методе читай http://www.dimsun.ru/forum/index.php?showtopic=17&st=11 и всё указывало на то, что в Максе поля указаны НЕПРАВИЛЬНО.

Хоть мне и раньше встречались такие программы с такими "ошибками", но
я на всяк пож забил тревогу на Форумах. Но.. как у нас водится с полями - народ как то дружно игнорил посты .

И всё же! Повидав много странного компьютерного на своём веку, я не могу со 100% уверенностью сказать, что я прав. Это должны подтвертить ещё несколько человек. Пока никто не выразил желания провести тесты и сказать кто из нас двоих не прав (я или 3ДМакс) .

Alekseyg

Я говорю - Odd. А вот в Максе написано - Even. Так что сам разбирайся теперь...

Автор: gvz 17.02.2005 - 08:52

Небольшая поправка насчет odd/even.

Even - это "четный" либо "правильный", а Odd соответственно наоборот; что непозволяет с полной уверенностью говорить о том какое это поле - верхнее или нижнее.
Т.к. если пользователь ведет отсчет от единицы, то программисты ведут его с ноля.
Если же используется второе значение этого слова, то все несколько проще.
для PAL, согласно стандарта, "правильным" является нижнее, а для NTSC - верхнее.

Другими словами:

1) еven не переводится как "нижний"

2) как правило, при наличии опции odd/even ничего нельзя сказать о том, что будет отвечать за нижнее, а что за верхнее поле (за исключением случаев когда это заведомо оговорено)

3) 3DSMax считает поля ПРАВИЛЬНО, как и любой другой софт который пользуется определением для полей odd/even.

Автор: DimSUN 17.02.2005 - 12:51

gvz
О как загнул...

Странно.... Вот ты сам и говоришь, что это чётный. А чётными числами являются 0,2,4.... Нулевой строки в телевидении нету (поэтому нолик мы отбрасываем, чтобы не парить мозги другим, ок?) , зато есть вторая строка.
Соответственно odd - это нечётный. Нечётными числами являются 1,3,5...
И вполне логично, что 1 - должна соответствовать первой строке в сигнале, а не второй (если вести отсчёт с нуля).


Сильно сомневаюсь, что это именно то значение, которым руководствовался Дискрит. Это получилось бы только запутыванием пользователей.


Зато в телевиденни нету нулевой строки и приплетать сюда этот ноль (а тем более чтото от него отсчитывать), я думаю совсем не стоит.


Нука нука... откуда такая инфа? Где есть такая спецификация, из которой получается что только 3DSMax правильно работает с полями, а весь остальной софт неправильно .

----------------
Фишка в том, что такого значения при рендере (odd/even) я кроме как в 3ДМаксе не встречал больше нигде, и поэтому сравнить не могу. Я знаю только, что материал посчитанный в Махе с even полями является материалом с доминирующим первым полем, хотя если судить из перевода этого значения, то поле должно быть вторым .

Автор: gvz 18.02.2005 - 12:03

для начала вот тебе мнение Криса Пирацци разработчика програмного обеспечения (SGI):

Avoid The Terms "Even" and "Odd"
These terms are ambiguous and terribly overloaded. They must be avoided or carefully defined where used.

"Even and odd" could refer to whether a field's active lines end up as the even scanlines of a picture or the odd scanlines of a picture. In this case, one needs to additionally specify how the scanlines of the picture are numbered (zero-based or one-based), and one may need to also specify 525 vs. 625 depending on the context.

Мне пришлось проработать с достаточным количеством программ видеомонтажа самого разного типа (и как пользователю и как тестеру, а в нескольких случаях и как разработчику) самого разного типа (от бытовых до профессиональных). Обозначение доминанты как оdd/even встречается достаточно часто, и если оно встречается, то может быть любым из перечисленных мною вариантов (возможно есть и еще, но таких я не встречал =)).

зы: насчет <"правильности" по стандарту> возможно я и перегнул, но то что такая рекомендация была это я помню точно. К сожалению доступа к рабочей библиотеке у меня сейчас нет, но кажется (могу и ошибаться) это было где-то в SMTPE170M. Если дома найду более точнуе ссылку, то обязательно сообщу.

Автор: DimSUN 23.02.2005 - 16:52

Именно так и переводится. Отсканирую словарь .

Кстати translate.ru http://www.translate.ru/dictionary.asp?lang=ru&mode=translate&word=odd&direction=er&psubmit2.x=25&psubmit2.y=15 ODD как "нечётный" (т.е. 1,2,5,7....)
Но 3DSMax при выставленном флаге ODD делает доминантным второе поле - чётное (2,4,6....).

Вот и разбирайтесь теперь

Автор: gvz 24.02.2005 - 06:37

Возможно в определенном котексте оно и может переводится как "нижний", но уж не в данном случае это уж точно.

Ты вообще читал мой последний комментарий к урокам ?
Не бери за аксиому то, что если ты привык считать с единицы, то значит все считается именно от нее (возми хотя-бы к примеру начало Декартовых координат, или ты считаешь что оно тоже начинается с единицы ?).
Для начала стоило бы прочитать пару-тройку стандартов по этому вопросу, заглянуть в потроха какой-нибудь либы по работе с ТВ-сигналом (хотя-бы в GNU-шный libDV который идет с неплохими комментариями), а не делать выводы на основе галочек в 3DМax-е и по их переводу со словарем.
Не считай что команда из нескольких сотен человек (программистов, тестеров и т.п.) глупее тебя.



В качестве оправдания: =)

Очень хорошая статья, на русском языке я пока-что лучше не встречал.

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

Позволю себе задать тебе один вопрос, он на мой взгляд схож с данной проблемой:
чему равны целое и остаток при делении (-5) на (2)

Автор: DimSUN 24.02.2005 - 10:41

Брэйк!
Я вовсе не хотел тебя обидеть, наоборот я даже рад, что всплыла возможность пообщаться с человеком, способным пролить свет на это тёмное обстоятельство... (я про Odd/Even)

gvz

Ну... я предпочитаю всётаки исходить сначала из наиболее очевидных вещей. В данном случае воспользоваться словарём для перевода было самым логичным решением (ИМХО конечно). Ни о каких математических расчётах я и не помышлял.


Да читал, но не стал там отвечать поскольку стало ясно, что беседа начинает приобретать "ярковыраженный характер Odd/Even" и решил, что разговор лучше продолжить в ЭТОЙ самой ветке.


Я исхожу только из соображений логики - от простого к сложному. Если честно, вся эта история с 3DMax меня сильно напрягает, я (и таких тысячи) и так постоянно борюсь с его ущербностью и несуразностью, а тут ещё добавилась чехарда с полями . За что просят 6 тысяч долларов?


Ну а хелп Макса по этому вопросу тебя не устроит?
The fields are referred to as Field 1 (F1) and Field 2 (F2); either could contain the odd numbered (1st, 3rd, 5th, and so on) scan lines or the even numbered (2nd, 4th, 6th, and so on) scan lines in the frame.
Вот здесь и указано, какие линии относятся к Even, а какие к Odd.
И если ты действительно прав (это я о том, что в данном случае Odd нельзя переводить как "нечётный"), то я вообще ничего не понимаю...


Да да.... точно точно.... эта та самая команда, которая, уже годами сложившиеся методы моделирования и анимации (в других 3D пакетах) сумела в Махе так испоганить, что народ пачками убегает с него в другие пакеты.


Так рассматриваю же. Просто неясно с какого боку ты притянул сюда этот ноль? И так ничего неясно, так зачем ещё больше запутывать...
Неее... если ты конечно абсолютно уверен в точке зрения Дискрита на этот вопрос, то тогда ладно, я просто поставлю ещё один жирный минус напротив этого пакета .


Издеваешься? Я не в курсе. Школу закончил давно, а высших образований мы не имеем... Подозреваю что "минус 2 с половиной" .

Автор: gvz 24.02.2005 - 13:56

Пришлося ставить Мах 5.0.... =)

Первое что я нашел в хелпе по полям было:
Odd/Even—Selects the field order of rendered images when the Render to Fields option is turned on in the render dialog. Some video devices require that the even field be first, other video devices require that the odd field be first. Determine the correct field order for your video device. If the video output of your device is strobing or appears jittery, it may be due to incorrect field order, try changing this parameter and re-rendering your animation.

Что в принципе ничему не противоречит.

Но потом (О БОЖЕ !!! от Дискрита я того не ожидал) я действительно нашел:
The fields are referred to as Field 1 (F1) and Field 2 (F2); either could contain the odd numbered (1st, 3rd, 5th, and so on) scan lines or the even numbered (2nd, 4th, 6th, and so on) scan lines in the frame.

Похоже им стоит сокращать свой штат. Они уже даже не знают какой у них движок на прощет полей стоИт (0-based || 1-based) =(

Кстати, я помню Мах только до версии 2.5 и могу сказать что в то время столь точного определения полей у них не было (впрочем, я и не искал =).

Ну да ладно, это их проблемы. Я же хотел сказать что при наличии терминов Odd/Even нельзя с полной уверенностью сказать какой из них является Upper, а какой Lower. Что и следовало бы указать в твоей статье. Либо просто избежать этого определения.

М/д прочим я тоже давно не студент 3-го курса =). Но считаю что любоиу композеру, математику нужно знать на твердую четверку, а то потом начинаются расспросы почему здесь Divide, а там Multiply, и чем Screen от Add отличается.

Забыл сказать насчет косяков. В случае полей в Мах-е это можно списать на опечатку, да и не сильно критична эта ошибка (не подумай что я являюсь поклонником этого продукта. могу даже добавить что до этого момента я лет 7 его не видел). Есть намного более ужасные ошибки (с моей, да и с математической точки зрения) в куда более известных программах на которые почти никто не обращает внимания. Например почти все из мной видимых программ измеряют котраст с ноля, а не с единицы, да еще и при полном отсутствии смещения (хотя последнее не столь страшно). Т.е. высокоуважаемые люди пытаются нам доказать что X*0 = X, а не нулю, как мы это привыкли ожидать =(.

зы: при целочисленном делении (-5) на (2) получается (-3)!!! и (1) в остатке (я не опечатался =), вместо предполагаемых (-2) и (1) в остатке. =)

Автор: DimSUN 25.02.2005 - 12:44

gvz

Скорее всего у них нету в штате консультанта по теледелам .


Укажу, ага...

Автор: Warwar 4.01.2006 - 11:47

Долбанный 3D Max. С долбанными полями.

Автор: DimSUN 4.01.2006 - 15:58

Шо? Опять?

Автор: Yan 22.09.2007 - 13:38

Здравствуйте! У меня один ламерский вопрос - раньше я рендерил и у меня проходил кадр за один раз, а сейчас, например, рендерю в canopus DV, он у меня за 26 проходов каждый кадр делает - от чего это зависит? Рендерер стандартный, макс 7.

позже: Нашел, это оказывается в настройках камеры на сцене было