Neue Testversion 17.90b8

[bkh]

Im Code steht und bei mir ist das auch so, dass hier Leerzeichen eingefügt werden, d.h. wenn du 10 Seiten speicherst, erhält die Seite 1 den Namen "Page 1.pld" statt "Page1.pld". Das wird hier unter Windows dann im Explorer auch richtig sortiert.
Ist das unter Mac OS X nicht so? Soll ich besser "Page01.pld" erzeugen?

Genau, die Leerzeichen habe ich auch. OS X sortiert die Bilder auch richtig, auch Programme, die einfach lexikografisch sortieren, kommen damit klar, Nur PL im Browser sortiert (wenn ich nach Name sortiere) anders und ignoriert anscheinend die Leerzeichen. Insofern wäre "Page01.pld" sicherer.

L.G.

Burkhard.

[Martin Huber]

Im Code steht und bei mir ist das auch so, dass hier Leerzeichen eingefügt werden, d.h. wenn du 10 Seiten speicherst, erhält die Seite 1 den Namen "Page 1.pld" statt "Page1.pld". Das wird hier unter Windows dann im Explorer auch richtig sortiert.
Ist das unter Mac OS X nicht so? Soll ich besser "Page01.pld" erzeugen?

Es sollte meiner Ansicht nach entweder immer ein Leerzeichen oder nie ein Leerzeichen eingefügt werden, also entweder:
- "Page1.pld", "Page2.pld" bis "Page10.pld"
oder:
- "Page 1.pld", "Page 2.pld" bis "Page 10.pld"

Ob man die Zahlen selbst nun mit "0" auf die gleichen Stellenanzahl bringt, ist mir egal.

Martin

P.S: Da sowohl Windows als auch Mac OS die Leerzeichen bei der Sortierung ignorieren ("a 1.pld" ist kleiner als "a2.pld"), habe ich die Sortierung in PhotoLine auch entsprechend umgebaut.

[Martin Huber]

Du kannst durch Drücken und Halten der R-Taste das "Ansicht drehen"-Werkzeug auch außer der Reihe aufrufen. Zurücksetzen lässt sich das Drehen durch einen einfachen Klick.

Ja, so hatte ich mir das vorgestellt … sehr schön. Im Moment bleibt noch der Pinselumriss stehen, wenn ich "R" halte.

Ist das schlimm? Redraw-Fehler treten bei mir dadurch zumindest nicht auf.

Martin

[bkh]

Im Moment bleibt noch der Pinselumriss stehen, wenn ich "R" halte.

Ist das schlimm? Redraw-Fehler treten bei mir dadurch zumindest nicht auf.

Schlimm nicht, macht insgesamt auf mich halt den Eindruck, als sei es "nicht ganz fertig". Erst ist der Pinselcursor sichtbar, aber während man dreht, verschwindet der Pinselcursor. Ob er beim Abheben des Stiftes/Loslassen der Maus wieder erscheint, ist ein bisschen zufällig (vermutlich hängt es davon ab, ob der Cursor sich nach dem Loslassen der Maus und vor dem Redraw noch bewegt – wenn ich während einer Bewegung den Stift loslasse, bekomme ich eher den Pinselcursor, wenn ich den Stift beim Abheben still halte, ist der Pinselcursor eher nicht da). Wenn ich die "R"-Taste loslasse und es ist kein Pinselcursor da, dann wird er erst neu gezeichnet, wenn ich den Cursor bewege.

Wenn das technisch einfacher ist: lasst doch den Pinselcursor einfach weiter mitlaufen – das, was mich, glaube ich, am meisten irritiert, ist, dass der Pinselcursor einfach stehen bleibt. Ich sehe gerade, beim Verschieben-Tool (Leertaste) tritt das alles auch auf.

Das mit dem temporären Werkzeugwechsel, indem man die entsprechende Taste gedrückt hält, finde ich übrigens ein tolles Feature. Geht das noch bei anderen Werkzeugen?

L.G.

Burkhard.

[Martin Huber]

Im Moment bleibt noch der Pinselumriss stehen, wenn ich "R" halte.

Ist das schlimm? (…)

Schlimm nicht, macht insgesamt auf mich halt den Eindruck, als sei es "nicht ganz fertig".

Ich habe das jetzt so umgebaut, dass der Pinselumriss sofort gelöscht wird. Er erscheint aber weiterhin erst wieder, wenn nach dem temporären Aufruf die Maus bewegt wird. Das zu ändern, wäre eine gewisse Hampelei.

Das mit dem temporären Werkzeugwechsel, indem man die entsprechende Taste gedrückt hält, finde ich übrigens ein tolles Feature. Geht das noch bei anderen Werkzeugen?

Das wird momentan nur von "Ansicht drehen" unterstützt. Prinzipiell wäre das mit allen Werkzeugen möglich, die keine Einstellungen haben. Da fällt mir aber auf Anhieb nur die Lupe ein, die aber kein Tastenkürzel hat (bei Photoshop hat sie "M", das aber bei uns momentan das Finger-Werkzeug ist).

Martin

[bkh]

Ich habe hier noch ein kleines Problem mit der Texteingabe in Textebenen: jedesmal, wenn ich "r" oder einen Leerraum tippe, kommt das Zeichen doppelt. Hängt vermutlich mit dem Shortcut für das neue Ansicht-Drehen-Werkzeug zusammen, denn wenn ich dort die Tastenzuordnung lösche, ist das Problem mit dem "r" verschwunden. "R" geht übrigens einwandfrei. In der 17.53 ist das Problem noch nicht, auch nicht mit der Leertaste.

L.G.

Burkhard.

[bkh]

H- Grafiktablett, Malwerkzeuge: Beim Wechsel auf den Stift-Radiergummi wird auch
implizit auf das Radiergummi-Werkzeug gewechselt

Bei mir funktioniert es plötzlich nicht mehr – der Radiergummi schaltet nicht mehr auf Radiergummi, sondern radiert mit den normalen Pinseleinstellungen, so wie bis zur letzten PL-Version. Ich habe schon alles ausprobiert, Voreinstellungen (~/Library/Preferences/Photoline) gelöscht, Beta neu installiert, Rechner neu gestartet, mit und ohne Touch-Funktion des Tabletts, verschiedene Tablett-Optionen … – nichts hilft. Habt ihr irgendeine Idee, was da schief laufen bzw. was ich noch probieren könnte?

Was mir aufgefallen ist: die Radiergummi-Einstellungen werden anscheinend nicht richtig gespeichert (auch nicht in der 17.53): wenn ich beim Radiergummi eine neue Einstellung mache, auf ein anderes Werkzeug wechsle und dann PL beende, ist die neue Radierer-Einstellung weg. (Ohne den Werkzeugwechsel geht's).

L.G.

Burkhard.

[Martin Huber]

Ich habe hier noch ein kleines Problem mit der Texteingabe in Textebenen: jedesmal, wenn ich "r" oder einen Leerraum tippe, kommt das Zeichen doppelt. Hängt vermutlich mit dem Shortcut für das neue Ansicht-Drehen-Werkzeug zusammen, denn wenn ich dort die Tastenzuordnung lösche, ist das Problem mit dem "r" verschwunden.

Ja, ich habe das mittlerweile repariert.

Bei mir funktioniert es plötzlich nicht mehr – der Radiergummi schaltet nicht mehr auf Radiergummi, sondern radiert mit den normalen Pinseleinstellungen, so wie bis zur letzten PL-Version. Ich habe schon alles ausprobiert, Voreinstellungen (~/Library/Preferences/Photoline) gelöscht, Beta neu installiert, Rechner neu gestartet, mit und ohne Touch-Funktion des Tabletts, verschiedene Tablett-Optionen … – nichts hilft.

Da wird intern was nicht richtig initialisiert. Wenn da bei Programmstart zufällig der richtige Wert steht (was bei meinen Tests mit einer Ausnahme bisher immer so war), dann funktioniert es, ansonsten nicht. In der nächsten Beta sollte das Problem nicht mehr auftreten.

Was mir aufgefallen ist: die Radiergummi-Einstellungen werden anscheinend nicht richtig gespeichert (auch nicht in der 17.53): wenn ich beim Radiergummi eine neue Einstellung mache, auf ein anderes Werkzeug wechsle und dann PL beende, ist die neue Radierer-Einstellung weg. (Ohne den Werkzeugwechsel geht's).

Ich sehe mir das an.

Martin

[bkh]

Da wird intern was nicht richtig initialisiert. Wenn da bei Programmstart zufällig der richtige Wert steht (was bei meinen Tests mit einer Ausnahme bisher immer so war), dann funktioniert es, ansonsten nicht. In der nächsten Beta sollte das Problem nicht mehr auftreten.

Danke! Da bin ich aber erleichtert – ich war gerade dabei, den Tabletttreiber neu zu installieren, kann ich mir jetzt wohl erst mal sparen.

L.G.

Burkhard.

[bkh]

Farbfilter bei virtuellen Kopien scheinen nicht mehr zu funktionieren. Die angehängte Datei zeigt bei PL 17.53 noch das richtige Ergebnis (reale und virtuelle Kopie verhalten sich gleich).

Ich habe dann versucht, die virtuelle in eine reale Ebene zu wandeln und bin dabei noch auf folgende Probleme gestoßen.

Außerdem: wenn ich eine virtuelle Kopie in eine reale wandle, und das Original ist ausgeschaltet ("Auge"), dann ist die reelle Kopie auch aus, egal, ob die virtuelle Kopie an war oder nicht. Das passiert auch in der 17.53.

Ein etwas schwierigerer Punkt: beim Wandeln von virtueller in reale Kopie gehen Ebenenstile und Farbfilter der virtuellen Kopie verloren. Es ist klar, dass es nicht immer möglich ist, die Kombinationen von Farbfiltern/Ebenenstile des Originals und der virtuellen Kopie zu einem gleichwertigen Farbfilter/Ebenenstil der gewandelten Ebene zu verrechnen, aber evtl. könnte man in dem Fall, dass beide Ebenen Filter/Stile haben, die Filter/Stile der Originalebene auf die neue Kopie anwenden und die Filter/Stile der virtuellen Kopie auf eine Gruppe, die diese neue Kopie enthält?

L.G.

Burkhard.

[Martin Huber]

Farbfilter bei virtuellen Kopien scheinen nicht mehr zu funktionieren. Die angehängte Datei zeigt bei PL 17.53 noch das richtige Ergebnis (reale und virtuelle Kopie verhalten sich gleich).

und

Außerdem: wenn ich eine virtuelle Kopie in eine reale wandle, und das Original ist ausgeschaltet ("Auge"), dann ist die reelle Kopie auch aus, egal, ob die virtuelle Kopie an war oder nicht. Das passiert auch in der 17.53.

Das habe ich beides geändert.

Ein etwas schwierigerer Punkt: beim Wandeln von virtueller in reale Kopie gehen Ebenenstile und Farbfilter der virtuellen Kopie verloren. Es ist klar, dass es nicht immer möglich ist, die Kombinationen von Farbfiltern/Ebenenstile des Originals und der virtuellen Kopie zu einem gleichwertigen Farbfilter/Ebenenstil der gewandelten Ebene zu verrechnen, aber evtl. könnte man in dem Fall, dass beide Ebenen Filter/Stile haben, die Filter/Stile der Originalebene auf die neue Kopie anwenden und die Filter/Stile der virtuellen Kopie auf eine Gruppe, die diese neue Kopie enthält?

So wie ich das sehe, existiert dieses Problem in der Praxis nicht. Haben eine virtuelle Kopie und deren Original beide einen Farbfilter oder Ebeneneffekte (zumindest bei Vordergrundeffekten, Hintergrundeffekte wie Schatten habe ich nicht getestet), "gewinnen" die virtuellen Kopien.

Beim Erzeugen einer echten Ebene wurden die Einstellungen der virtuellen Kopie aber nicht übernommen. Das habe ich geändert.

Martin

[Hoogo]

Da fällt mir grad ein, daß ich letztens im CT-Sondergheft geblättert habe, in dem es um 32Bit-Bildbearbeitung ging. PL hat da ein eigenes Kästchen bekommen, von dem mir aber vor allem die Nachteile und Probleme in Erinnerung geblieben sind. Clipping war einer der Punkte.

Hat jemand die CT? Wäre imho nicht verkehrt, diese nun "offiziell" bekannten Probleme anzugehen, wenn möglich.

[Martin Huber]

Da fällt mir grad ein, daß ich letztens im CT-Sondergheft geblättert habe, in dem es um 32Bit-Bildbearbeitung ging. PL hat da ein eigenes Kästchen bekommen, von dem mir aber vor allem die Nachteile und Probleme in Erinnerung geblieben sind. Clipping war einer der Punkte.

Hat jemand die CT? Wäre imho nicht verkehrt, diese nun "offiziell" bekannten Probleme anzugehen, wenn möglich.

Wenn ich mich recht erinnere, war die Kritik recht allgemein gehalten, ohne Beispiele zu nennen.

Nachdem die Histogrammkorrektur auf 32-Bit umgestellt wurde, sollten mittlerweile auch alle wichtigen Filter auf 32 Bit umgestellt sein (die meisten waren es davor schon), und nicht mehr Clippen.

Weiterhin clippen bzw. arbeiten nur mit 8/16 Bit die Funktionen, bei denen es prinzipbedingt ist:
- Farbverwaltung ist nur im Bereich [0;1] definiert (bzw. [0;255]/[0;65535]). Das betrifft alle Funktionen, die mit Farbprofilen arbeiten, aber auch z.B. Filtern im Lab-Farbraum.
- Tabellenbasierte Funktionen wie die "Gradation" sind auch nur im Bereich [0;1] definiert.
- Filter wie "Median", "Maximum rund" und "Minimum rund" können bei großen Filterradien nur mit 8 Bit in einer akzeptablen Geschwindigkeit ausgeführt werden.

Aber wenn du Probleme mit einer Funktion hast, dann sehe ich mir das gerne an.

Martin