Чем Linux полезен ЛА?

[Мегаоптик]

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

кернел =! дистрибутив.
после слаки философия редхата тяжеловато воспринимаеться, а уж фрибсд - этто вообще....
хотя некоторым нравиться...

Дык всё верно: пересаживаешься со своего любимого на другой дистрибутив - всё жутко неудобно, но разобраться можно, просто философия другая. А пересаживаешся на бздю и чувствуешь что нет, "этто вообще". Так вот сие потому, что другой кернел!

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

[tmc]

Посоветуйте ,операционку(ки) под FTP-сервер???

[Мегаоптик]

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

[kirx]

Посоветуйте ,операционку(ки) под FTP-сервер???

Легче сказать какую операционку не надо использовать - винду.
Потому что о удобствах компиляции всякого специализированного астрософта (типа iraf'а) в разных дистрибутивах и на разных *nix системах можно поспорить... Но вот такая мегастандартная веСЧ как FTP-сервер уж точно есть ВЕЗДЕ! Причём везде будет выбор из нескольких хороших (и как правило одних и тех же для всего *nix) программ ftp-серверов.
Лично я - фанат proftpd, но на вкус и цвет...

ОТ:прикольные у вас люди юзербары! Я тоже себе решил завести!

[lazyBSD]

Посоветуйте ,операционку(ки) под FTP-сервер

OpenBSD/FreeBSD/NetBSD

[biz_0n]

а есть программа под линух которая дружит с qhy5? и гидирование с поддержкой qhy5?

[lazyBSD]

нет

[Мегаоптик]

а есть программа под линух которая дружит с qhy5? и гидирование с поддержкой qhy5?

видимо ЛА писать самостоятельно нужно 

[biz_0n]

а есть программа под линух которая дружит с qhy5? и гидирование с поддержкой qhy5?

видимо ЛА писать самостоятельно нужно 

Не ну сейчас у меня просто знаний не хватит на такое, может кто есть программеры которые смогут это написать? и желательно опенсурс+фриваре

[Lantan]

а есть программа под линух которая дружит с qhy5? и гидирование с поддержкой qhy5?

сам лично не не пробовал, но вот свежая информация с форума qhyccd -
драйвера есть, и они уже в составе INDI, брать тут:
svn co https://indi.svn.sourceforge.net/svnroot/indi/trunk/indi-qhy

а вот еще оттудова:
.....
I am now guiding in linux using only open-source software:
http://code.google.com/p/open-phd-guiding/wiki/Screenshots

It requires:
OpenPHD: http://code.google.com/p/open-phd-guiding
INDI support for your mount (I'm using an LX200 compatible mount with pulse-guiding support)
My QHY5 drivers: http://code.google.com/p/linux-astro/


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

сам я тоже освоил автогидирование полностью под линукс, но у меня сетап попроще - EQ5 переделанная под управление через LPT порт, в качестве гида - Philips 900NC переделанный для длительных экспозиций по методу "tuc led" (светодиод на камере завязан на затвор камеры - не нужны никакие дополнительные LPT/COM хвосты - все через один USB), а в качестве гидирующего софта - QAstroCam, но я сильно поиздевался над ним, сделав сборку под Qt4, и добавил панель управления Canon DSLR.

[biz_0n]

складывал изображения в iraf и заметил одну вешчь: в центре ярких звёзд чёрные точки, ради интереса собрал их в ирисе и этих точек не обнаружил. Складывал командой :
imcombine @input stack combine=sum
может кто подскажет как с этим бороться?
и ещё вопрос, можно ли сложить изображения так, чтобы они не теряли цвет или нужно поканально складывать?

[SF]

Изображения с пикселами int16 вместо float32 ?

[biz_0n]

Изображения с пикселами int16 вместо float32 ?

Извините, не понял вопроса

[kirx]

Чёрные точки возникают в зависимости от того, как прога ведёт себя при переполнении числа. В беззнаковом 16-битном пикселе (самом стандартном) можно хранить отсчёт от 0 до 65535. А теперь попиксельно складываем два изображения, в которых есть пиксели с любыми значениями из этого интервала. Получается изображение с диапазоном отсчётов в пикселях от 0 до 131070. Правильные варианты действий (со стороны складывающей программы):
1)писать результат не в 16-битный массив а в 32 битный или в массив с плавающей точкой (float);
2)тупо не полениться поделить резултата на 2.
Не правильный вариант действий, который очевидно и реализует айраф - сложить и оставит как есть. При этом если к 16-битному числу 65535 прибавлять ещё немного и результат записывать в 16-битное число, получится что-то около нуля. Т.е. "счётчик" как бы сбрасывается и начинает считать сначала. Так и появляются тёмные пиксели с маленькими отсчётами в них.

P.S. Лично я совершенно не разделяю мнение что "iraf это круто". 

[SF]

P.S. Лично я совершенно не разделяю мнение что "iraf это круто". 

Вполне возможно, что iraf - это не круто, а полого, или даже совершенно горизонтально.
Но кроме него, MIDAS-а и STARLINK-а систем для автоматической пакетной обработки данных (open source + posix) пока ведь вроде бы нет? Или появилось что-то ещё?

[kirx]

P.S. Лично я совершенно не разделяю мнение что "iraf это круто". 

Вполне возможно, что iraf - это не круто, а полого, или даже совершенно горизонтально.
Но кроме него, MIDAS-а и STARLINK-а систем для автоматической пакетной обработки данных (open source + posix) пока ведь вроде бы нет? Или появилось что-то ещё?

Что iraf, что у midas - это совершенно точно, горизонтально! (про старлинк не скажу, сам не юзал)
Есть причина, почему midas и iraf не поддерживаются и не развиваются большшинством астрономического комьюнити, а последние годы существуют в основном за счёт фанатов которые работали на и над этими системами в молодости, а теперь им лениво переходить на что-то другое (и отлично, пусть сидят на чём удобно! плохо только если эти люди насильно подсаживают студентов на несовременную систему и стиль работы). Айраф и Майдас создавались в семидесятые-восьмидесятые-первой половине девяностых, когда возможности компьютерной техники были практически несравнимы с современными: и по железу и, главное(!), по софту. Действительно, если на дворе самый продвинутый язык - фортран, а для Си нет нормальных астрономических библиотек... В такой обстановки создание своей программной среды в которой можно производить арифметические действия с целыми изображениями(вах!), запускать специализированные подпрограммки, среды, в которой, наконец, будет просто удобная коммандная строка(!!) - не кажется таким уж безумием. Но те времена прошли, и что мы имеем теперь: iraf и midas - монструозные специализированные языки, требующие заментых усилий для их изучения и при этом не дающие той гибкости, какая есть у современных языков общего назначения (которые изучить ничуть не сложнее) в купе с обилием специализированных библиотек.
Может скажу немного упрощённо (т.к. у каждого свой стиль работы) но если перед студентом/аспирантом/учёным (астрономом, не программистом) встала задача "сделать что-то эдакое с FITS-изображением/таблицей" то:

• двадцать лет назад он стал бы писать что-то на майдасе (или в случае невозможности - на фортране и оформлять результат в виде модуля для майдаса)
• десять лет назад он стал бы писать на перле или IDL'е
• сегодня он стал бы писать на питоне

(Лично я делаю это на сях, но я не самый типичный случай).
iraf и midas - примеры систем, противоречащих философии *nix, что программа должна делать что-то одно, но делать это хорошо. Современный подход, к созданию систем автоматической пакетной обработки данных (ИМХО): это язык программирования общего назначения (питон, перл, IDL, C) + специализированные библиотеки (для чтения/записи FITS, всякой сложной матиматики) + набор из нескольких внешних специализированных программ которые делают что-то настолько сложное, что выходит за рамки библиотечных функций (как например SExtractor для распознавания объектов на изображении). Но, очевидно, созданная по таким принципам система будет делать что-то одно: делаем фотометрию - так мы делаем фотометрию, обрабатываем эшельный спектр - так обрабатываем эшельный спект. Потому и не появляется новых систем позиционирующих себя как способных сделать абсолютно всё, что нужно астроному: оказывается, астроному бывает нужно делать очень разные вещи...

[1212Lupus]

kirx, тогда назовите, пожалуйста, специализированную программу под Linux, которая делает нормальную (как в MiximDL, к примеру) фотометрию звёзд. Задача ведь специализированная. Просто никак не могу найти адекватной программы (бесплатной) для фотометрии... Под винду искать отчаялся, может хоть под *nix-системы есть...

[kirx]

kirx, тогда назовите, пожалуйста, специализированную программу под Linux, которая делает нормальную (как в MiximDL, к примеру) фотометрию звёзд. Задача ведь специализированная. Просто никак не могу найти адекватной программы (бесплатной) для фотометрии... Под винду искать отчаялся, может хоть под *nix-системы есть...

Тут есть моменты... Под линукс всё вообще другое, и в частности - стиль работы (я не говорю что для любых задач он лучше, он просто другой). Так что лучшая программа под линукс "которая как MiximDL" - это MiximDL запущенный под вайном. А хорошая программа для фотометрии под Linux - SExtractor. И при минимально грамотном использовании она делает фотометрию заметно лучше МаксИМа, потому как беспокоится о таких вещах как, например, горячие пиксели/плохие колонки попадающие в кольцо в котором определяется фон...
Но тут есть загвоздка - секстрактор по большому счёту не предназначен для обработки серий кадров. Он сделан для того, чтобы взять один кадр, найти и измерить всё что на нём есть, и сделать это без вмешательства человека. Что, конечно, очень круто, но не совсем то что нужно было мне как заядому переменщику. Мне как-раз нужна была обработка больших серий (и хорошо, что в автомате). Потыкавшись немного туда-сюда я тоже отчаялся и на основе трактора с помощью друзей написал свою программу VaST: ей можно искать новые переменные звёзды и измерять известные. Базовая редукция ПЗС изображений (дарк, флэт) - тоже там. Мне, как автору, программа кажется дико удобной и мощной , но многие кто пытался ей пользоваться этого мнения не разделяют.

[biz_0n]

Что iraf, что у midas - это совершенно точно, горизонтально!

так что это получается, под linux нет нормальных обработчиков астроизображения, если нужно что-то адекватное, то нужно это писать самому. Я понимаю что это настоящий linux way, но если у меня нет возможности самому написать такое приложение, то что тогда остаётся? А остаётся тот же iraf.
Мне интересно, а чем вы пользуетесь, если iraf и midas - горизонтально?

[kirx]

2 biz_0n
А какой функционал должен быть у программмы, чтобы она квалифицировалась как "нормальный обработчик астроизображений"?

Если нужно всё в одном флаконе и ничего что в неудобном - тогда да, это: iraf, midas, MaxIm. Если такая штука позволяет решать поставленную задачу - ну и отлично! Но это, ИМХО, действительно "не unix way".

Сам я пользуюсь разным софтом (и MaxIm'ом тоже) в зависимости от ситуации.

Вот для примера исходники трёх маленьких программок которые я использую для базовой редукции ПЗС изображений (в формате FITS, 16 бит, одно изображение в файле):
mk - складывание нескольких изображений медианой (чтобы сделать master-dark и master-flat)
ms - вычиталка изображений (для учёта dark'а)
md - делилка изображений (для учёта flat'a)
Чтобы скомпилировать эти исходники понадобятся библиотеки CFITSIO и GSL. Нужно переиминовать прикреплённые к этому посту файлы из txt в .c (умный форум не позволяет прикрепрять файлы с таким "странным" расширением)

Код: [Выделить]

mv md.c.txt md.c ; mv ms.c.txt ms.c ; mv mk.c.txt mk.c И скомпилировать их вот такими командами:

Код: [Выделить]

gcc -o mk mk.c -lm -lcfitsio -lgsl -lgslcblas
gcc -o ms ms.c -lm -lcfitsio
gcc -o md md.c -lm -lcfitsio
И всё, можно использовать хоть прямо из командной строки, хоть из скрипта, хоть как предлагает iLoveoOz - из менюшки наутилуса.

Естественно, ни у одного нормального человека нет возможности сесть и написать что-то масштаба iraf'а с нуля! Но написать какую-нибудь мааленькую недостающую утилитку для решения какой-нибудь мааленькой подзадачи. Связать несколько таких утилиток скриптом, автоматизирующем решение задачи вцелом... Вот это и есть "unix way"!
И нечего тут бояться!

(И ещё немного абстрактной болтавни в духе старика Столлмана)
Микро$офт развратил народ! И не чем-нибудь, а своей бизнес моделью. Виндой очень легко пользоваться и это сделало компьютер доступным любой домохозяйке (что есть очень хорошо!). Но при этом, под винду очень сложно писать программы. Это сделано сознательно, чтобы отделить "профессионального программиста" от "тупого пользователя". И на первый взгляд всё логично: действительно, ну зачем обычной домохозейке писать скрипты?! Проблемы начинаются, если вдруг эта домохозяйка в свободное от домашнего хозяйства время увлекается, например, обработкой FITS-изображений (или чем угодно, что выходит за рамки функциональности M$ Office). Из-за привычности этой майкрософтовской модели люди ждут, что умные "профессиональные программисты" напишут всеобъемлющий пакет, который удовлетворит всем их специфическим нуждам. Причём пересаживаясь с винды на линукс бедные люди ждут, что "профессиональные программисты" сделают это ещё и бесплатно. Естественно, многие разочаровываются.
В линуксе как правило приходится самому решать свои проблемы (если они нестандартные), для чего система предоставляет широкие возможности. А если нашёл решение какой-то проблемы и думаешь, что оно может оказаться полезным кому-то ещё - не жмись, поделись с народом! В линуксе грань между пользователем и программистом очень зыбкая. Не надо бояться иногда заходить на "чужую" территорию, просто стоит начать с чего-то маленького а не с собственного обработчика изображений на все случаи жизни.

Возвращаясь к теме... В линуксе нет "нормального обработчика изображений" потому, что за него никто не заплатил. Точнее заплатила NOAO и получился IRAF, заплатила ESO и получился MIDAS. Но по прошествии десятка-другого лет они поняли, что заплатить-то заплатили, а получили не совсем то, что нужно: недостаточно гибкую систему. И с тех пор предпочитают вкладываться в разработку библиотек и ПО под конкретные задачи на их основе. Динозавры типа вымерли. Вопрос о том, что делать простому ЛА на этом впечатляющем историко-культурном фоне остаётся открытым. Моя версия - потихоньку писать что надо и копировать у соседа, если тот написал что-то полезное.

Сорри за многабукф, тема задела за живое.