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)
Ответ на: комментарий от Eddy_Em

и я превращусь в зомби

Так уже-ж. Думаешь увлечение заглотным коммунизмом проходит без последствий?

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

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

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

Очень трудно упихать в numpy поле в несколько сот Мб - оно рисуется нашим вьювером.

А в чём, собственно проблема? Если это многомерное поле — то вы всё равно рисуете его проекцию которую можно сохранить в массив. Если облако точек, то 10⁶-10⁷ вполне отрисовывается.

А есть еще векторные поля, мы их визуализацию только осваиваем но с ними будет совсем весело. Там наложение стрелочек на картинку, причем картинку то можно растягивать/сжимать как угодно а вот стрелочки нет - углы должны сохраняться.

Ну храните вы их же тоже на сетке или в меше? https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.quiver.html

Векторные поля, впрочем, гораздо нагляднее отрисовывать через streamplot.

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

не использую numpy.

Эта вещь-в-себе делает питон довольно шустрым, так что зря не пользуешься.

З.Ы. За сегодня как раз слопатил конвертор из npy (без сжатия, ага) в привычные уже рутовские файлы.

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

Если облако точек, то 10⁶-10⁷ вполне отрисовывается.

По моим ощущениям scatter plot в ROOT работает быстрее, чем в mlp. Дольше отрисовывать потом задумпленный постскрипт.

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

scatter plot

Если разные цвета не нужны, то обычный plot быстрее scatter — просто без соединительных линий и с однопиксельным маркером ",".

отрисовывать потом задумпленный постскрипт

ЕМНИП,

rasterized=True

Но, вообще (насколько я помню) ROOT же в ходу в основном у ФВЭшников, или где-то ещё его активно используют?

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

npy (без сжатия, ага)

Так голый .npy только один массив держит. Вот с неупакованным .npz бы мне научиться работать, в том плане что бы не копировать содержимое в оперативную память, а mmapать каждую zip-entry.

ROOT

На сайте пишут что там пайтон-интерфейс есть. Зачем поднадобился отдельный конвертёр?

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

Да почему не можете-то? Размер шрифта в гнуплоте задаётся. Размер картинки тоже (set size). Пересчитать его надо из гнуплотовских координат в пункты или сантиметры, но это один раз делается. Абсолютное позиционирование там делается, координаты можно задавать в graph или screen. То есть, положением всего, что есть на рисунке вы можете управлять. Ну да, надо это всё рассчитывать в обёртке или в самом гнуплоте.

P.S. Посмотрите GMT, там возможности настройки сильно побольше, чем в гнуплоте.

P.P.S. А какие журналы нынче позволяют такие сложные штуки с вёрсткой? А то крупные издательства понабрали индусов, латех ещё принимают, но конвертируют его в какое-то говно, в результате все детали и тонкости, которыми заморачивался в латехе идут лесом. Даже таблицы приходится вставлять как рисунки, иначе изгадят напрочь.

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

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

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

Прежде чем в журнал отдавать, статью полезно на arxiv выложить, а тут журнальные верстальщики не подмога.

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

На сайте пишут

На заборе тоже много чего пишут... Скажем так пользоваться этим интерфейсом можно, но крайне осторожно.

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

Ситуация несколько упрощается от осознания того, что про всё остальное можно забыть :( Утрирую конечно, но не сильно.

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

Скажем так (на правах наблюдений): относительно молодые экономисты владеющие статистикой как профессиональным инструментом знают, что такое R, потому что их этому теперь учат. Старики — это да, ничего вкуснее морковки и не кушали.

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

Дык я фэчист.

Хотя мода последних лет этот рут из анализа выкидывать. Хотя казалось бы, разрабы рута адекватные люди, им можно письма писать как и что исправить и ты ды…

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

У меня числодробилка на плюсах, в питоне я только графики рисую. А коллега вот питонист, он только npy умеет делать

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

Да нормальный он. В чем-то удобнее cling даже.

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

Учитывая то, что 99% рабочего времени я пишу что-то на С, изредка разбавляя это подсчетами в октаве, вообще не вижу смысла в пытхоне.

Ну и напомню о наркоманском синтаксисе поделия этого ненормального Гвидо! Плюс там наличествует ООПщина, от которой вообще невозможно избавиться!

В общем, не язык программирования, а кусок кала.

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

стоит ли препринт таких трудозатрат?

Каких трудозатрат? Ты тупо берешь свой латеховский файл и верстаешь его не в стиле своего журнала, а с более крупными буквами и в одну колонку.

Офигеть, «трудозатраты»!

Другое дело, что иногда не дают окончательный исходник с переводом, и приходится текст копировать из pdf. Вот тогда, конечно, намучаешься…

P.S. А журналы, которые принимают в «ворде», нужно игнорировать. Все равно от этих мурзилок тебе ни горячо, ни холодно! На «хирша» твоего они никаким образом повлиять не смогут! Разве что при защите кОньдидатского диссера помогут набрать груз ненужного хлама.

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

Эта вещь-в-себе делает питон довольно шустрым, так что зря не пользуешься.

Там где нужна шустрота я беру плюсы. Питону питоново… хотя я numpy использую для curve fitting, у меня даже утилитка хорошая есть;-)

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

Да почему не можете-то?

Потому что гладиолус. Если тики расставляются автоматом то выравнивание в таблице это в принципе итерационный, многопроходный процесс, как бы там чего не контролировалось. Я пока что очень смутно представляю как его вообще делать.

А какие журналы нынче позволяют такие сложные штуки с вёрсткой?

А они не сложные с тз журнала. Обычный latex с pdf-ками. Туда де тока ворд берут я стараюсь не писать. У нас под боком свой журнал, в РФ один из лучших по нашей тематике, но они от теха отказались лет 10 назад, это какой то позор… Мы туда теперь пишем только от безысходности.

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

В моей области знаний тот, кто статью пишет, тот и оформляет.

У нас иногда пишет кто то другой а финальную верстку делаю я - просто потому что умею. Особенно если лимит по размеру и нужно 16-17 страниц утрамбовать в 15;-)

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

С/C++/Fortran/«выберете своё» прекрасен, но с человеческими интерфейсами там беда, так что нужен клей, а сегодня стандарт для клея — это Python. Так что осваивать придётся по любому хотя бы со словарём. Другое дело, что кроме клея там много чего ещё есть.

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

Это уже «для души» aka для тех кто «любит красиво». По умолчанию самым заинтересованным является автор, а оформление это 1-2% от времени потраченного на написание статьи, так что нет особого смысла иметь выделенного человека.

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

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

Все тики и отступы там контроллируются

При выравнивании картинок в таблице это не поможет.

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

Эстетически это буэ, не надо так глумится над читателями.

Если это многомерное поле — то вы всё равно рисуете его проекцию которую можно сохранить в массив.

Далеко не любое даже двумерное поле лезет в обычный 2D массив. Например AMR не лезет, и есть еще много других структур данных которые тоже не лезут. Если мы говорим про 3D то там картинка генерится на GPU, и ни о каких проекциях речь не идет, там все сложно.

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

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

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

Выделенного человека у нас и нет, но вот ужать 16-17 страниц в 15 это не для души совсем а суровая необходимость. Если сказано что лимит 15 страниц а статья 17 страниц то ее банально не примут.

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

Вот с неупакованным .npz бы мне научиться работать, в том плане что бы не копировать содержимое в оперативную память, а mmapать каждую zip-entry.

дык пишете свой массив умеющий читать npz, делов то;-)

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

У меня числодробилка на плюсах, в питоне я только графики рисую.

В питоне еще очень хорошо делать интерфейсы (верхний управляющий слой) для числодробилок на плюсах.

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

с человеческими интерфейсами там беда

Что значит «человеческий интерфейс»? На мой взгляд ничего и не нужно, кроме вменяемого CLI.

А пытхон - это игрушка. Вот пусть школьники с ним и играются, в работе он не нужен.

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

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

Меня как-то раз по рукам побили за питон на годах системы сбора данных… Написал на баше.

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

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

По удивительному совпадению эти люди и руководят всем… Похоже, я делаю что-то не то в жизни.

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

Интерфейс для общения с человеками. Я ранее для этого perl использовал, но Python сейчас у perl всё выиграл, точнее perl заморозился и запах ☹ Есть надежда, что движуха в perl-сообществе пойдёт с тем, что Ларри Уолл официально от него отказался, но сейчас там костяк это старые администраторы, которые хотят только ещё сильнее всё там приморозить, включая уже найденные баги.

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

CLI это тоже интерфейс для общения с человеками и организовать удобный CLI средствами питона гораздо удобнее, чем C++ с одной стороны или bash с другой.

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

Numpy сам по себе вроде как то ли си, то ли плюсы, то ли вообще асм.

Да, но при сложении двух векторов нампая насколько я понимаю дергается виртуальная функция на каждую ячейку вектора. При сложении и умножении - две. Ну или на каждую операция в AST запускается отдельный цикл и создается временный массив с результатом, даже не знаю что хуже. Быстро (по сравнению с Ъ плюсами) это не будет.

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

Для чего угодно. Как уже верно сказал @Evgueni например CLI на питоне делается куда проще и прозрачней чем на плюсах. В таких задачах плюсы питоны сливают вчистую, как ни странно в т.ч. за счет сильной типизации.

У питона сейчас две проблемы:

  1. идет переход от v2 к v3 со сломом обратной совсместимости

  2. питон не очень дружит с MPI. Мне во всяком случае толком (для своих задач) их подружить не удалось, но я MPI юзаю редко.

В остальном, связка «интерфейс на питоне + ядро на плюсах» идеальна для большинства задач численного моделирования.

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

Интерфейс для общения с человеками

CLI, естественно. Разве что нужно картинки показывать, тогда лучше сделать веб-морду или на чистом OpenGL что-то набросать. Ну или над OpenGL взять Nuklear (недавно для себя эту header-only библиотечку открыл; классная, не то, что всякое говнище вроде Qt или GTK).

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

интерфейс на питоне + ядро на плюсах

Лучше тогда вообще пытхон выкинуть. Зачем этот инвалид? Интерфейс на крестах тоже легко рисуется. Попробуй nuklear, думаю, тебе понравится! Там все просто и прозрачно. И не нужно себе мозг насиловать идиотским синтаксисом или навязанной ООПщиной (даже там, где она не нужна). Я уж молчу об указателях и типах данных — без этих вещей вообще жить невозможно!!!

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

Интерфейс на крестах тоже легко рисуется.

Зачем его рисовать??? Я про CLI говорю, и про верхний управляющий слой.

Эдди, мы в неравном положении - ты писал только на Сях, а я и на Сях, и на плюсах и на питоне. Эдди, ты не прав;-)

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

лучше сделать веб-морду

Ну да и это опять же Python. В общем он везде, куда ни плюнь. Это довольно удобно в смысле не умножения изученных сущностей.

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

Тебе никто не мешает писать на любом ЯП, как на C/Fortran/«выбери для себя что-то дорогое и любимое». Вот особенно Fortran легко переносится в любую языковую среду ☺ И да, я не считаю что это что-то плохое, если программа работает.

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

Ну да и это опять же Python.

А вот и нет! Я веб-морды тоже на С пишу. И не понимаю, на кой черт сюда пытхон совать.

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

Немного, у меня весь CLI - это парсинг аргументов командной строки. А если нужен интерактив, то вот — я пользуюсь libreadline и libncurses. Для всяких демонов у меня сетевой интерфейс, просто при помощи netcat коннекчусь или из веб-морды.

У меня на гитхабе все есть, смотри, если хочешь.

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

Лично мне - не печально. Потому что С - очень простой язык и то, что пытхонист будет сутки писать, я за несколько часов накалякаю.

Eddy_Em ☆☆☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.