формат векторной графики

Sat Aug 21, 2010 5:06 pm

Gluk wrote:тогда предлагаю так изменить формат битфилда параметров: 0 - нет параметра этого. ну, на нет и суда нет. 1 - есть параметр, и следующие 2 бита означают длину параметра.
При этом если на 7м бите указывается единица параметра, то длина указана в первых двух битах следующего байта, 8й при этом выполняет роль 8го бита следующего байта битфилда, освобождая тот 8й бит от его специального значения.
Если на 6м бите указывается единица параметра, то следующие 2 бита показывают, сколько впереди еще битфилдов кроме одного (т.е. 00 если только один, 11 если 4), и тогда во всех остальных байтах битфилда, кроме 4го дополнительного (ну, если было 11, в послденем из них) 8й бит ничего не значит специального, и они обрабатываются как обычно.
Во всех остальных случаях 8й бит установлен в 1 если есть продолжение битмапа в следующем байте, в 0 - если битмап окончен, а во всех оставшихся параметрах, если таковые возможны, нули.

Честно говоря, ни фига не понял

По-моему, проще чем "у них" не придумаешь: если параметры занимают от 0 до 62 байт - на размер отводится 6 бит, а если от 63 до 4Гб - тогда 32 бита. Даже если попался незнакомый тэг, парсер всегда точно определит позицию следующего.

-в предлагаемом формате размер _и_форма_ рисунка задается первым графическим объектом, который описан в файле, частота обновления не задается, так как не требуется для статики.

"Первый графический объект" в этом случае должен явно определять окно, иметь свой тэг, поле размера и 4 координаты. В SWF требуется только одна структура RECT

"2) Код разбит на тэг-блоки. Тэг создает объект строго определенного класса, используя для этого параметры только своего блока, с адресацией данных относительно начала блока."
-не вижу что это дает

1) Отсутствие перекрестных связей на низшем уровне (на уровне тэгов такие связи есть и оформлены как отдельные тэги)
2) Возможность независимого парсинга каждого блока с линковкой в один проход

-мой вариант без учета заголовка чуть ли не в два раза компактней будет, впрочем, дождемся результатов, обещанных Asper'ом

-я в предыдущих постах двух предложил указывать размер данных в битовом поле, от 1 до 4 байт, или, в случае огромных полей для рисования, строкой координаты указать можно. А так до этого еще не дочитал)

Допустим, надо определить окружность (простейшая фигура!) в поле 400х400 единиц. При 2-байтном формате для ее описания требуется 6 байт; при битовом уплотнении - 4. Прямоугольник требует 2 пар координат: 8 байт или 6 байт при уплотнении. Треугольник: 3 пары координат (12 байт против 8 ) и т.д.

Sat Aug 21, 2010 5:35 pm

art_zh, битфилды не только для этого. Они позволяют пропустить не только незнакомый тэг, но и незнакомый параметр. Они задают размер параметров, чтобы для координат, например, не использовать всегда 4 байта. И они показывают, какие параметры описаны (ведь они идентифицируются именно по их положению), а какие - нет. И все это плотно упаковано

Sat Aug 21, 2010 5:46 pm

Gluk wrote:art_zh, битфилды не только для этого. Они позволяют пропустить не только незнакомый тэг, но и незнакомый параметр. Они задают размер параметров, чтобы для координат, например, не использовать всегда 4 байта. И они показывают, какие параметры описаны (ведь они идентифицируются именно по их положению), а какие - нет. И все это плотно упаковано

"незнакомый параметр" при корректном тэге возможен только при сбое кодировки. Такие сбои могут быть только при ручном редактировании кода (в hex-редакторе) или повреждении файла, это фатально в любом случае.
Если байт-код кодируется макросами или внешним компилятором, таких сбоев не будет - все параметры должны паковаться корректно.

Sat Aug 21, 2010 6:02 pm

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

Sat Aug 21, 2010 6:33 pm

Gluck
Такие случаи легко разрулить
а) по номеру версии (уж парсер-то знает когда какая фича была в нём реализована);
б) по фактическому размеру блока данных;
в) по дополнительным тэгам, в том числе и самодельным.
Ведь никто здесь не говорил, что векторный парсер обязан обрабатывать только какое-то определенное подмножество какого-то определенного стандарта, и больше ничего.

Sat Aug 21, 2010 7:00 pm

art_zh,
замечу, что это я про свой черновик говорил (зачем еще битфилды, почему не тупо длина данных вместо них), а не про SWF (типа плохо что там такого нет. я такого не могу сказать даже по той причине, что не дочитал еще спецификацию по нему)
то есть я имел ввиду примерно следующее: "да, у них проще, но у меня на этом элементе помимо этой есть еще функциональность, потому усложнение оправданно"

Sat Aug 21, 2010 10:18 pm

art_zh,
""Первый графический объект" в этом случае должен явно определять окно, иметь свой тэг, поле размера и 4 координаты. В SWF требуется только одна структура RECT"
для того чтобы быть первым графическим объектом, объект должен быть:
-объектом;
-графическим;
-первым(из графических объектов).
то есть это может быть розовый полупрозрачный круг с ободком в виде зеленых черточек толщиной в три пиксела и нулевой прозрачностью. И он при этом нарисуется. И объявит при этом поле рисунка, заодно. В SWF к кругу потребуется дополнительно еще и структура RECT.

Sun Aug 22, 2010 2:09 am

Gluk wrote:... это может быть розовый полупрозрачный круг с ободком в виде зеленых черточек толщиной в три пиксела и нулевой прозрачностью. И он при этом нарисуется. И объявит при этом поле рисунка, заодно. В SWF к кругу потребуется дополнительно еще и структура RECT.

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

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

Конечно, я понимаю, этот самый первый тэг - он очень специальный, ради него вполне можно сделать исключение.
Только зачем?
Что мешает включить в заголовок компактную структуру RECT (минимум 2, максимум 17, реально 6-9 байт) и вообще забыть про "объект номер один"?

Sun Aug 22, 2010 9:50 am

"Что мешает включить в заголовок компактную структуру RECT (минимум 2, максимум 17, реально 6-9 байт) и вообще забыть про "объект номер один"?"
ничто не мешает, но лишает возможности задания формы рисунка

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

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

Sun Aug 22, 2010 10:53 am

art_zh,
"Допустим, надо определить окружность (простейшая фигура!) в поле 400х400 единиц. При 2-байтном формате..."
-стоп, я правильно понимаю что это окружность, занимающая все это поле? дыки тогда и радиус (200), и координаты центра (200,200) вполне умещаются в 1 байт каждый из размеров. Итого 3 байта против 4х?

Sun Aug 22, 2010 11:49 am

Gluk wrote:art_zh,
"Допустим, надо определить окружность (простейшая фигура!) в поле 400х400 единиц. При 2-байтном формате..."
-стоп, я правильно понимаю что это окружность, занимающая все это поле?

Нет, неправильно.
Я лишь привел примеры затрат на определение некоторых произвольных фигур в заданном координатном поле.
определить многоугольник = указать координаты всех его вершин;
для окружности - координаты центра и радиус;
для "горизонтального" прямоугольника (важный частный случай) - координаты противолежащих вершин.

Поле 400х400 выбрано в для сравнения двух методов представления координат.
В таком поле любой объект имеет только 9 значащих бит координаты. При Вашем способе кодирования для каждой координаты нужно отводить 16 бит, 7 из которых всегда будут нулями.
В SWF потребуется 9 бит на координату, плюс 5 бит на размер битового поля. Чем больше координат требуется для описания объекта, тем заметнее экономия места в параметрах тэга.

Sun Aug 22, 2010 3:10 pm

"При Вашем способе кодирования для каждой координаты нужно отводить 16 бит, 7 из которых всегда будут нулями."
-вовсе не обязательно. я уже привел в пример окружность, для кодирования всех координат которой требуется 3 байта, по 8 бит на каждую. Также, если даже прямоугольник будет, его координаты (4 штуки) будут занимать от 4х до 8ми байт в зависимости от его положения внутри области. 14 бит будут излишними лишь для координат точек, находящихся в пределах поля, размером (400-256)х(400-256) точек. еще в одной области (256)х(400-256) будут лишними 7 бит (от одной координаты), и еще в одной (400-256)х(256) - 7 бит (от другой координаты), в области 256х256 лишних бит не будет по обеим. То есть уже не ВСЕГДА 14 бит нули, а в заметно менее половины случаев ((400-256)^2 меньше чем 256^2). Поясняю еще раз, для хранения размеров от нуля до 256 используется только один байт, и все. О каких двух байтах ВСЕГДА речь?

Sun Aug 22, 2010 6:12 pm

Gluck
Вот оказывается как у Вас всё закручено - каждая точка имеет свои собственные поля формата координат (+4бита на каждую пару!!)
Но это не значит, что

если даже прямоугольник будет, его координаты (4 штуки) будут занимать от 4х до 8ми байт в зависимости от его положения внутри области.

Минимум 5 байт (4байта координат + 8бит полей размера), и то в самом лучшем случае, когда весь прямоугольник лежит внутри области 256х256.
Таких 5-байтовых прямоугольников будет 17% от всех возможных в квадрате 400х400.
Остальные кости упадут так: 6bytes - 38%; 7 - 32%; 8 - 12%; 9bytes - 1.7%

Для сравнения: в SWF-кодировке прямоугольник с 9-битными координатами в любом случае упаковывается в 5+4х9=41 бит

Теперь сравним оба метода на примере широкоформатной задачи: надо изобразить (допустим) карту звёздного неба - 20 тыс. пятнышек, разбросанных по простыне 16000х10000 пикселей, или 320,000х200,000 twips. У каждой звезды могут быть свой цвет, размер и форма, но нас интересует только кодирование их координат.

Сколько объектов попадет в квадрат 256х256 twips (2.5-байтовые координаты)? Ответ: НОЛЬ !
В полосах Х<65536 и Y<65536, находятся соответственно 20% и 33% всех звёзд, причем только 6% требуют 4.5-байтовой кодировки, остальные 49% занимают 6.5 байт. Ну и наконец 45% требуют 8 с половиной байт на пару.
ИТОГО: 142Кбайт для представления координат, из них 10000 байт используются только на кодирования размера данных.

SWF требует 5.125 байт (41 бит) на пару координат, или 100Кбайт на все объекты, при значительно более простом кодировании.

Sun Aug 22, 2010 7:15 pm

Извиняюсь за задержку.
Итак, поначалу пытался научиться рисовать в hex-редакторе, но надоело высчитывать битовые поля потому нарисовал в нем только квадрат 400x400 c толщиной границы в 5 пикселов (100 твипов) и прозрачностью границы 0.7 во фрейме тоже размером 400x400.
Потом взял Macromedia MX 6.0 и нарисовал всю картинку в нем по твоему словесному описанию насколько я это понял. (Кстати в байтовой кодировке этой картинки в твоем формате то ли у тебя ошибки, то ли я чего не так понял).

Полученный файл занимает в общем 302 байта, из них 20 байт в начале файла заголовок SWF.
Кроме того судя по всему в выходном файле ещё оказалась куча мусора (одинаковые стили линий и неиспользуемые стили линий и заливок), то ли вследствии того, что я несколько раз перерисовывал картинку пока получил нужный результат, то ли из-за старой версии SWF редактора (не зря же существует оптимизаторы флэш файлов).

Вобщем вот сам файл (1mn.swf), файл проекта (1.fla), дефлэш лог fltk-gnash (1mn.log), моё подробное описание дампа файла 1mn.swf (1mn bits desc.txt), правда не до конца, там уже думаю по спецификации разберёшься. Также в папке first то, что я нарисовал в hex-редакторе.

Sun Aug 22, 2010 7:23 pm

konstantin_666 wrote:Не спешите. Парсер байт-кода - это такая штука, которую нельзя реализовать "неполностью".
Для реализации флэш необходимо добавить в библиотеку парсера абсолютно все объекты, которые описаны в спецификации.
Самый компактный парсер флэша весит 4 Мб. Библиотека векторных функций для флэша займёт гораздо больше, чем 4 Мб.
Не говоря уже о других библиотеках...

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

формат векторной графики

Who is online