Dotaz: RawTherapee generuje purpurové fotky

[otula]

Přílohy:

• _MG_0174rt.jpg (703703 bytů)
• _MG_0174rt2.jpg (649210 bytů)

Chtěl bych se zeptat, zda někdo z vás netuší, kde hledat zakopaného psa v následujícím problému.

RawTherapee si kompiluji sám z gitu. Po některé z nedávných aktualizací systému mi ale nově zkompilované verze začaly barvit všechny fotky do purpurova. Zkusil jsem nainstalovat distribuční balíček, ten se chová správně. Zkompiloval jsem si sám stabilní verzi z PKGBUILDu pro distribuční balíček a barví také do purpurova. Problém tedy zjevně není ve zdrojácích k RawTherapee, ale v nějaké jiné součásti mého systému, která se při kompilaci zapojí do tvorby balíčku. Jak se dopátrat toho, kde je problém?

V příloze jsou 2 verze jedné fotky bez úprav - jedna z mnou kompilovaného RT, druhá z distribučního RT.

---

---

Odpovědi

[Gréta]

nóó a neni tamten pejsek takovej hežčejší s tim supr růžovým filtrem???????? :O :O :D :D ;D ;D

tady hele si myslej žeto dělá nepodporovanej foťák protože stará verze rawtherapee a tady podobnej vyřešenej problém s darktable hele :O :O jeto asi jako poměrně častej druch problémku dělání s *.raw  :O :O :O ;D

[otula]

Nepodporovaný foťák to určitě nebude A jestli chceš, tak se nech vyfotit, rád ti to vyvolám. Ale pohni, ať to stihneš dřív, než přijdu na to, v čem je problém

[otula]

Jinak u toho odkazu s Darktable řešili něco jiného - purpurovou v přepálených oblastech, to s tím mým problémem nesouvisí...

[T0nda]

Mne neco podobneho delalo u Nikonu s NEF, v podstate mas nejak rozhasenou kalibraci barev a misto cerne to tahne do purpuru. U ARW ani HEIC formatu mi to nedelalo. Ja uz nepamatuji co jsem nastavoval stejne to byla nejaka postarsi verze a mam dojem ze to vyresil upgrade. Zkus se zeptat na oficialnim foru https://discuss.pixls.us/c/software/rawtherapee .

[otula]

Mně to dělá úplně u všeho - CR2, ARW, X3F. Ale jak jsem psal, dělá to až u balíčků, kompilovaných po některé aktualizaci systému. Když nainstaluji dříve kompilovaný balíček, vše je OK.

[Pavel 'TIGER' Růžička]

Zkusil jsi hodit stranou původní ~/config/RawTherapee?

[otula]

Jo, ten jsem smazal. Konfigurací to určitě není. Nainstaluji git verzi kompilovanou 6. dubna, je to OK. Nainstaluji git verzi z 16. května, je to v háji. Nainstaluji distribuční stabilní verzi, je to OK, nainstaluji dnes kompilovanou stabilní verzi, je to opět v háji. Problém je v něčem, co jsem po 6. dubnu aktualizoval. Jenže od té doby mám v pacman cache kolem 800 balíčků...

[Pavel 'TIGER' Růžička]

Já bych zkusil porovnat závislosti mezi funkční a nefunkční verzí, třeba to nakopne správným směrem. Předpokládám tedy, že kompilace žádnou chybu nehlásila.

[otula]

Tak jsem vyzkoušel porovnat seznam knihoven, které vyplivne ldd, a oba seznamy jsou zcela identické. Kompilace se také tváří OK. Zkusil jsem RT sestavit na jiném počítači, problém je zcela stejný, takže to ani není něco, co bych si doma sám zmršil...

Navíc jsem si ještě všimnul, že to dělá jen u raw souborů, TIFF či JPEG jsou v pohodě.

[Bohatyr]

Ahoj. Mas moznost vyvolat v RT RAW z jineho pristroje? Kuprikladu z poradneho Nikona? :)

[otula]

Pokud je D610 pořádný nikon, tak ano. Dělá to to samé.

[Bohatyr]

Zkusil bych projet temata nize:

"https://discuss.pixls.us/t/purple-dng-rendering/8959" "https://github.com/Beep6581/RawTherapee/issues/4695"

[otula]

Obě témata řeší, že při převodu raw souboru do dng bylo povoleno Embed Fast Load Data. Tedy konkrétní vlastnost konkrétních souborů. Mně to dělá s jakýmkoliv neupraveným raw souborem v RT kompilovaném cca od letošního května. Tedy úplně stejné zdrojové soubory kompilované v březnu v aktuálním systému vyplivly RT v pořádku, na rozdíl od situace, kdy byly stejným postupem kompilovány v květnovém systému.

[Gréta]

akdyž bys jakoby zkusil zkompilovat nějakou starší verzi jestli by to taky dělalo tamten supr růžovej filtr?????????? :O :O

[otula]

Vždyť to píšu přímo v dotazu, že jsem to otestoval i na stabilní verzi, také to má supr růžovoučký filtr :-p

[otula]

A nemůže to být nějaká zmršená optimalizace kompilátoru? Typicky nové verze GCC mívají různě zábavné bugy. Pokud můžeš, zkusil bych RT zkompilovat starším kompilátorem nebo s vypnutými optimalizacemi.

[otula]

Dívám se na to, ale nic extra optimalizovaného v makepkg.conf nevidím:

#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

[MadCatX]

Už -O2 by mohlo stačit. V Archu už je GCC 10 zatímco distribuční RT bude asi ještě přeložená GCC 9. Minimálně jeden bug s příliš akční DSE už je pro GCC 10.1 nahlášený, takže se nabízí otázka, jestli něco podobného nenaboří i RT.

[otula]

Jo, přesně tak, po downgradu na 9.2.1 je to v pořádku. Děkuji!

[MadCatX]

Kdyby ses cítil dobrodružně, můžeš to zkusit s GCC 10.1 a přidat do CXXFLAGS -flifetime-dse=1. Předpokládám, že i vývojáři RT by rádi věděli, že tohle chování někde potřebují.

[otula]

Tak jsem to udělal a RT s tím zkompiloval… A co teď s tím?

[MadCatX]

Zkus to spustit a mrkni, jestli zase dostaneš ten sépiový odstín na RAWech. Pokud ne, stálo by to za bug report.

[otula]

Jo, to jsem zkoušel a purpurový odstín tam je.

[MadCatX]

Aha... no to byl spíš jen takový výstřel naslepo. Ještě bys to mohl zkusit úplně bez optimalizací. Na druhou stranu už jen informace, že s GCC 10 je to rozbité by vývojářům měla stačit k tomu, aby to vyřešili.

[otula]

Mrknu na to, jak se u nich hlásí bugy a pošlu jim report. Aspoň tak přispěji svou troškou do mlýna. Ještě jednou díky za odhalení zdroje problému.

[otula]

Ten výpis kompilace není moc dlouhý, tak se dívám, že je tam tohleto:

[ 11%] Building CXX object rtengine/CMakeFiles/rtengine.dir/dcraw.cc.o
In file included from /usr/include/string.h:495,
                 from /usr/include/glib-2.0/glib/gtestutils.h:30,
                 from /usr/include/glib-2.0/glib.h:85,
                 from /home/ota/abs/rawtherapee/rawtherapee/trunk/src/rawtherapee-5.8/rtengine/dcraw.cc:12:
In function ‘void* memcpy(void*, const void*, size_t)’,
    inlined from ‘int fread(void*, int, int, IMFILE*)’ at /home/ota/abs/rawtherapee/rawtherapee/trunk/src/rawtherapee-5.8/rtengine/myfile.h:130:16,
    inlined from ‘void DCraw::parse_makernote(int, int)’ at /home/ota/abs/rawtherapee/rawtherapee/trunk/src/rawtherapee-5.8/rtengine/dcraw.cc:5631:13:
/usr/include/bits/string_fortified.h:34:33: warning: ‘void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int)’ specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
   34 |   return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ono už to tam zřejmě bylo při předešlých kompilacích, ale nezastavilo se to kvůli tomu, takže jsem to bral, že je to v pohodě. Není to nakonec právě ten problém? Stížnost u kompilace dcraw by tomu docela nasvědčovala.

[ET]

co to zkusit s novym uzivatelem a cistym profilem? trebas to dela jiny ~/.config/*

[otula]

Konfigurací to není. A jak jsem psal, stejně se chová i RT zkompilovaný a spuštěný na jiném počítači.

[PetebLazar]

A co adresář ~/.cache/RawTherapee, byl jeho vliv mezi zkouskami různých buildů eliminovan?

[otula]

Ano, ano, vliv byl zcela eliminován, a na tom počítači v práci, na kterém jsem to dnes ráno zkusil, předtím nebyl RT vůbec nainstalován...

[Aleš Kapica]

No jo. Holt někdo ten zdroják vylepšil. Takové problémy totiž obvykle způsobuje třeba to, že někdo vyhodí funkci, která zdánlivě nic užitečného nedělá, "jenom" připočítává nějakou konstatní hodnotu.

Já s touhle aplikací bohužel nic nedělám, ale na tvém místě bych stáhnul git a postupně bych se vyzkoušel vracet, dokud bych nenarazil na funkční verzi. A pak bych hledal commit, který to vylepšil.

Vždyť sám v dotazu píše, že:

Problém tedy zjevně není ve zdrojácích k RawTherapee, ale v nějaké jiné součásti mého systému, která se při kompilaci zapojí do tvorby balíčku.

[otula]

To jsem si také původně myslel, jenže v tom je právě ten vtip, proč se zde ptám. Jak jsem psal, stejný problém se objeví i když zkompiluji stabilní verzi, kterou určitě nikdo nevylepšoval. Problém způsobuje nějaký jiný program, který byl od dubna aktualizován a podílí se na kompilaci. Nebo je možná v RT nějaký kousek kódu, který není úplně OK, ale projevilo se to až právě s aktualizací něčeho jiného.

[Aleš Kapica]

V takovém případě bych tedy vyzkoušel binární verzi z nějaké jiné distribuce a šel po verzích knihoven, které by s tím mohly mít co do činění. A nejspíš bych podezříval nejprve lcms2, když je to "Small-footprint color management engine"

[otula]

Hm, tak jsem zkusil zkompilovat starší balíček lcms2 a poté znovu RT, ale nepomohlo... Asi se na to vykašlu, starší verze RT mi fungují, dříve nebo později snad na tento problém narazí i někdo, kdo s tím má co do činění...

[otula]

A zkusil jsi to zkompilovat starší verzí GCC? To mi přijde jako nejjednodušší cesta k tomu, abys vyloučil, že je problém v optimalizacích gcc.

[otula]

Nezkoušel, vyzkouším :)

Ještě jsem testnul ten starší fftw, ale také bez vlivu. Uvidím, jak dopadnu s tím starším gcc.

[otula]

BINGO! Downgradoval jsem na verzi 9.2.1 (z verze 10) a je to OK. Děkuji!

[Aleš Kapica]

Případně fftw, protože ten posun barev by také mohl vzniknout při nějaké invalidní transformaci.