Neue Testversion 17.90b11

[Hoogo]

Im Moment ist es auch so, dass Dialoge, die ich andocke, während "Lock Panel Layout" aktiv ist, trennbar bleiben (keine schlechte Lösung, weil man so versehentlich angedockte Dialoge wieder losbekommt). Sogar, wenn ich "Lock Panel Layout" aus- und wieder einschalte – da würde ich allerdings erwarten, dass die angedockten Dialoge auch angedockt bleiben.

Wenn "Dialoganordnung schützen" aktiviert ist, docken Dialoge nicht an andere an, die Ausrichtung der Position wird aber schon gemacht Daher mag es so erscheinen, als würden die Dialog aneinander gedockt.

Vielleicht wäre es dann sinnvoll, das "Einrasten" zu unterdrücken? Dann wüsste man, dass die Dialoge nur "zufällig" an der entsprechenden Position sind. Wenn Dialoge bei "Lock Panel Layout" nicht einrasten, ist das ja grundsätzlich schlüssig.

L.G.

Burkhard.

Nicht einrasten wäre doch auch wieder doof. Dann würde eine hübsche Anordnung rein vom Augenmaß abhängen.

[OldRadioGuy]

Re: Straighten Tool Problems

Here are some screen cap illustrations to demonstrate what is happening with the Straighten tool.

Example_1.jpg

Example_2.jpg

Example_3.jpg

2. The application of the Straighten Tool on a ... file with three layers ... does not get recorded as an Undo step. ...

don't get a problem here

Gerhard

Gerhard, I emailed you a link for downloading the PDL file in question

2. The application of the Straighten Tool on a PSD file with three layers -- Thumbnail, Focal Point (a plugin applied in Lightroom) and Background -- does not get recorded as an Undo step.

Maybe the amount of RAM for Undo isn't enough (check Preferences -> Working -> Undo). Rotating changes all layers in the document and so needs a lot of undo space. To get an idea of how much undo space you need, go to "Save as" and check the file size of your PLD with the "No compression" option.

Burkhard.

Burkhard, I doubled the undo space, and it made no difference.

Bpb

[bkh]

Noch 'ne Kleinigkeit, die ich etwas merkwürdig finde: wenn ich mehrere Ebenen auswähle, so wie hier:

Bild 1.png

und dann auf das "Auge" der untersten Ebene klicke, dann werden die beiden ausgewählten Ebenen unsichtbar:

Bild 2.png

Erwartet hätte ich, dass ich mit dem "Auge" der untersten Ebene diese Ebene unsichtbar machen kann (und mit einem der Augen der ausgewählten Ebenen diese ausgewählten Ebenen gleichzeitig ein- oder ausschalten kann. Shift-Klick ins Auge verhält sich noch mal ganz anders – es wirkt immer nur auf die Ebene, die man anklickt.

L.G.

Burkhard.

[Juan]

Hi all,

First of all I have to say that the new terminology used on the layers function is much much clear Thank you.

I would like to suggest another related with the option of the Copy brush, there is one that reads Merged Copy, I´m not so sure about it so what if this could be changed for something like: Read other layers or Use other layers

Another thing that comes to my mind is when a new layer is created there is a checkbox for 16 bits, but with the full support of 32 bits as well, what about a small dropdown menu with 8,16 and 32bits?

Cheers
Juan

[arnold_s]

Hat jemand außer mir noch das Problem, dass Photoline beim Laden von JPGs (andere gehen) aus der Bildübersicht immer abschmiert?

[Martin Huber]

Hat jemand außer mir noch das Problem, dass Photoline beim Laden von JPGs (andere gehen) aus der Bildübersicht immer abschmiert?

In der aktuellen Beta gibt es ein Problem mit der Dateivorschau in der Bildübersicht.
Wenn du die Dateivorschau so klein ziehst, dass sie unsichtbar wird, sollte der Absturz verschwinden.

Martin

[bkh]

Ich sehe hier ein etwas merkwürdiges Verhalten der Arbeitsebene "Wolken" (sowohl 17.90b11 als auch 17.53, OS X 10.8.4):

• ich lege eine Arbeitsebene "Wolken" über eine weiße RGB-Ebene.

• wenn ich die Arbeitsebene als Kindebene der RGB-Ebene nehme, sieht das Ergebnis auf dem Bildschirm plötzlich anders aus, beim Web-Export oder über "Verknüpftes Kopieren" bekomme ich aber das ursprüngliche Ergebnis.

• wenn ich eine virtuelle Kopie der RGB-Ebene mit angehängter Arbeitsebene "Wolken" mache, dann sieht die virtuelle Kopie wiederum anders aus – sie setzt sozusagen das Wolkenmuster aus der Originalebene fort. Einfach die virtuelle Kopie verschieben, dann sieht man den Effekt. (Der eigentliche Grund, warum ich "Wolken" an die RGB-Ebene angehängt habe, ist, dass ich eine virtuelle Kopie des Wolkenmusters brauchte.)

• wenn ich statt der RGB-Ebene + Kindebene eine gekapselte Gruppe nehme, ist das Verhalten genauso.

Eine Beispieldatei ist im Anhang, die oberste (ausgeschaltete) Ebene ist die verknüpfte Kopie der darunter liegenden Ebenen.

L.G.

Burkhard.

[arnold_s]

Hat jemand außer mir noch das Problem, dass Photoline beim Laden von JPGs (andere gehen) aus der Bildübersicht immer abschmiert?

In der aktuellen Beta gibt es ein Problem mit der Dateivorschau in der Bildübersicht.
Wenn du die Dateivorschau so klein ziehst, dass sie unsichtbar wird, sollte der Absturz verschwinden.

Martin

Danke, probiere ich aus.

[Martin Huber]

Ich sehe hier ein etwas merkwürdiges Verhalten der Arbeitsebene "Wolken" (sowohl 17.90b11 als auch 17.53, OS X 10.8.4):

• ich lege eine Arbeitsebene "Wolken" über eine weiße RGB-Ebene.

• wenn ich die Arbeitsebene als Kindebene der RGB-Ebene nehme, sieht das Ergebnis auf dem Bildschirm plötzlich anders aus, beim Web-Export oder über "Verknüpftes Kopieren" bekomme ich aber das ursprüngliche Ergebnis.

Ich denke, dass ich das jetzt repariert habe.

• wenn ich eine virtuelle Kopie der RGB-Ebene mit angehängter Arbeitsebene "Wolken" mache, dann sieht die virtuelle Kopie wiederum anders aus – sie setzt sozusagen das Wolkenmuster aus der Originalebene fort. Einfach die virtuelle Kopie verschieben, dann sieht man den Effekt. (Der eigentliche Grund, warum ich "Wolken" an die RGB-Ebene angehängt habe, ist, dass ich eine virtuelle Kopie des Wolkenmusters brauchte.)

Da Arbeitsebenen im Seitenkoordinatensystem arbeiten, kann ich nicht garantieren, dass die (virtuelle) Kopie einer gruppierten Arbeitsebene genauso aussieht wie das Original. Spätestens wenn die Kopie skaliert wird (oder skaliert/geschert/verzerrt), werden Unterschiede auftauchen. Der spezielle Fall aus deinem Beispieldokument sollte aber in der nächsten Beta funktionieren.

Martin

[Ashcraaft]

Mein PL hat gerade rund 5 Minuten zum öffnen einer lokalen PLD-Datei benötigt.
Ich habe das Programm einfach im Status "reagiert nicht" belassen und andersweitig weitergearbeitet und nach 5 Minuten war das Bild dann endlich offen.

Hat noch jemand Hänger oder Abstürze zu verzeichnen?

[Ashcraaft]

Mein PL hat gerade rund 5 Minuten zum öffnen einer lokalen PLD-Datei benötigt.
Ich habe das Programm einfach im Status "reagiert nicht" belassen und andersweitig weitergearbeitet und nach 5 Minuten war das Bild dann endlich offen.

Hat noch jemand Hänger oder Abstürze zu verzeichnen?

>>> EDIT: Auch das Öffnen eines 1MB JPG benötigt mehrere Minuten

[bkh]

Mein PL hat gerade rund 5 Minuten zum öffnen einer lokalen PLD-Datei benötigt.
Ich habe das Programm einfach im Status "reagiert nicht" belassen und andersweitig weitergearbeitet und nach 5 Minuten war das Bild dann endlich offen.

Hat noch jemand Hänger oder Abstürze zu verzeichnen?

Hier bei mir unter OS X 10.8.4 ist alles normal. Deine Bilder sind ja meist nicht ganz klein, vielleicht hat es damit zu tun, dass nicht genügend freier Arbeitsspeicher frei ist und erst ein Teil auf die Festplatte ausgelagert werden muss? Hast du mal probiert, einfach alle Programme zu beenden und dann PL neu zu starten? Man kann das auch in der Aktivitätsanzeige sehen – wenn im Tab "Speicher" die Werte von "Frei" und "inaktiv" sehr klein sind und der Wert bei "Seitenauslagerungen" ständig steigt, dann werden ständig Daten zwischen Arbeitsspeicher und Festplatte hin- und hergeschoben, und damit kann man auf Dauer nicht vernünftig arbeiten. Wenn's das nicht ist, kannst du in der Liste darüber sehen, welches Programm gerade wie viel CPU-Leistung und wie wiel RAM benutzt (unter "Physikal. Speicher steht, wie viel RAM das Programm benutzen kann, unter VSIZE, wie viel es gerne hätte).

L.G.

Burkhard.

[Ashcraaft]

Mein PL hat gerade rund 5 Minuten zum öffnen einer lokalen PLD-Datei benötigt.
Ich habe das Programm einfach im Status "reagiert nicht" belassen und andersweitig weitergearbeitet und nach 5 Minuten war das Bild dann endlich offen.

Hat noch jemand Hänger oder Abstürze zu verzeichnen?

Hier bei mir unter OS X 10.8.4 ist alles normal. Deine Bilder sind ja meist nicht ganz klein, vielleicht hat es damit zu tun, dass nicht genügend freier Arbeitsspeicher frei ist und erst ein Teil auf die Festplatte ausgelagert werden muss? Hast du mal probiert, einfach alle Programme zu beenden und dann PL neu zu starten? Man kann das auch in der Aktivitätsanzeige sehen – wenn im Tab "Speicher" die Werte von "Frei" und "inaktiv" sehr klein sind und der Wert bei "Seitenauslagerungen" ständig steigt, dann werden ständig Daten zwischen Arbeitsspeicher und Festplatte hin- und hergeschoben, und damit kann man auf Dauer nicht vernünftig arbeiten. Wenn's das nicht ist, kannst du in der Liste darüber sehen, welches Programm gerade wie viel CPU-Leistung und wie wiel RAM benutzt (unter "Physikal. Speicher steht, wie viel RAM das Programm benutzen kann, unter VSIZE, wie viel es gerne hätte).

L.G.

Burkhard.

Photoline zieht zwischen 99 und 100% CPU. Ich mach jetzt erst mal einen kompletten Neustart…

[bkh]

Photoline zieht zwischen 99 und 100% CPU. Ich mach jetzt erst mal einen kompletten Neustart…

Das klingt zumindest nicht nach 'nem Arbeitsspeicherproblem. Wenn das passiert, ist die CPU-Auslastung eher niedrig …

L.G.

Burkhard.

[Ashcraaft]

Photoline zieht zwischen 99 und 100% CPU. Ich mach jetzt erst mal einen kompletten Neustart…

Das klingt zumindest nicht nach 'nem Arbeitsspeicherproblem. Wenn das passiert, ist die CPU-Auslastung eher niedrig …

L.G.

Burkhard.

Auch nach Neustart noch immer das gleiche Problem.
Ich installiere die Beta jetzt mal neu. Oder soll ich lieber irgendwelche speziellen .plist-Dateien entfernen?
Am liebsten aber natürlich mit Wiederherstellungsmöglichkeiten für meine Präferenzen.