Neue Testversion 16.40b7

[and]

- Die Druckereien sind es leid, dass Kunden satte RGB-Farben (z.B. 0/0/255) abliefern und sich dann beschweren, dass diese bunten Farben nicht auch gedruckt werden.

Dies dürfte der Hauptgrund sein, warum Druckereien CMYK-Profile fordern.

[Martin Huber]

Ich experimentiere grad was damit, mit dem Vektormorphen und "linear abwedeln" einen "echten" Lichteinfall zu basteln.

(...)

Dann dachte ich mir so, daß ich doch einfach mal die Hintergrundebene auf 32Bit stelle und mein Vektormorphen nicht von 0 bis 8, sondern von 0 bis 64 laufen lasse. Das Ergebnis wird dann zwar schlimm zu hell, aber sollte ja bei 32Bit Float kein Problem sein, Werte >1 gehen ja nicht verloren.

Allerdings gelingt es mir weder mit einer TWK

Das Histogramm und die Gradation sind ein grundsätzliches Problem für 32 Bit, da sie beide nur für einen Bereich von [0;1] definiert sind.

noch mit einer grauen Ebene "multiplizieren", diese Werte wieder in meinen gewünschten Bereich zu verschieben. Das wird alles genau so dunkler, als ob bei Überlauf doch abgeschnitten würde.

Hier habe ich bis eben gebraucht, um zu kapieren, was du meinst Das "Linear abwedeln" von oben ist hier noch entscheidend.
Ja, du hast recht. Da sind noch ein paar Anzeigemodi, die auch in 32-Bit die Werte abschneiden. Ich werde mir das ansehen.

Martin

[Hoogo]

Das Histogramm und die Gradation sind ein grundsätzliches Problem für 32 Bit, da sie beide nur für einen Bereich von [0;1] definiert sind.

Ist ein Extrapolieren an der Stelle sinnvoll? Wie verhält sich PS denn da?

Ja, du hast recht. Da sind noch ein paar Anzeigemodi, die auch in 32-Bit die Werte abschneiden. Ich werde mir das ansehen.

Gut Was mir da grad durch den Kopf geht: Die Prozentwerte der Ebenendeckkraft inter/extrapolieren ja immer zwischen den Ergebnissen von 0% und 100% Deckkraft. Vielleicht tauchen da noch Situationen auf, in denen ein etwas geändertes Verhalten bei 32Bit sinnvoll wäre?

[bkh]

- super wär's, wenn man auch gleich perspektivisch entzerren könnte (CMD-Eckenanfasser ziehen)

Da ist mir bei der Bedienung nicht klar, auf was sich Verzerrung beziehen soll:
- auf das ungedrehte, vollständige Bild
- auf den momentan sichtbaren Ausschnitt
Rein theoretisch sollte es sich auf den sichtbaren Ausschnitt beziehen. Aber ich befürchte, dass man da recht absonderliche Vezerrungen produzieren kann, wenn man mehrere Dreh- und Verzerrungsoperationen kombiniert.

Ja, auf den Ausschnitt, der im Beschnittrahmen auftaucht. Wie bei der Drehung sollte nicht der Rahmen, sondern die darunter liegende BIldebene verzerrt werden. Also muss man "nur" die Verzerrung nehmen, die beim Bewegen der Rahmenecke entstehen würde, und damit die Eckpunkte der Bildebene transformieren.

Das mit den absonderlichen Verzerrungen verstehe ich nicht ganz - mehr als die vier Eckpunkte der BIldebene auf vier beliebige Punkte zu ziehen geht ja nicht.
Das Problem der Verrechnung von Drehungen und Verzerrungen tritt ja auch schon bei den normalen Ebenen auf - ich nehme mal an, ihr rechnet bei Kombinationen eh schon die ursprüngliche Drehung in eine Verzerrung um?

- und für die Luxusversion: Verzeichnung korrigieren mit CMD-Seitenanfasser ziehen … Na gut, das sprengt vermutlich endgülig den Rahmen.

Dazu müsste die enstprechende Routine in PhotoLine erst deutlich schneller werden.
[/quote]
Wenn ich es mir genau überlege, Ist das vermutlich auch nicht sinnvoll. Verzeichnung sollte man ja am unbschnittenen Bild korrigieren, sonst geht die Symmetrie verloren. Jedenfalls, wenn man auch noch verzerrt.

L.G.

Burkhard.

[bkh]

Beim Zeichnen von Bezierkurven sind mir ein paar Punkte aufgefallen (sowohl PL 16.11 als auch 16.40b7 64 bit, Mac OS 10.6.5)

- Wenn ich eine Bezier-Kurve zeichne und die Linienbreite auf "Haarlinie" (0 px) stelle, wird die Umrissline bei 100 % Ebenenintensität mit Antialiasing gezeichnet, bei einer anderen Intensität nicht. Da die Füllung immer mit Antialiasing gezeichnet wird, reicht sie dann z. T. über die Begrenzungslinie heraus. (Man sieht das nur im Pixelmodus oder wenn man die Ebene in eine Bitmap-Ebene wandelt).

- wenn ich im Pixelmodus bei hohen Zoomstufen (1600 %) scrolle, erscheinen auf dem Bildschirm Artefakte - am häufigsten, wenn die Randlinie ohne Antialiasing gezeichnet wird.

Screen shot 2010-12-02 at 11.07.34 .png

Betrifft wohl nur die Anzeige, wenn ich den Pixelmodus aus- und wieder anschalte, sind sie verschwunden.

- bei einer Intensität von unter 100 % wird im Moment eine teilweise transparente Randlinie auf die Füllung gezeichnet, so dass dort Farbmischungen auftreten. Bei breiteren Randlinien ist dann die innere Hälfte mit der Füllfarbe gemischt, die äußere nicht. Das ist in sich logisch, aber ich fände es sinnvoller, erst den Rand mit voller Intensität zu zeichnen und die Transparenz erst auf die fertige Kurve anzuwenden. Wenn ich ein solches Ergebnis im Moment erreichen will, muss ich die Kurve mit 100 % Intensität in eine gekapselte Gruppe setzen und dann die Intensität der Gruppe ändern. Das jetzige Verhalten ließe sich ja nach wie vor erreichen, indem man Rand und Füllfarbe mit reduzierter Deckung verwendet.

L.G.

Burkhard.

[Hoogo]

In der Histogrammkorrektur im Lab-Modus ist der L-Kanal nicht mehr der L-Kanal, sondern ein Dummy-Kanal, der nichts verändert. Zeigt man sich die 3 Kanäle gleichzeitig an, ist der L-Kanal verfügbar.

[Hoogo]

Beim Malen mit dem normalen Pinsel scheint mir Shift nicht mehr zum Linienziehen zu wirken. Shift hat einfach keine Funktion mehr.

[frankenstein]

Ja, ist bekannt und wird repariert.
http://www.pl32.com/forum3/viewtopic.php?f=1&t=2545

[Martin Huber]

Eben dachte ich noch: braucht man vielleicht doch nicht - texturieren macht man doch eh normalerweise mit dem Darstellungsmodus Overlay oder mit einem der Beleuctungsmodi. Aber wie ich sehe, schreiben auch diese Modi in den transparenten Bereich der Hintergrundebene(n) (...)

(...)

Prinzipiell wäre es evtl. sinnvoll, wenn man Ebenen das Attribute "Nicht den Alphakanal verändern" verpassen könnte.

Das habe ich nun eingebaut (steuerbar über das Transparenzfeld neben dem Anzeigemodus-Popup im Ebenendialog).

Martin

[Martin Huber]

- Wenn ich eine Bezier-Kurve zeichne und die Linienbreite auf "Haarlinie" (0 px) stelle, wird die Umrissline bei 100 % Ebenenintensität mit Antialiasing gezeichnet, bei einer anderen Intensität nicht. Da die Füllung immer mit Antialiasing gezeichnet wird, reicht sie dann z. T. über die Begrenzungslinie heraus. (Man sieht das nur im Pixelmodus oder wenn man die Ebene in eine Bitmap-Ebene wandelt).

Ich werde zukünftig Haarlinien immer geglättet zeichnen (wenn die Glättung nicht ausdrücklich ausgeschaltet ist).

- wenn ich im Pixelmodus bei hohen Zoomstufen (1600 %) scrolle, erscheinen auf dem Bildschirm Artefakte - am häufigsten, wenn die Randlinie ohne Antialiasing gezeichnet wird.
Betrifft wohl nur die Anzeige, wenn ich den Pixelmodus aus- und wieder anschalte, sind sie verschwunden.

Ja, das ist ein Anzeigeproblem. Aber durch die obige Änderung sollte es nicht mehr auftreten.

- bei einer Intensität von unter 100 % wird im Moment eine teilweise transparente Randlinie auf die Füllung gezeichnet, so dass dort Farbmischungen auftreten. Bei breiteren Randlinien ist dann die innere Hälfte mit der Füllfarbe gemischt, die äußere nicht. Das ist in sich logisch, aber ich fände es sinnvoller, erst den Rand mit voller Intensität zu zeichnen und die Transparenz erst auf die fertige Kurve anzuwenden.

Man müsste die Ebene also implizit gekapselt ausgeben. Ich werde mir das mal ansehen.

Martin

[Martin Huber]

In der Histogrammkorrektur im Lab-Modus ist der L-Kanal nicht mehr der L-Kanal, sondern ein Dummy-Kanal, der nichts verändert. Zeigt man sich die 3 Kanäle gleichzeitig an, ist der L-Kanal verfügbar.

Das wird auch repariert.

Martin

[bkh]

Eine Kleinigkeit ist mir beim 32 bit-Modus noch aufgefallen.

Wenn ich einen Farbverlauf in eine 16 bit-Ebene zeichne, sieht er auf dem Bildschirm gleichmäßig aus - anscheinend, weil PL meiner 8 bit-Videokarte per dithering "hilft" (was ich sehr schön finde, andere Programme können das nicht.)

Screen shot 2010-12-05 at 23.50.47 .png

Wenn ich nun dasselbe im 32 bit-Modus mache, sehe ich auf dem Bildschirm dieselben Bänder wie im 8 bit-Modus.

Screen shot 2010-12-05 at 23.50.38 .png

Wenn ich in eine 16 bit-Ebene konvertiere, verschwinden die Bänder - also ist der feinere Farbverlauf in der Farbebene vorhanden, aber das dithering wie bei 16 bit findet nicht statt. Ich fände es jedenfalls schön, wenn auch der 32 bit-Modus dithering könnte.

L.G.

Burkhard.

[Hoogo]

Ich reduziere ein Bild auf 256 Farben, best match, Methode X
Bei Speichern als Gif klappt nochmal der Dialog zum Reduzieren auf, 256 Farben, Fehlerstreuung, Methode Y voreingestellt. Da ich ja wusste, daß das Bild nur 256 Farben hatte, hab ich einfach so auf OK geklickt.

Denkste...

Methode Y hatte eine andere Farbpalette erzeugt, Ergebnis war ein Bild mit Fehlerstreuung.

Ich meine, in älteren Versionen kam der Dialog zum Reduzieren der Farben beim Speichern nicht, wenn das Bild nur 256 Farben hat.

[Gerhard Huber]

Ich reduziere ein Bild auf 256 Farben, best match, Methode X
Bei Speichern als Gif klappt nochmal der Dialog zum Reduzieren auf, 256 Farben, Fehlerstreuung, Methode Y voreingestellt. Da ich ja wusste, daß das Bild nur 256 Farben hatte, hab ich einfach so auf OK geklickt.
Denkste...
Methode Y hatte eine andere Farbpalette erzeugt, Ergebnis war ein Bild mit Fehlerstreuung.
Ich meine, in älteren Versionen kam der Dialog zum Reduzieren der Farben beim Speichern nicht, wenn das Bild nur 256 Farben hat.

Wenn du in den Einstellungen für GIF auf "Fragen" gestellt hast, kommt der Dialog immer. Es könnte ja sein, dass du auf 64 Farben reduzieren willst.

Gerhard

[bkh]

Methode Y hatte eine andere Farbpalette erzeugt, Ergebnis war ein Bild mit Fehlerstreuung.

Beide Standardmethoden zur Erzeugung der Paletten (MedianCut, Octree) sollten eigentlich bei 256 Farben im Bild die optimale Palette (mit allen vorkommenden Farben) liefern.

Eigentlich … Ich habe eben mal mit einem normalen Farbverlauf von Schwarz nach Weiß experimentiert, der nur 256 Farben hat. Mit "Best Color" sieht man deutlich, dass weder MedianCut noch Octree eine gute Palette hinkriegen - es werden wesentlich weniger Palettenplätze genutzt als vorhanden, entsprechend schlecht ist das Ergebnis. Liegt wohl daran, dass die Farben zu eng beieinander liegen. Wenn man auf weniger als 256 Farben reduziert, sieht man, dass auch die Aufteilung merkwürdig ist.

L.G.

Burkhard.