Raw Therapee 3 beta Speed

[filosowe]

Hallo,

RT ist manchmal schon schrecklich langsam und man muss warten, bis sich mal das Bild aktualisiert.

Hat man Möglichkeiten, da etwas zu schrauebn? Das folgende Zitat bezieht sich auf V2, ich finde das so in der 3 nicht - oder übersehe ich etwas? Danke.

Wegen Speed: Du Kannst über dem Dateibrowser mit der Box wo 1:3, 1:4 1:5 usw drin steht die Vorschaubildgröße einstellen. Wenn du dort 1:3 stehen hast wird nur ein drittel des Bildes berechnet und dann auf den Monitor skaliert. Die vollen XX MPixel brauchst du eh erst beim export und nicht beim Einstellen der Belichtung.
Eine 100% Vorschau gibts wenn du da Detail-Häkchen anklickst. Aber auch nur Ausschnittsweise.

Wenn du Rawtherapee so nutzt wird es eigentlich sehr flott. Andere RAW Converter passen die Vorschaugröße wohl automatisch an.

 

[becksbier]

Die neueste Entwicklungsversion ist wieder schneller. Das "Problem" ist, dass man den Amaze-Algo bei 100% verwendet hat und der ist sehr langsam. Wenn du bei deiner Version unter "Raw" einen von den alten einstellst, sollte es schneller gehen. Abgesehen davon sollte man das Teil sowieso alle paar Bilder neu starten, da noch sehr buggy und nach wenigen Bilder kann es langsam werden oder gar nicht mehr korrekt reagieren oder gleich komplett abstürzen, OHNE die gemachten Änderungen gesichert zu haben.

 

[szal]

Abgesehen davon sollte man das Teil sowieso alle paar Bilder neu starten, da noch sehr buggy und nach wenigen Bilder kann es langsam werden oder gar nicht mehr korrekt reagieren oder gleich komplett abstürzen, OHNE die gemachten Änderungen gesichert zu haben.

Halte ich für ein Gerücht. Ich habe damit auch schon 20 bis 30 Bilder am Stück konvertiert, ohne Geschwindigkeitsverlust oder gar irgendwelche Fehler bemerkt zu haben. Klingt mir irgendwie nach zu wenig RAM und subsequenter Zuhilfenahme von Pagefile bzw. Swap.

 

[cncfraese]

Das vor- bzw. fertig kompilierte RT ist so langsam, weil es mit der Option zur Erzeugung von Debug-Infos kompiliert wurde!
Es wird erheblich schneller, wenn man es selbst kompiliert ohne diese Option.

Hier mein Script (unter Linux):

#!/bin/bash

DIR="${HOME}/rt"
[ -d $DIR ] || mkdir $DIR
hg clone https://rawtherapee.googlecode.com/hg/ rawtherapee # Only first time
cd ~/rawtherapee/ && hg pull && hg update && cmake -DPROC_TARGET_NUMBER=5 -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$DIR -DBINDIR=. -DDATADIR=. -DLIBDIR=. && make install




Stimmt, das kommt noch hinzu:

Das "Problem" ist, dass man den Amaze-Algo bei 100% verwendet hat und der ist sehr langsam. Wenn du bei deiner Version unter "Raw" einen von den alten einstellst, sollte es schneller gehen. ....

 

[szal]

Das vor- bzw. fertig kompilierte RT ist so langsam, weil es mit der Option zur Erzeugung von Debug-Infos kompiliert wurde!
Es wird erheblich schneller, wenn man es selbst kompiliert ohne diese Option.

Ich habe im Zuge eines Bugreports auch mal RT mit -DCMAKE_BUILD_TYPE=Debug kompiliert und konnte beim Ausführen keinen wesentlichen Geschwindigkeitsabfall gegenüber -DCMAKE_BUILD_TYPE=Release feststellen.

Hier mein Script (unter Linux):

#!/bin/bash

DIR="${HOME}/rt"
[ -d $DIR ] || mkdir $DIR
hg clone https://rawtherapee.googlecode.com/hg/ rawtherapee # Only first time
cd ~/rawtherapee/ && hg pull && hg update && cmake -DPROC_TARGET_NUMBER=5 -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$DIR -DBINDIR=. -DDATADIR=. -DLIBDIR=. && make install

Damit schmeißt Du allerdings die Quellen und das Kompilat in dasselbe Verzeichnis, was ich persönlich eher unelegant finde. Wenn Du Dir dafür sowieso schon ein Skript schreibst, kannst Du gleich auch die Ausgabeverzeichnisse ändern. Bei mir gibt’s dafür ein Verzeichnis ~/local/rawtherapee3-staging/ (das -staging ist Legacy von den ersten RT3-Builds), während die Quellen in ~/local/src/rawtherapee/ liegen.

 

[cncfraese]

Damit schmeißt Du allerdings die Quellen und das Kompilat in dasselbe Verzeichnis, was ich persönlich eher unelegant finde.

Das stimmt ja gar nicht!

Quelle in ~/rawtherapee/
Compilat in ~/rt

Sei versichert, dass dem so ist (steht ja auch so im Script)!

 

[szal]

Das stimmt ja gar nicht!

Quelle in ~/rawtherapee/
Compilat in ~/rt

Ok, ich glaub Dir das mal. Bin eh keine Leuchte, wenn’s um Shellskripte geht…

 

[becksbier]

Halte ich für ein Gerücht. Ich habe damit auch schon 20 bis 30 Bilder am Stück konvertiert, ohne Geschwindigkeitsverlust oder gar irgendwelche Fehler bemerkt zu haben. Klingt mir irgendwie nach zu wenig RAM und subsequenter Zuhilfenahme von Pagefile bzw. Swap.

Ich spreche aus Erfahrung, also kein Gerücht. Ich "pulle" alle 2-3 Tage den neuen Entwicklungsstand und teste den und zwar real, dass heißt mit echten Bildern und vielen Einstellungen/Operationen und 20-30 ist wirklich selten, meistens geht schon viel früher was kaputt, auch Sachen die man nicht sofort sieht, z.B. fehlende GUI-Updates bezüglich Schärfung bei 100%-Ansicht oder Lupe.

Das mit dem Debug ist natürlich auch richtig, hatte ich jetzt ganz vergessen, da ich das auch immer ohne übersetze.

 

[cncfraese]

Ich habe es grade nochmals ausgetestet.

Ca. 70 Bilder im Batch. Die Batchverarbeitung ist im Vergleich zu Bibble sehr langsam. Pro 10MB-RAW-Bild ca. 35 Sek. gleichbleibend und ohne Hänger oder Abstürze. RT Version von heute 3.1m1.11
In dieser Version ist der Bildaufbau und die 100% Ansicht extrem schnell im Vergleich zu früheren Versionen!

Die von Dir beschriebenen Probleme können durchaus von defekten Speicherbausteinen herühren, die sonst bei weniger speicherintensiven Anwendungen nicht auftreten! Wäre nicht das erste mal, dass sowas vorkommt! Entferne einfach mal die oberen 50% RAM Riegel....

 

[filosowe]

Halte ich für ein Gerücht. Ich habe damit auch schon 20 bis 30 Bilder am Stück konvertiert, ohne Geschwindigkeitsverlust oder gar irgendwelche Fehler bemerkt zu haben. Klingt mir irgendwie nach zu wenig RAM und subsequenter Zuhilfenahme von Pagefile bzw. Swap.

Also ich habe hier ein Windows 7 x64, 8 GB Ram und es ist mir zwar nicht abgestürzt, aber es dauert immer länger bis zum Bildaufbau (hatte den Eindruck, es exerziert alle Arbeitsschritte immer wieder von vorn durch). Also manchmal kam es dann, dass man mehr als 30 Sek. warten musste, obwohl unten in der Statusleiste "Ready" steht.

Ich nutze die hier:
http://www.rawtherapee.com/releases...MAP-RelWithDebInfo-3.0A2_1019-8466eb48c1e6.7z

 

[becksbier]

Ich habe es grade nochmals ausgetestet.

Ca. 70 Bilder im Batch. Die Batchverarbeitung ist im Vergleich zu Bibble sehr langsam. Pro 10MB-RAW-Bild ca. 35 Sek. gleichbleibend und ohne Hänger oder Abstürze. RT Version von heute 3.1m1.11
In dieser Version ist der Bildaufbau und die 100% Ansicht extrem schnell im Vergleich zu früheren Versionen!

Die von Dir beschriebenen Probleme können durchaus von defekten Speicherbausteinen herühren, die sonst bei weniger speicherintensiven Anwendungen nicht auftreten! Wäre nicht das erste mal, dass sowas vorkommt! Entferne einfach mal die oberen 50% RAM Riegel....

Ja, im Batch! Ich rede davon, dass man einzelne Bilder bearbeitet. Mein Rechner ist absolut okay. Gimp und alle anderen Programme ohne Probleme und das alte RT (2.4.1) schafft immerhin noch so gut 100 Bilder oder mehr (in Handarbeit ) bevor es sich unplanmäßig terminiert.
Aber ist ja auch kein Wunder bei einer Beta an der jeden Tag noch herumgeschraubt wird und die aus einer nicht stabilen Version hervorgegangen ist. Denke da wird sich erst was grundlegend ändern, wenn die Engine neu geschrieben wird, was ja "demnächst" der Fall sein soll, wenn ich das beim Überfliegen des RT-Forum richtig verstanden habe.

 

[szal]

Denke da wird sich erst was grundlegend ändern, wenn die Engine neu geschrieben wird, was ja "demnächst" der Fall sein soll, wenn ich das beim Überfliegen des RT-Forum richtig verstanden habe.

Ich bin diesbezüglich nicht ganz auf der Höhe, weil ich im Forum auch nicht alles lese. Aber ich habe neulich erfahren, dass es eine Kopie des Quellbaums von einem der Entwickler gibt, der den Code „aufräumt“; würde mich nicht wundern, wenn davon etwas in den Haupt-Quellbaum zurückfließt.

 

[becksbier]

Ich hoffe sehr, dass die da ordentlich aufräumen, denn RT ist mein Lieblingsprogramm (warum weiß ich selber nicht, hab' mich zumindest an die alte Version so gewöhnt, dass mich die teure Kaufsoftware nie wirklich überzeugen kann). Wenn die das demnächst mal wirklich stabil kriegen, ist es schon ziemlich weit vorne. Hier und da noch was gefummelt und dann (aber bitte erst dann!) noch ein paar Features reingestopft, und es spielt ganz oben mit und das als "Hobbyprojekt".

 

[maggusn]

Hi Leute,

ich hatte bis vor kurzem "nur" meine alte EOS 350D und war mit RT 2.4.x glücklich, absolut stabil, keine Abstürze und "normale" Geschwindigleit (habs aber nie in einem Rennen mit anderen verglichen).

Seit dem ich eine neue EOS 60D habe mußte ich zwangsweise auf RT 3.x umstellen .... und bin bisher ein wenig enttäuscht.

Der 3.0 Branch scheint zwar rel. stabil zu sein, ab ab und zu scheint irgendein "Filter" in der SW zu hängen, den Prozessor zu 100% auszulasten und mit etwas Glück nach einer gefühlten Minute fertig zu werden.
Das gleiche Bild mit den gleichen Settings ging aber vorher noch normal.

Die aktuelle Entwicklungsversion 3.1.x kann z.Z. überhaupt kein RAW mehr (stürtzt beim Öffnen des RAWs sofort komplet ab. JPGs öffnen geht problemlos.

Die Konvertierung scheint mir im vergleich zu 2.4.x eher etwas langsamer, könnte aber auch an dem oben beschriebenen Problem liegen.

Alles in Allem bin ich mittlerweile so weit das ich DPP in wine laufen lasse und hoffe das es nicht abstürzt (macht es manchmal :-().

UFRaw fehlt leider die Möglichkeit zu schärfen ... via GIMP gehen die Settings verloren ... will mir mal LightZone anschauen (kostet aber was).

Wenn RT sich nicht beeilt werde ich wohl umsteigen, obwohl ich mit RT und seiner Funktionalität glücklich war.

Auch so, laufe unter Suse 11.4 ...

Grüße
markus

 

[NandoHiller]

Hallo zusammen,
unter RawTherapee, habe ich ein Möglichkeit gefunden, die das Ergebnis erheblich schneller anzeigt. Die Engine einer älteren Beta-Version ist schneller. Die Vorschau beinhaltet auch Änderungen der Ausgabegrösse.

Ich habe die Geschwindigkeit anhand von gleichen 'simplen' Änderungen unter aktueller (branch default) und älterer Beta-Version (branch lanczos) verglichen.
older engine faster?

lanczos 4sek
default 9sek


Die Geschwindigkeitsvorteile erhöhen sich, wenn man die Ausgabegrösse des Bildes kleiner wählt. Ich benutze meist eine Bildgrösse von 1024x768. Um ein Bild in der gewünschten Qualität mit etwas mehr Einstellungen auszugeben, benötige ich bei aktueller Version von RawTherapee in dem Falle das 18-fache der Zeit. Das Bild unter RawTehrapee lancos wird in Bildgrösse 1024x768 berechnet und ausgegeben. Das Bild unter RawTherapee default wird in Bildgrösse 4000x3000 berechnet und in Bildgrösse 1024x768 ausgegeben.
resize (WYSIWYG)

lanczos 2s_________default 8s_________default plus 36s


RawTherapee lancos ist aber eine alte Beta-Version mit ein paar Fehlern. Änderungen in Schatten/Lichter werden nicht korrekt angezeigt. Wenn man aber ein Häkchen bei Qualität setzt, bekommt man das zu sehen, was am Ende ohne das Häkchen bei Qualität ausgegeben wird. Löscht man ausserhalb von RawTherapee Bilder aus dem Verzeichnis, in RawTherapee angezeigt, stürzt RawTherapee ab.

RawTherapee der aktuellen Version hat natürlich den Vorteil, dass es weiterentwickelt wird. Die Ausgabequalität soll auch besser sein.

Ich hoffe es hilft jemanden. Wie ist eure Meinung zu solch einem Rückschritt in der Geschwindigkeit?

bis dann,
Nando