Neue Testversion 15.40b7

[SCX]

Klingt für mich immer noch plausibel. Je RGB-Ebene etwa 4MB Speicher, macht bei 46 Ebenen etwa 180MB - wenn die Ebenen alle gleich groß sind... PSE braucht doppelt so viel Speicher, wäre dann pro Ebene das Zwischenergebnis gespeichert. Nicht gekapselte Gruppen sind sowieso nur eine Art optische Klammer, und der Verrechnungsmodus spielt praktisch keine Rolle.

Noch ein paar Vermutungen:
-Beim Malen auf der untersten Ebene tun sich beide Programme vom Tempo her nichts?

Bei diesem speziellen Bild ist es so, daß der Pinsel in PSE gleichmäßiger läuft. Bei PhotoLine ruckelt er mehr. Die Zeit, bis der Pinsel nachkommt würde ich bei beiden etwa gleich einschätzen. Einmal schräg übers Bild knapp vier Sekunden, weicher Pinsel. Natürlich hängt das auch viel vom Radius, Weichheit und Schrittweite ab. Das kann man schlecht vergleichen, weil die Einstellmöglichkeiten nicht die selben sind.

-Wenn alle oberen Ebenen nur 1 Pixel groß sind braucht PL kaum mehr als die 4MB Speicher, PSE aber 90 oder 180MB?

Ich habe das Dokument auf 1x1 Pixel verkleinert und dann nur die Hintergrundebene wieder auf 1440x900 vergrößert, dann gespeichert, beide Programme geschlossen und die Datei wieder geöffnet.

PSE 140 MB
PhotoLine 56 MB (nach Löschen des Vorschaubildes, welches ja bei PSD automatisch erscheint waren es noch 30 MB)

-Beim Malen auf der obersten Ebene braucht PL genauso lange wie auf der untersten Ebene, PSE ist aber schneller?

Richtig.


Wenn das wirklich rein an der Zwischenspeicherung liegt, ist das ziemlich genial gemacht.

[SCX]

Ich habe das jetzt mal mit Hoogos "Laangsam"-Datei probiert. Die bremst PhotoLine wirklich ganz schön aus. Wenn ich über den bestehenden Ebenen eine 100% deckende Ebene erstelle, sodaß also eigentlich alles, was sich darunter befindet für den Moment sowieso egal ist, wenn man darüber z. B. eine neue Arbeitsebene einfügt, bremsen die unteren Ebenen die Geschwindigkeit scheinbar trotzdem. Da müßte wirklich noch einiges an Potential für eine schnellere Geschwindigkeit bei PhotoLine drin sein. Allerdings weiß ich natürlich nicht, wie aufwendig es ist, sowas zu ändern.

[NoSi]

Die da

Hossa! Das ist ja cool! Die hab ich noch nie ausprobiert. Da wird also das aktuelle Verzeichnis "durchgeloopt" - coole Funktion. Wobei das natürlich auch ziemlich fatal sein kann, denn ob man dann bei mehreren Versionen immer so den Überblick hat. Denn wenn man z.B. zwei Bilder aus zwei Verschiedenen Verzeichnissen (oder mehr) hat, kann man in entsprechend vielen Verzeichnissen blättern. Hat zweifellos für die praktische Arbeit was, weil man den Speicher freier halten kann. Ob ich da genauso leicht einfach mal was platt machen können will - da reicht mir die Option im Bildbetrachter und die klickt man nicht "mal eben" an. Vielleicht bin ich da ein wenig paranoid, was "unwiederbringlich weg" angeht... .

Grüße
NoSi

[JulianZI]

Ob ich da genauso leicht einfach mal was platt machen können will - da reicht mir die Option im Bildbetrachter und die klickt man nicht "mal eben" an. Vielleicht bin ich da ein wenig paranoid, was "unwiederbringlich weg" angeht...

Anstatt gleich zu löschen würde ich daher die Datei in den Papierkorb verschieben. Nach Abfrage versteht sich.

Wieso ich drauf komme?

Ich exportiere gelegentlich ein Bild aus Lightroom in Photoline um es dort fürs Web aufzubereiten. Hinterher möchte ich die exportierte Kopie (ich habe ja die RAW Daten) wieder löschen. Das Bild ist ja auch nicht automatisch in LR sichtbar, wenn man nicht "Stapeln" ausgewählt hat. Es handelt sich also um eine Kopie die nur Speicher vergeudet.

[Hoogo]

Nochmal zu den Cache-Geschichten:
----------------------------
Meine Vorstellung von der Vorgehensweise von PL ist, daß eine Speicher von der Größe des Bildschirmfensters angelegt wird und dann ALLE Ebenen von unten nach oben im Ebenenstapel erstmal "irgendwie" auf Bildschirmgröße gerendert und dann mit diesem Speicher verrechnet werden. Von mir aus auch in einem Schritt... Jedenfalls stelle ich mir zwangsläufig nach jeder eingerechneten Ebene einen Zwischenstand im Speicher vor. Nach allen Ebenen ist das der Endstand, und der wird angezeigt. Falls das ganz anders läuft ist natürlich alles, was ich von mir gebe, Mumpitz.

Ich komme häufiger an einen Punkt, an dem PL sehr langsam wird, weil ich mir da schonmal ganz wilde Ebenen-Konstruktionen aufbaue. Virtuelle Duplikate mit Kanalmixer und Histogramm+Maske zu einem Maskenteil machen, mehrere Maskenteile dann kombinieren... Ich gebe gerne zu, daß nicht alles non-destruktive wirklich sinnvoll ist, ich reduzier dann halt allerlei auf eine Ebene, und dann wird es auch wieder flüssiger.

Ich sehe die Cache-Geschichten als 2 Baustellen:
-Cache als solcher
-Berechnung in 100%

Gegen "...Das heißt, man müsste direkt nach dem Öffnen des Bildes alle Caches komplett füllen, was meiner Ansicht nach inakzeptabel lange dauert..." möchte ich Einspruch erheben Wenn ich eine Datei öffne, dann dauert es, bis ich die auf dem Bildschirm sehe - schliesslich muß die Datei gerendert werden. Als Aussenstehender stelle ich es mir da einfach vor, die dabei zwangsläufig entstehenden Zwischenschritte den gerade berechneten Ebenen zuzuordnen - falls man sich entscheidet, gerade diese Ebene zu cachen. Der ganze Cache müsste beim Scrollen/zoomen geleert werden, Teile beim Betreten von Gruppen oder dem Wechsel der aktiven Ebene. Über Details zerbreche ich mir da mal nicht den Kopf

Ein weiterführender Schritt wäre die 100%-Geschichte, hätte vielleicht noch ein paar Vorzüge bei der Anzeige, beim Zoomen und Scrollen, aber da fallen mir auf Anhieb auch gleich viel mehr Sonderfälle ein.

Smart-Ebenen:
----------------------------
Nach dem, was ich so mitbekomme, werden die meist benutzt, um Filter verlustfrei anwenden zu können. Da finde ich den PL-Weg besser. Das eigentlich coole an einer Smart-Ebene ist imho, daß sie für PS unverdauliche Daten speichern kann und diese Daten von einer fremden Anwendung rastern lassen kann. Von diesem Zweck hört man aber seltener, vielleicht mal, wenn Raw-Daten von einem Raw-Konverter bearbeitet werden oder da ein Vektorbild in PS weiterbearbeitet wird. Das PS da nebenbei die ganze Ebene mit den ganzen Filteranwendungen zwischenspeichert (und vermutlich auch speichert, wer weiß, ob der Zeilrechner alle fremden Anwendungen drauf hat?) ist imho ein sehr nützlicher Nebeneffekt.

[SCX]

Smart-Ebenen:
----------------------------
Nach dem, was ich so mitbekomme, werden die meist benutzt, um Filter verlustfrei anwenden zu können. Da finde ich den PL-Weg besser. Das eigentlich coole an einer Smart-Ebene ist imho, daß sie für PS unverdauliche Daten speichern kann und diese Daten von einer fremden Anwendung rastern lassen kann. Von diesem Zweck hört man aber seltener, vielleicht mal, wenn Raw-Daten von einem Raw-Konverter bearbeitet werden oder da ein Vektorbild in PS weiterbearbeitet wird. Das PS da nebenbei die ganze Ebene mit den ganzen Filteranwendungen zwischenspeichert (und vermutlich auch speichert, wer weiß, ob der Zeilrechner alle fremden Anwendungen drauf hat?) ist imho ein sehr nützlicher Nebeneffekt.

Was ich so in Videos gesehen habe, sind Smart-Ebenen (Smart Objects? Oder sind das zwei verschiedene Sachen?) recht hilfreich, eben weil es in PS nicht soviele Arbeitsebenen gibt, wie in PL. Wenn ich eine Ebene entsprechend umwandle, können da wohl so ziemlich alle Filter verlustfrei angewandt werden, wie Du richtig geschrieben hast.

Der andere Vorteil ist, daß man wohl das Original verändern kann und das wird dann automatisch im Bild aktualisiert.

Das kenne ich aber alles nur von Videos und bin mir über die tatsächliche Funktionsweise nicht so ganz im Klaren. Das wäre jetzt für mich kein Killerargument für eine Software. Nett, wenn man es hat, aber vermißt habe ich es in PL dank der zahlreichen Arbeitsebenen bisher noch nie.

[Martin Huber]

Meine Vorstellung von der Vorgehensweise von PL ist, daß eine Speicher von der Größe des Bildschirmfensters angelegt wird und dann ALLE Ebenen von unten nach oben im Ebenenstapel erstmal "irgendwie" auf Bildschirmgröße gerendert und dann mit diesem Speicher verrechnet werden. Von mir aus auch in einem Schritt... Jedenfalls stelle ich mir zwangsläufig nach jeder eingerechneten Ebene einen Zwischenstand im Speicher vor. Nach allen Ebenen ist das der Endstand, und der wird angezeigt. Falls das ganz anders läuft ist natürlich alles, was ich von mir gebe, Mumpitz.

Grundsätzlich ist das so.

Ich komme häufiger an einen Punkt, an dem PL sehr langsam wird, weil ich mir da schonmal ganz wilde Ebenen-Konstruktionen aufbaue. Virtuelle Duplikate mit Kanalmixer und Histogramm+Maske zu einem Maskenteil machen, mehrere Maskenteile dann kombinieren... Ich gebe gerne zu, daß nicht alles non-destruktive wirklich sinnvoll ist, ich reduzier dann halt allerlei auf eine Ebene, und dann wird es auch wieder flüssiger.

Arbeitsebenen sind in PhotoLine üblicherweise recht schnell. Eine Gradationsebene oder Histogrammebene braucht für die Anzeige nicht nennenswert länger als ein normales Bild. Das Arbeiten mit Arbeitsebenen wird üblicherweise dann langsam, wenn
- Filter mit großem Radius beteiligt sind
- die Maske der Arbeitsebene kein einfaches Graubild ist

Ich sehe die Cache-Geschichten als 2 Baustellen:
-Cache als solcher
-Berechnung in 100%

Gegen "...Das heißt, man müsste direkt nach dem Öffnen des Bildes alle Caches komplett füllen, was meiner Ansicht nach inakzeptabel lange dauert..." möchte ich Einspruch erheben Wenn ich eine Datei öffne, dann dauert es, bis ich die auf dem Bildschirm sehe - schliesslich muß die Datei gerendert werden.

Den Einspruch lehne ich ab Der Filter aus deiner Beispieldatei braucht auf meinem Rechner 90 Sekunden, wenn ich ihn auf das ganze Bild anwende. Während ich bisher das Dokument sofort sehe, müsste ich in Zukunft 90 Sekunden warten.

Als Aussenstehender stelle ich es mir da einfach vor, die dabei zwangsläufig entstehenden Zwischenschritte den gerade berechneten Ebenen zuzuordnen - falls man sich entscheidet, gerade diese Ebene zu cachen. Der ganze Cache müsste beim Scrollen/zoomen geleert werden, Teile beim Betreten von Gruppen oder dem Wechsel der aktiven Ebene. Über Details zerbreche ich mir da mal nicht den Kopf

Über Details zerbreche ich mir in dem Zusammenhang regelmäßig den Kopf und bin bisher immer zu dem Schluss gekommen, dass ein Cache den Aufwand und die Risiken nicht wert ist.
Wenn ich den Cache beim Scrollen/Zoomen leere, dann verliere ich - besonders in Hinblick auf die von dir gewünschte 100% Darstellung bei Zooms kleiner als 100% - jeden Vorteil des Caches. Ein Cache bringt meiner Ansicht nach nur dann einen Vorteil, wenn er immer in 100% und in Dokumentgröße angelegt wird, und dann bei Bedarf die benötigten Teile gefüllt werden. Das ist aber sehr aufwendig und benötigt sehr viel Speicher.

In dem Zusammenhang ist auch wichtig, dass große Speicherallozierungen recht langsam sind. Und je mehr Speicher eine Anwendung verbraucht, umso langsamer werden Speicherallozierungen und damit die gesamte Anwendung.

Martin

[akeller]

*

[Hoogo]

Hm... Das Dokument auf die Hintergrundebene zu reduzieren dauert bei mir etwa 70 Sekunden. Da das ja ordentlich gemacht wird wäre das ein guter Punkt gegen die Berechnung in 100%. Beim Öffnen der Gradationskurve werden auch immer die kompletten 70 Sekunden gebraucht, wegen der Histogrammdarstellung?

Aber mal von der 100%-Sache abgesehen: Das Dokument öffnet sich bei mir in 29%, und das dauert 3 Sekunden. Und diese 3 Sekunden werden immer wieder verbraucht, beim Wechsel einer Ebene, beim Minimieren/Maximieren des Fensters, beim Scrollen, bei jedem Zupfen an den Punkten der Gradationskurve... Diese 3 Sekunden sind manchesmal sehr lästig, und da hoffe ich halt, daß es einen einfachen Weg gibt, das zumindest bei den wichtigsten Fällen zu erreichen. Da verspreche ich mir von der simpelsten Cache-Version, hier und da den skalierten, sichtbaren Ausschnit zu speichern, schon einiges.

Wobei mir aber auch dämmert, daß das Speichern des sichtbaren Bildausschnitts zu einfach gedacht ist. Für Filterebenen mit Radius müsste der Ausschnitt größer berechnet werden, und davon ab scheint Ihr mir sowieso nicht den ganzen Bildschirm, sondern nur die nötigen Bereiche immer neu zu berechnen, und sicher noch mehr...

Anbei ein anderer, stressiger Ebenen-Aufbau, in den Ebenen herumzumalen ist eine Quälerei. Keine Ahnung, ob auch andere Anwender derart "experimentelle" Dokumente zusammenbauen.

[SCX]

Anbei ein anderer, stressiger Ebenen-Aufbau, in den Ebenen herumzumalen ist eine Quälerei. Keine Ahnung, ob auch andere Anwender derart "experimentelle" Dokumente zusammenbauen.

Dazu braucht es keine experimentelle Dokumente. Wenn man ein wenig Illustration machen will, kommen sehr schnell sehr viele Ebenen zusammen. Auch bei Fotomontagen u. ä.

[siepict]

Ist das ein Fehler oder habe ich etwas übersehen?

hallo andreas,
interessant, vor allem, wenn du dir dazu den ebenenrand anzeigen läßt.
horst
edit: p.s.: noch interessanter. wie immer hab' ich mal ein anderes programm genommen, und da geschieht dasselbe (siehe anhang)

[Hoogo]

Wenn man die Randlinie und die Flächenfüllung als 2 eigenständige Ebenen betrachtet, dann wird das Ergebnis logisch, finde ich.
Ähnliche Effekte gab es bei Ebenen-Effekten, aber da hat sich gerade was verändert

Wenn diseser Effekt grad konkret stört kann man die Ebene gruppieren und kapseln, oder einfacher: Einen Ebeneneffekt Fabüberlagerung ohne Farbe drauftun.

[akeller]

*

[siepict]

andreas,
hab' auch schon eine antwort aus 'dem anderen forum' und erhalte dort eine entsprechende erklärung.
egal ob logisch oder nicht, aber dann wird es wohl so sein - interessant in jedem fall.
horst

[Hoogo]

Meine Lösung: Vektorebene umwandeln in RGB, dann kann man ohne Probleme die Ebenenintensität verändern. Dumm nur, wenn man dann noch einmal die Größe ändern möchte.

Na, jetzt hast Du ja 2 Alternativen.