LINUX.ORG.RU

nufraw 0.42 + gimp 2.10-9 (-git)

 , ,


0

2

Вот, скомпилял ветку gimp-2.10 (поверх новых babl + gegl тоже из git). Для сборки по крайней мере gegl + gimp нужен уже хотя g++/C поновее, чем у меня были в gcc 4.8/gcc 4.9 — пришлось собирать с помощью clang 7 (который из пакета llvm, который нужен для mesa).

В общем после утаскивания кучи пакетов в сырцах от slackware-current и их сборки (там сейчас *.la файлы убили, а у меня они частично ещё используются — было весело, особенно с двумя libpng: 1.4 и 1.6) наконец-то получилось почти как надо. Собрал ещё nufraw (https://sourceforge.net/p/nufraw/blog/), теперь открывает разные raw и даже в 16-бит на канал. Но при этом автоопределение svg отвалилось, и если выбрать опцию сохранять exif в tiff — то полученный файл как бы имеет две страницы, но открыть можно только первую (по крайней мере в самом Гимпе), вторая судя по всему — метаданные.

Но в целом работает шустро, даже для 32-битного варианта, особенно если дать использовать 3 Гб памяти (максимум на 32-битной платформе).

>>> Просмотр (2880x900, 2275 Kb)

★★

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

Не думаю что кого то можно удивить свежим гимпом.

Но это ведь кде3. Не тде. КАК?!

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

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

crypt ★★★★★ ()

А ведь можно было просто поставить нормальный дистрибутив и свежий GIMP из репозитория

annerleen ★★ ()

даже для 32-битного варианта

а почему вообще 32? очень старый пк?

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

к сожалению, в мире линукс не существует «нормальных» дистрибутивов. у каждого свои проблемы.:(

crypt ★★★★★ ()

3 Гб памяти (максимум на 32-битной платформе)

А вот и нет.

mord0d ()

Дырку то до F16 пошто? Нет же ничего на переднем плане.

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

Ну именно в GIMP в настройках - выше 3 не выставишь :) Машина на самом деле новая -

lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD FX(tm)-4300 Quad-Core Processor
Stepping:              0
CPU MHz:               1745.497
CPU max MHz:           3800,0000
CPU min MHz:           1400,0000
BogoMIPS:              7600.31
Virtualization:        AMD-V
L1d cache:             16K
L1i cache:             64K
L2 cache:              2048K
L3 cache:              4096K
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd ibpb vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

KDE 3 таки с патчами из ТДЕ.

32-бита исторически сложилось, лень ломать/переделывать (ядро всё равно 64-бита, кстати 4.19.0 - но пока вроде кроме моей глупости фс никто не ломал).

Собственно, я не гимп как таковой показывал, а скорее nufraw, про который как мне кажется мало кто знает.

Andrew-R ★★ ()

Видел твои мучения на IRC :)

Оригинальный UFRaw вроде одно время генерил TIFF, где в один слой пихал мини-превьюху. Уже не помню, что было дальше с этой багофичей.

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

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

ЯННП. Зависимости слишком новые что ли?

AP ★★★★★ ()

Для сборки по крайней мере gegl + gimp нужен уже хотя g++/C поновее, чем у меня были в gcc 4.8/gcc 4.9

Летом штатного компилятора из 14.2 еще хватало для сборки нового gegl + gimp 2.10 (правда опыт из 64-битной системы).
С тех пор все успело так сильно поменяться?

bormant ★★★★★ ()
Ответ на: комментарий от Andrew-R

KDE 3 таки с патчами из ТДЕ.

to Andrew-R

KDE 3 таки с патчами из ТДЕ

добрый день/ночь! поделитесь инфой/патчами (любой возможной информацией)

или оставьте свои координаты для связи (если это возможно)

спасибо

п.с. я так понял вы собрали натуральные KDE3 на Slackware-14.2 current?

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

возможно, эта багофича переехала в nufraw по наследству. Но он в отличие от Darktable/Rawtherapee qt5 и прочего нового не хочет, а довольствуется gtk2.

Так вроде товарищ, от которого соньковские ARW пришли свежесгенерённый ГИМП'ом tiff нормально открыл, правда не знаю в чём.

Andrew-R ★★ ()
Ответ на: KDE 3 таки с патчами из ТДЕ. от sunjob

Re: KDE 3 таки с патчами из ТДЕ.

Нет, это скорее Слакварь между 2006-ым и -current :) Но больше конечно между 13.37 и -current. Я какое-то время назад собирал под свежеустановленную 14.1-32bit но там часть фич отвалилась (предпросмотр pdf завязанный на старый poppler-qt3).

https://cloud.mail.ru/public/8dSj/RLp6BfJwq https://cloud.mail.ru/public/2qyx/1G1ugjttj https://cloud.mail.ru/public/AceD/ftGj6ckVN https://cloud.mail.ru/public/JU7D/CwTFfN6kM https://cloud.mail.ru/public/DgvD/Cp4y8dstd https://cloud.mail.ru/public/Mywp/caM1kcxcq https://cloud.mail.ru/public/Jyv8/TwuLp1zjM https://cloud.mail.ru/public/5bBo/Y5arjJ8Nu

НО там нет qt3 slackbuild-а

Andrew-R ★★ ()
Ответ на: комментарий от bormant

у меня нештатный... gcc 4.8.5 (обновлять целиком всё на 5.x + пока не хочу. Но видимо придётся ..). Стандартная 14.2 должна собирать норм, если есть поддержка с++14 (gegl стал её хотеть например только в нерелизнувшейся ещё версии 0.4.13. Но поскольку гегл без гимпа для меня малоприменим ... вопрос в простановке правильных CC , CXX для каждого пакета)

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

Нет, это скорее Слакварь между 2006-ым и -current :) Но больше конечно между 13.37 и -current

ну вообще запутался! дело в том, что КДЕ3 б.м. нормально собираются максимум на sl13.37 а далее...увы...

Я какое-то время назад собирал под свежеустановленную 14.1-32bit

есть надежда, что на sl14.1 собирется?

у меня нештатный... gcc 4.8.5 (обновлять целиком всё на 5.x + пока не хочу ... и далее бла-бла-бла

если не сложно, оформите в виде статьи эти старания :о), надеюсь, сообществу пригодиться

спасибо

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

есть надежда, что на sl14.1 собирется?

Надежда всегда есть, но лучше проверить... Запущу на днях виртуалку, всё равно хотел пересобрать kdelibs для 14.1. Вот собственно по причине несборки кед я и остался на старой слаквари, к которой только ручками (slackbuilds, checkinstall) нужные в тот или иной момент времени компоненты и доставлял ...

Правда, временами приходится запускать что-то вроде

#!/bin/sh

find /usr/lib -name "*.la" -exec sed -e "s:-lpng14:: ;
s:/usr/lib/libpng14.la::" -i \{\} \;

!/bin/sh

find /usr/lib -name "*.la" -exec sed -e "s:/usr/lib/libgdk_pixbuf-2.0.la::" -i \{\} \;

Ну и патч на гимп, который хак (без него просто нажатие на Импортировать для tiff созданного самим gimp-ом из вот таких вот импортированных через nufraw изображений приводит к ошибке, вручную если выбрать первую страницу из предложенных двух - всё ок)

diff --git a/plug-ins/file-tiff/file-tiff-load.c b/plug-ins/file-tiff/file-tiff-load.c
index 724a0b7..07285f7 100644
--- a/plug-ins/file-tiff/file-tiff-load.c
+++ b/plug-ins/file-tiff/file-tiff-load.c
@@ -176,6 +176,7 @@ load_dialog (TIFF              *tif,
     {
       const gchar *name = tiff_get_page_name (tif);

+
       if (name)
         gimp_page_selector_set_page_label (GIMP_PAGE_SELECTOR (selector),
                                            i, name);
@@ -255,6 +256,7 @@ load_image (GFile              *file,
       guint16           orientation;
       gint              cols;
       gint              rows;
+      gint             length;
       gboolean          alpha;
       gint              image_type           = GIMP_RGB;
       gint              layer;
@@ -274,6 +276,10 @@ load_image (GFile              *file,
       const gchar      *name;

       TIFFSetDirectory (tif, pages->pages[li]);
+// my hack for loading exif'ed tiffs from gimp if selector left in defalt state
+
+      if (! TIFFGetField (tif, TIFFTAG_IMAGELENGTH, &length))
+       continue ;
       ilayer = pages->pages[li];

       gimp_progress_update (0.0);

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

залез в своих закрома, оказывается я уже собирал с вашими скриптами под sl14.1, не все так радужно... с тех пор что-то изменилось, скрипты/патчи менялись/дозатачивались?

попробуем еще раз набег сделать :о)

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

Скрипты дозатачивались (версии на yandex disk) НО например с libpng 1.6 я ещё ничего не пересобирал .... грабли обещают бить.

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

если успешно соберете на sl14.1/14.2, пожалуйста, отпишитесь в «личку» куда ни-будь (по моему, мы уже с вами пересекались где-то на др. форумах, ну и на вс. случай я вам на почту написал <blah-blah-blah>andrew-r<at>ru)

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

....я был уверен, что адрес где-то в профиле. Но там написано «виден только вам и модераторам». Можно randrianasulu_dog_gmail.com использовать (хотя к сожалению моё мыло разработчику nufraw так и не дошло, похоже.. что-то с принимающей стороной)

Andrew-R ★★ ()
Ответ на: комментарий от AP

обсуждали уже. ты видишь, что человеку llvm пришлось собирать? неужели еще какие-то вопросы остались. ты как считаешь, это обычный способ установки для обычного пользователя? во всей этой пачке связанных с gimp'ом проектов линкуемся с той версией, что мы из git стянули, когда нам в голову пришло код написать. бампимся по каким-то своим непонятным правилам.

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

как я уже писал, разработчики вообще не знают целевую аудиторию. в результате удобнее всего устанавливать последний снапшот под виндой.

и про флатпак можешь не говорить. он далеко не везде работает, что бы там ни думали его авторы.

crypt ★★★★★ ()
Последнее исправление: crypt (всего исправлений: 1)

чем только не пытался проявлять raw'ы, а удобнее AdobeCameraRaw не нашел.. =(

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

Для «вообще незнакомой» целевой аудитории планируется со временем добавить сборки в AppImage. Andrea Ferrero понемногу дотачивает свой сборочный скрипт под требования апстрима. Надеюсь, Жеан доберется до него к следующему релизу гимпа.

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

RAW-комбайны

Bibble Labs         / Bibble Pro / [win/mac/linux]
ребрендинг:         
After Shot Pro2     / Corel      / [win/mac/linux]
                    
- Apreture          / Apple      / [mac]
- Light Room        / Adobe      / [win/mac]
- Capture One                    / [win/mac]

ACR - можно отнести, к так сказать: Stand-Alone-tool

- Nikon Capture NX  / Nikon      / [win/mac]
- ACR               / Adobe      / [win/mac]
- Raw Photo Processor            / [mac] 

Bibble/After-Shot - великолепно работают на линухах, ко всему еще и нетребовательные к рессурсам

для потока, все же ACR - ни как не годится, работа в таком случае сродни набору команд в терминале, хотя для одиночного кадра/два/десятка - ACR весьма хороша, но с др. стороны, все тоже самое можно делать значительно быстрее и удобнее в «комбайнах»

про цвет/оттенки/тон белого платья невесты - спорить вообще беЗ/Смысленно, профи рулит на любом инструменте :о)

у свадебщиков/рекламщиков - в основном как раз Aperture/LR

для «потока» (естественно с отменным качеством) - единственный выбор именно «комбайны»...

к стати, для ручного «теребоньканья и макс. качества» - попробуйте RPP

p.s. есть еще куча других, весьма не плохих конверторов, но они, как-бы, немного не в тренде :о)

p.s.2 LR - это GUI для ACR

p.s.3 удачи :о)

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

у свадебщиков/рекламщиков - в основном как раз Aperture/LR

Ну да, понимаю. Апертура. Закрытая Эпплом. С последним релизом в 2014 году.

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

дык и чЁ? кто запрещает использовать-то? великолепная тулзятина :о)

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

p.s.2 ...и это был комментарий для DILIN :o)

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

дык и чЁ? кто запрещает использовать-то?

Только если твоя камера выпущена до 2015 года. И то не факт, что всякая.

В общем и целом, я не вижу смысла в сабже (nUfraw). Как только в 2009 году вышла самая первая версия darktable, я забил на UFRaw и Rawstudio. А теперь, когда и darktable, и RT работают как плагины гимпа (если уж прямо ну очень надо), оживлять этого покойничка вообще никакого смысла. Ну разве что никаких сил слезть с 32-bit нет.

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

И то не факт

не факт - что «не факт»

в своей апертуре я работаю со всеми ПОСЛЕДНИМИ «шестерками», «пятаками» и «еденичками» (путем несложным махинаций руками и головой, что-то вообще напрямую) - это «основной парк рабочих прошек», в смысле не у меня а «вообще у народа» :о) ни кого ни в чем не убеждаю, все остальное халивар, не относящийся к теме... и это тоже уже становиться злостным халиваром :о)

по поводу ненужности - у всех свои «карандаши», не дело обсуждать это в ТОПИКЕ, где автор решает свои проблемы, делится информацией, обсуждает именно «свой-данный аспект/проблему/тему»...

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

давайте, все-таки, больше не флудить... кланяюсь, всем спасибо :о)))

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

flatpack или appimage - какая разница применительно к топику? еженедельные статические билды и то были бы более здравым решением. паковали бы их в deb/rpm/tgz и все. так нет же, надо извратить с flatpack и appimage... когда руки дойдут.

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

appimage - это и есть практически тот же статический билд, только без всего гемора, неразрывно связанного со статическими библиотеками

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

flatpack или appimage - какая разница применительно к топику?

Принципиальная. Аппимиджи как правило собирают на базе LTS и в статике.

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

appimage - это и есть практически тот же статический билд, только без всего гемора

да, и я об этом же. только мы с тобой, видимо, под гемором понимаем разное. для меня установка-распаковка из deb/rpm/tgz куда-нибудь в /opt как раз простой способ. appimage же еще надо «завезти» на какой-нибудь слакваре или centos 6.

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

Распространяется и запускается как один файл (руками делаешь chmod +x только).

По желанию пользователя устанавливает .desktop для быстрого запуска из рабочей оболочки.

В принципе, есть дельта для обновления до новой версии (но пока не видел, чтобы кто-то юзал).

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

appimage же еще надо «завезти» на какой-нибудь слакваре или centos 6

Скачал один файл и запустил, куда уж проще

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

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

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

главное, наверно, не требует root-привилегий? иначе установка deb/rpm одним кликом в «проводнике» делает тоже самое: инсталирует, добавляет .desktop file и репозиторий для проверки обновлений.

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

Нормальным пацанам достаточно интеграции в $PATH

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

и про флатпак можешь не говорить. он далеко не везде работает, что бы там ни думали его авторы

Согласен. Флатпак - это вишенка на торте. Лично мое мнение - флатпак начинается со сборки под Linux Standard Base. Собрали gimp-bin.tar.xz, проверили на ubuntu 14.04, centos 7 - норм, можно делать flatpak.

Для тех, кто не понял, я не призываю использовать gcc4 и древние версии специальных либ. Наоборот, нужно максимально формализовать окружение, зафиксировать версии либ и компиляторов, сколь угодно свежие, настроить CI, опубликовать скрипты сборки. Все это собирается и запускается на c7 и ub1404. Как это делается, вообще-то, по-нормальному.

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

главное, наверно, не требует root-привилегий?

Именно так.

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

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

https://gitlab.gnome.org/GNOME/gimp/blob/gimp-2-10/configure.ac:46

настроить CI

https://build.gimp.org/

И на CircleCI сборка для мака делается, адрес не помню.

опубликовать скрипты сборки.

https://gitlab.gnome.org/GNOME/gimp/tree/gimp-2-10/build

AP ★★★★★ ()

Эти шрифты с засечками

Фу.

StReLoK ☆☆ ()
Ответ на: комментарий от Andrew-R

Машина на самом деле новая
AMD FX(tm)-4300 Quad-Core Processor

Как бы тебе помягче эту печатную машинку охарактеризовать?)

// Кстати, что там у GIMP с OpenCL ускорением?

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

Мое почтение за ответы.

Если не ошибаюсь, то воспроизвести сборку поможет непосредственно

https://gitlab.gnome.org/World/gimp-ci/jenkins-dsl/blob/master/vars/gimpBuild...

+

https://gitlab.gnome.org/World/gimp-ci/docker-gimp/blob/master/debian-testing...

Дженкинс всё усугуляет, конечно. Он делает всё очень непрозрачным, слишком он монстроузен.

Народу надо подключаться, кто заинтересован, и клепать типовые окружения для статический и/или bundle сборки на debian-jessie/centos7 или типа того. После этого, все проблемы у массы людей, кто хочет самого свежего гимпа, и у кого проблемы с flatpak, исчезнут. Ну это я так вижу, по небольшому собственному опыту.

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

Кстати, что там у GIMP с OpenCL ускорением?

Оно есть, но прицельно этим уже не занимаются, поскольку на целевой платформе (Linux) с этим довольно уныло в плане драйверов.

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

Да, репозиторий правильный.

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

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

Максимум, что наблюдал — приходил какой-то наш соотечественник, который хотел помочь с CI. Но у него бомбануло от того, что мы не хотим переезжать на гитхаб и дела проекта обсуждаем на IRC. В общем, ничем это не кончилось.

AP ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)