Neue Testversion 16.40b7

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
and
Mitglied
Posts: 125
Joined: Wed 03 Feb 2010 14:36

Re: Neue Testversion 16.40b7

Post by and »

Martin Huber wrote:- 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.
Windows 10 64 Bit You better watch out, there may be dogs about.
Martin Huber
Entwickler
Entwickler
Posts: 3980
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 16.40b7

Post by Martin Huber »

Hoogo wrote: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.
Hoogo wrote: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
User avatar
Hoogo
Betatester
Posts: 3917
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 16.40b7

Post by Hoogo »

Martin Huber wrote: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?
Martin Huber wrote: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
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 16.40b7

Post by bkh »

Martin Huber wrote:
bkh wrote:- 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?
bkh wrote:- 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
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 16.40b7

Post by 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.
You do not have the required permissions to view the files attached to this post.
User avatar
Hoogo
Betatester
Posts: 3917
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 16.40b7

Post by 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.
User avatar
Hoogo
Betatester
Posts: 3917
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 16.40b7

Post by Hoogo »

Beim Malen mit dem normalen Pinsel scheint mir Shift nicht mehr zum Linienziehen zu wirken. Shift hat einfach keine Funktion mehr.
User avatar
frankenstein
Betatester
Posts: 317
Joined: Fri 28 May 2004 18:05
Location: Wien

Re: Neue Testversion 16.40b7

Post by frankenstein »

Ja, ist bekannt und wird repariert.
http://www.pl32.com/forum3/viewtopic.php?f=1&t=2545
Michael
Macbook Pro, macOS X (X = neueste Version)
https://instagram.com/m_frankenstein/
https://frankenste.info/m/
Martin Huber
Entwickler
Entwickler
Posts: 3980
Joined: Tue 19 Nov 2002 15:49

Re: Schnittmaske

Post by Martin Huber »

Martin Huber wrote:
bkh wrote: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
Entwickler
Entwickler
Posts: 3980
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 16.40b7

Post by Martin Huber »

bkh wrote:- 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).
bkh wrote:- 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.
bkh wrote:- 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
Entwickler
Entwickler
Posts: 3980
Joined: Tue 19 Nov 2002 15:49

Re: Neue Testversion 16.40b7

Post by Martin Huber »

Hoogo wrote: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
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 16.40b7

Post by 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.
You do not have the required permissions to view the files attached to this post.
User avatar
Hoogo
Betatester
Posts: 3917
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Neue Testversion 16.40b7

Post by 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.
User avatar
Gerhard Huber
Entwickler
Entwickler
Posts: 4011
Joined: Mon 18 Nov 2002 15:30
Location: Bad Gögging

Re: Neue Testversion 16.40b7

Post by Gerhard Huber »

Hoogo wrote: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
Betatester
Posts: 3661
Joined: Thu 26 Nov 2009 22:59

Re: Neue Testversion 16.40b7

Post by bkh »

Hoogo wrote: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.