LINUX.ORG.RU

Научная визуализация - масштабируемые графики типографского качества?

 , ,


0

2

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

Картинка обычно устроена следующим образом:

  4 +-------------+  +-+ 4
  3 |             |  |P| 3
Y 2 |   графики   |  |A| 2 Z 
  1 |             |  |L| 1 
  0 +-------------+  +-+ 0 
    0  1  2  3  4  
           X

В середине график, вокруг зарамочное оформление (чиселки на осях и метки на осях), сбоку опционально может быть палитра (обозначена PAL, если цветом рисуется функция двух переменных).

Дальше начинаются проблемы. Когда картинка вставляется в статью, она должна удовлетворять двум требованиям - шрифтовке и выравниванию.

Шрифтовка это типографское требование, шрифт на картинке должен совпадать со шрифтом в тексте но быть на кегль меньше. Естественно формулы/математические обозначения в метках на осях должны совпадать с текстом, быть красивыми и пр. В журналах как правило требования к размеру шрифту не очень жесткие, но шрифт должен быть визуально приемлемым - не слишком большим и не слишком маленьким. Самая печалька, что на графике тоже могут быть надписи (легенда, кривая какого цвета что значит), и они не должны пересекаться кривыми.

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

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

Поддержку LaTeX-а и правильную шрифтовку умеет делать например gnuplot в режиме epslatex - зарамочное оформление сбрасывается в .tex файл, график в .eps файл. Главный минус такого решения - если картинку начать масштабировать (это сложно, там размеры прибиты гвоздями наглухо, но гипотетически возможно) - то численные подписи к осям могут начать налезать друг на друга. Можно эту конструкцию сразу скопмилять в один .pdf (именно так я сейчас и делаю), но тогла при масштабировании поплывет шрифтовка, да и выравнивание превратится в лютый геморрой (в сложном случае) - понятно что размеры графика в центре при этом теряются. Подписи к оси X / палитру не отключишь.

Хочется некоторый формат для научной графики, отвечающий следующим требованиям:

  1. В файл сохраняются график, палитра (например в .png) + зарамочное оформление в формате (пределы по оси, метка к оси). Понятно что должна быть смотрелка для такого формата на экране.

  2. Есть утилита которая умеет из этого сделать например .png заданного размера с заданным шрифтом, чиселки вдоль осей она расставляет сама так что чиселки не налезают друг на друга. То же самое с подписями на графике.

  3. Та уже утилита умеет сразу сделать выравненную пачку картинок которые тупо вставляются в LaTeX таблицу.

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

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

@Crocodoom, @thunar, @Evgueni


UPD: сухой остаток после раздумий и обсуждения такой.

Можно сделать некий формат для верстки уже подготовленного изображения (т.е. понятно что рисовать и как рисовать, осталось нарисовать красиво). Бонусы в пользу такого решения не очевидны, но они есть - мы разделяем модель данных и представление. Формат должен быть простым и расширяемым.

  1. все что относится к картинке хранится в отдельной директории/tar/tar.gz/zip.

  2. система координат связана с графиком, все меряется в долях графика, (0,0) - нижний левы угол, (1,1) - верхний правый.

  3. текстовый файл axes описывает оси. Каждая ось это одна строка,

x0 y0 x1 y1 min max [logscale] подпись-к-оси

первые четыре числа координаты начала и конца оси на графики, дальше пределы, опционально логарифмический масштаб. Во всех подписях поддерживается LaTeX

  1. текстовый файл paletter задает палитру, в первой строчке
min max [logscale] подпись-к-палитре

во второй строчке сама палитра (цвета через пробел)

  1. изображение лежит в файле image.ppm или любом разумном графическом формате

  2. линии (кривые) лежат в файлах с имя.curve, каждая кривая в своем файле, первая строка #ключ-кривой, дальше в два столбца данные. Пустая строка означает разрыв в линии. Можно сохранять линии в бинарном формате.

  3. можно добавлять векторные поля и всяко разно.

Перемещено Shaman007 из development

★★★★★

Последнее исправление: AntonI (всего исправлений: 3)
Ответ на: комментарий от Evgueni

Как же скучно Вы живете… ;-)

Время на поиск решения простой задачи у меня как правило превышает время решения этой задачи самостоятельно.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

Это просто у вас под боком годного решебника нет :) Иными словами побеждает та среда, которая переманила к себе лучших техписов! Ну и доступность качественной документации и примеров это весьма весомый плюс.

В этом отношении я до сих пор считаю perl с его cookbook подобрался хорошо так к идеалу, но там Ларри Уоллу стало скучно и его понесло неведомо куда.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

Да нет, это я просто решаю быстро;-P

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

И? Вам надо иметь ширины символов [0-9], -+, \times и ещё +- с цифрами в верхнем регистре. 25 ширин. Причём делается это один раз. Или, действительно, считать ширину с помощью ghostscript, если время не критично.

JaM
()
Ответ на: комментарий от JaM

Это не так работает ЕМНИП, там еще есть отбивки. @Evgueni лучше знает потроха.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от JaM

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

Иными словами сделать хорошо можно, но сделать идеально вряд ли получится. Так что всегда будет нужен глаз со стороны который будет отлавливать (ну или закрывать глаза на) 1-5% косяков и исправлять их вручную.

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 2)
Ответ на: комментарий от AntonI

сравнить скорость разработки и число строк с питоном

Если ты не будешь пользоваться сторонними библиотеками (в т.ч. скрытыми сишными и крестовыми, которые используются пытхоном), то замучаешься парсер рисовать!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Evgueni

Я банально хочу это через тех прогонять. Кажется были какие то лайтовые решения

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Eddy_Em

то, что пытхонист будет сутки писать, я за несколько часов накалякаю.

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

(в смысле, пусть нам нужна быстрота исполнения кода)

the1 ★★
()
Последнее исправление: the1 (всего исправлений: 1)
Ответ на: комментарий от the1

Ты наверняка здесь имел ввиду какой-то самописный алгоритм с циклами?

Естественно! Если мне нужно тот же факториал один раз посчитать, я octave открою. А вот если нужно будет считать часто и много, то запилю что-нибудь свое.

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от AntonI

Повторюсь, в каждом журнале свои правила. В американских журналах, например, всё именно так, как я написал. Их не в латехе верстают.

yvv ★★☆
()
Ответ на: комментарий от yvv

обычно, в чём бы ты там ни набирал свою статью, верстает журнал всё заново, в своей системе.

Их не в латехе верстают.

Ты помнишь контекст? Речь о математике-физике.

the1 ★★
()
Последнее исправление: the1 (всего исправлений: 1)
Ответ на: комментарий от utf8nowhere

Лично меня не оставляет ощущения нестабильности и утечек. Сам root — это набор граблей для не сильно умелых «пограммистов» (целевая аудитория), а Python добавляет грабли детского размера.

Иными словами: это было просто брюзжание, а не конкретные указания.

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 1)
Ответ на: комментарий от thunar

Слишком всё сложно (C++ жизнь точно не облегчает) для простых пользователей особенно в ситуации когда алгоритм обработки не известен заранее и приходится быстро экспериментировать. Типичная большая программа в которой используется root полна утечек более чем полностью.

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

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 3)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.