LINUX.ORG.RU

Veusz 3.0

 , , ,


5

4

Veusz — программа построения научных графиков (с качеством «готовое к публикации»). С графическим пользовательским интерфейсом. Может использоваться как модуль Python.

Мультиплатформенное приложение, работает в Windows, Linux / Unix и macOS. Поддерживает векторный и растровый вывод, включая PDF, Postscript, SVG и EMF.

Довольно мощная программа, развиваемая с 2005 года. Основной автор — Jeremy Sanders из the Max Planck Institute for Extraterrestrial Physics (MPE). Гораздо более гибкая программа в части построения графиков по сравнению со scidavis и labplot2.

В версии 3.0 появилась поддержка 3D-графиков.

Некоторые особенности Veusz:

  • встроенное руководство;
  • в полях ввода данных при построении графика может использоваться синтаксис Python;
  • форматирование надписей и подписей на графиках с помощью LaTeX разметки;
  • масса встроенных примеров.

>>> Полный список особенностей

>>> Скриншоты

>>> Примеры

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Veusz — программа построения научных графиков

Так называемая «наука» не нужна. Особенно с графиками. Изобретение западной цивилизации разврата и разложения, она только обслуживает общество потребления и будущую технократическую дистопию, её существование должно быть прекращено.

Вся необходимая человеку истина находится в Боге и в Природе.

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

Гм. Ну как бы нет. Это не абы кто, а топовые ученые с отличной наукой, публикациями в PNAS, Science Advances и прочих Q1. Просто у них уже свои выстроенные публикационные пайплайны, которые сложно натягивать на наш стиль работы.

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

Это не абы кто, а топовые ученые с отличной наукой

Видел я таких «топовых учёных». Одни просто идиоты (не буду показывать пальцем, а лично от меня кто надо итак услышал это), а другим наплевать на гигиену инструментария.

Просто у них уже свои выстроенные публикационные пайплайны, которые сложно натягивать на наш стиль работы.

Слишком политкорректно ты выразился. Это называется «осилили только Origin и не хотим нормальные инструменты, нам насрать на то, что мы делаем».

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

Я тоже использовал вначале qtiplot (аналог origin), пробовал SciDavis (форк qtiplot) и Veusz, но потом вдруг понял зачем все это если есть pgfplot? Для любителей TeXа, вроде меня, это оно самое. Делают численный файл графика в Mathematica и потом обрабатываю в pgfplot. Возможности у него огромные, получаются отличные картинки. Но проект поддерживаю, кому-то все равно покажется удобным, а значит работа была не зря.

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

он как минимум не обязан их отдавать тем, кто не купил у него лицензию на использование бинарника

версия 0.9.8.9 года 2011 эдак вполне себе лежит в виде исходников

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

Везёт, я под виндоус решил глянуть, но ни 2.2, ни 3.0 не запустились. Поиск ошибки вывел на 2 бага, которые до сих пор открыты и обсуждение ясности не вносит: то ли ему python 3.4 в системе подавай, то ли ещё что-то. А с какими зависимостями автор программы собирал бинарник, он не поясняет, а само приложение просто падает без каких-либо логов или собственных окошек.

grem ★★★★★ ()

с качеством «готовое к публикации»

Всегда удивлялся - почему все это ПО для построение графиков «для публикации» выдает такие стремные рисунки по умолчанию?

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

он как минимум не обязан их отдавать тем, кто не купил у него лицензию на использование бинарника

На самом деле обязан. У него лежит демо-версия, а следовательно всем, кто демо-версию скачал, он по уши стал обязанным. Он ещё на форуме Scidavis кричал, что делает всё ради опенсорса, всё ради людей, что его не так поняли и т.д.

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

Сейчас он не основной автор проекта и кода.

Не знаю что там было на форуме, вики только упоминает о каких-то разногласиях в целях проекта и способах его монетизации, после чего появился Scidavis.

Исходники qtiplot на самом деле никому не нужны, что можно видеть и на примере исходников scidavis - никто толком его не развивает, хорошо, что хоть мелкие баги правят ещё. Всё гораздо только кричать «даёшь исходники!».

А на примере тех же fbreader и coolreader видно, что больше всех переживающее за наличие «исходников» сообщество до сих пор не в состоянии сделать для первого двухстраничный режим просмотра, а во втором случае добавить простенькую каталогизации книг, взяв её пусть даже из первого. Стоит авторам переключиться на другой проект, так об открытых исходниках самые активные возмущенцы сразу забывают.

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

Сейчас он не основной автор проекта и кода.

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

Не знаю что там было на форуме

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

Исходники qtiplot на самом деле никому не нужны

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

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

зачем собирать, если есть бинарники?

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

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

Python умеет их через PyRoot. Если у оной вундервафли есть возможность вызываться из питона, то может пригодиться, а если нет, то к сожалению не нужно, как и любая интерактивщена :(

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

зачем собирать, если есть бинарники?

Затем, что бинарников нет.

толком не толком, а изменений там больше, чем в scidavis.

Ага. Дополнительные фильтры приколхозил разработчик.

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

Вроде нормально сглаживание там работает. Или на чём-то специфическом спотыкается?

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

Как нет бинарников, есть же!

Ну и чего тогда переживаешь? Бери и используй последнюю общедоступную версию.

Скорее всего алгоритм сглаживания косячит, если точки близко расположены или еще что. Нужно пример подобрать.

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

Вроде нормально сглаживание там работает. Или на чём-то специфическом спотыкается?

Вот пример ненормального сглаживания в scidavis. Ничего специфичного. Простая парабола построенная по набору точек x от "-5" до «5» с шагом «1». В обоих случаях включен антиалиазинг. Надписи о названиях программ и о границах добавлены в GIMP. Одна из них повествует о том, что видимой верхней и правой границы рамки на самом графике не было. Она таинственным образом появляется при экспорте, например, в png.

Оба графика приведены к одному виду.

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

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

Для построения графиков по уже готовым данным скорость не является хоть сколько-нибудь лимитирующим фактором. Питон де факто сейчас является безальтернативным клеем для C++ модулей (Fortran — это либо легаси, либо очень специфичные параллельные задачи, который опять же легаси), так что говорить, что анализ на python никто не делает является довольно глупой ошибкой (подсказка: это я рассказал как делается анализ в коллаборации ATLAS).

Строить ли итоговые графики с помощью cxx-скрипта или py-скрипта — это вопрос исключительно предпочтений конкретного человека/его настроения/предыстории.

Python более удобен в случае написания процедуры, которая выдаёт итоговый результат по одному запуску скрипта. А cxx удобен тем, что изначально его легко начать сбросив туда набор уже проверенной цепочке интерактивных команд ROOT, а потом долго сокрушаться когда оный безнадёжно разрастается.

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

Fortran — это либо легаси, либо очень специфичные параллельные задачи, который опять же легаси

Какой-то бред. Не знаю ничего, что так же легко и быстро работает с I/O как FORTRAN, и это качество вкупе со скоростью числодробления является определяющим во многих задачах. И почему HBOOK до сих пор лучше ROOT-а?

Питон де факто сейчас является безальтернативным клеем для C++ модулей

Поэтому его не используют в нормальных коллаборациях? ATLAS — это смешно, там питон используют полтора хипстера с подворотами. ALICE/CBM/SHINE/COMPASS/FOPI/HADES/MPD/BM@N - там такой херни нет.

анализ на python никто не делает является довольно глупой ошибкой

Анализ на python никто не делает и графики в своём уме никто им не рисует.

Python более удобен в случае написания процедуры, которая выдаёт итоговый результат по одному запуску скрипта.

Чем он более удобен? Тем, что постоянно не работает, требует какие-то модули и крэшится? Я как-то переписывал чужой пихонокод на обычный shell чтобы всё-таки задача выполнялась правильно: оказалось, что так получается быстрее и прозрачнее и работает не только на машине автора.

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

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

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

И почему HBOOK до сих пор лучше ROOT-а?

Это не так. Файлы, которые генерит HBOOK — это ужас-ужас-ужас. Для создания больших нтаплов следует принимать весьма нетривиальные действия без особых гарантий на успех. Раньше с этим проблем не было, но сейчас объём сохраняемых данных увеличился в миллион раз (оптимистично). Сложность структуры данных тоже серьёзно возросла и CERNLIB для этого давно не хватает. Несмотря на переусложнённость ROOT альтернативы ему сейчас нет.

Анализ на python никто не делает и графики в своём уме никто им не рисует.

Во первых и делает, и рисует — тому есть масса успешных примеров. Во вторых никто не мешает использовать ROOT для отрисовки прямо из python.

Тем, что постоянно не работает, требует какие-то модули и крэшится?

Скорее всего вы просто не умеете его готовить.

ROOT в интерактиве? Воу... Даже не знаю что сказать.

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

пока за сотню строк так и не вышла.

У вас либо очень простая и не нужная программа, либо вы чего-то не договариваете. Например, что данные до скармливания этой программе уже подготовлены. Просто рисовать графики — это легко. Сложно понять а) что нужно нарисовать, б) какие у того, что нарисовано, систематики и наконец, в) как эти систематики прикончить...

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

ROOT альтернативы ему сейчас нет

Ему нет альтернативы из-за странного решения вкорячить его во все фреймворки, которые только можно.

Во первых и делает, и рисует — тому есть масса успешных примеров. Во вторых никто не мешает использовать ROOT для отрисовки прямо из python.

В перечисленных выше коллаборациях не знаю ни одного.

Скорее всего вы просто не умеете его готовить.

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

но использовать его в интерактиве (ну или для запуска коротких скриптов) можно.

Можно, но не вижу в этом особого смысла. Разве что проверка на коленке записи в root-файл.

Например, что данные до скармливания этой программе уже подготовлены.

Конечно подготовлены. Правда всё равно программами на FORTRAN/C++ с использованием некоторых библиотек из поставки рута — разносить рисование и основной код это такой хороший тон.

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

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

Только если тебе не нужно построить 10 000 графиков в высоком разрешении и склеить мувик. Питон в этом плане и близко не стоял, gnuplot это наше всё

Fortran — это либо легаси, либо очень специфичные параллельные задачи, который опять же легаси

Далеко не легаси, просто очень специфичный.

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

Только если тебе не нужно построить 10 000 графиков в высоком разрешении и склеить мувик. Питон в этом плане и близко не стоял, gnuplot это наше всё

Согласен, что это отдельная задача, которая требует специалиpованных инструментов. Другое дело, что если инструмент грамотный, то его можно вызывать из Python. И да, я представляю что такое gnuplot и я с его помощью написал систему медленного контроля, которая каждые пятнадцать минут генерит тысячи графиков на протяжении уже более чем десять лет, но IMHO конкретно для анализа данных это неудобный инструмент.

Далеко не легаси, просто очень специфичный.

Специфичный тут фактически эквивалентен легаси, как и все эти оптимизирующие языковые компиляторы разрабатываемые 30+ лет.

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

Ему нет альтернативы из-за странного решения вкорячить его во все фреймворки, которые только можно.

Лично мне больше R нравится, но для анализа больших данных альтернативы сейчас нет и как бы особо конкретно не предвидится. Более менее универсального аналога просто нет.

В перечисленных выше коллаборациях не знаю ни одного.

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

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

Конкретно эта проблема не является специфичной для Python. Я наблюдал (да чё уж там и сам время от времени писал) ужасный код и на Fortran, и на C, не говоря уж о C++. Есть и более жуткие языковые примеры. Python тут особо не выделяется. Плохую программу можно написать на любом языке программирования.

Правда всё равно программами на FORTRAN/C++ с использованием некоторых библиотек из поставки рута — разносить рисование и основной код это такой хороший тон.

Зависит от ситуации. Анализ данных вещь временами крайне сложная и нелинейная. Часто удобно и полезно, чтобы всё выдавалось автоматически в результате работы одного скрипта. Максимум двух (собственно отбор данных выполняемый на гриде и анализ уже отобранных событий локально).

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

Специфичный тут фактически эквивалентен легаси, как и все эти оптимизирующие языковые компиляторы разрабатываемые 30+ лет.

Да, но на этом всё строится. Взять тот же BLAS.

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

как и все эти оптимизирующие языковые компиляторы разрабатываемые 30+ лет

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

Это у нас из-за провала в численности научных сотрудников среднего возраста из-за 90-x получилось так, что «ветераны» ещё помнят FORTRAN 77 (90 им было уже без особой надобности учить) и в лучшем случае немного модифицируют свой давно отлаженный код, либо достаточно ещё молодые, которые в институте скорее всего учили C и C++ (в МАИ, слышал в середине 2000-x был Фортран, но не знаю какой) и что-то дописывают к старому коду или пишут в целях изучения.

Но такая ситуация только на пост-советских территориях. В Западной Европе и США продолжают его активно использовать. Если бы это было не так, то и развитием стандарта не занимались бы.

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

Я не говорю, что легаси — это плохо. Если кто-то уже описал большую часть проблемы, то нет причин менять ЯП. Другое дело если что-то начинается с нуля.

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

Да и начинать с нуля нет ничего плохого: инструментов для разработки в том числе под не-x86 хватает, а подрубить можно и фортране код и на Си. Вон даже nvidia подвязалась не так давно.

grem ★★★★★ ()