Dies dürfte der Hauptgrund sein, warum Druckereien CMYK-Profile fordern.Martin Huber hat geschrieben:- 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.
Neue Testversion 16.40b7
-
- Mitglied
- Beiträge: 125
- Registriert: Mi 03 Feb 2010 14:36
Re: Neue Testversion 16.40b7
Windows 10 64 Bit You better watch out, there may be dogs about.
-
- Entwickler
- Beiträge: 4176
- Registriert: Di 19 Nov 2002 15:49
Re: Neue Testversion 16.40b7
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 hat geschrieben: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
Hier habe ich bis eben gebraucht, um zu kapieren, was du meinst Das "Linear abwedeln" von oben ist hier noch entscheidend.Hoogo hat geschrieben: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.
Ja, du hast recht. Da sind noch ein paar Anzeigemodi, die auch in 32-Bit die Werte abschneiden. Ich werde mir das ansehen.
Martin
-
- Betatester
- Beiträge: 4031
- Registriert: So 03 Jul 2005 13:35
- Wohnort: Mülheim/Ruhr
Re: Neue Testversion 16.40b7
Ist ein Extrapolieren an der Stelle sinnvoll? Wie verhält sich PS denn da?Martin Huber hat geschrieben: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.
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?Martin Huber hat geschrieben:Ja, du hast recht. Da sind noch ein paar Anzeigemodi, die auch in 32-Bit die Werte abschneiden. Ich werde mir das ansehen.
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: Neue Testversion 16.40b7
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.Martin Huber hat geschrieben:Da ist mir bei der Bedienung nicht klar, auf was sich Verzerrung beziehen soll:bkh hat geschrieben:- super wär's, wenn man auch gleich perspektivisch entzerren könnte (CMD-Eckenanfasser ziehen)
- 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.
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?
Dazu müsste die enstprechende Routine in PhotoLine erst deutlich schneller werden.bkh hat geschrieben:- und für die Luxusversion: Verzeichnung korrigieren mit CMD-Seitenanfasser ziehen … Na gut, das sprengt vermutlich endgülig den Rahmen.
[/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.
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: Neue Testversion 16.40b7
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. 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.
- 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. 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.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- Betatester
- Beiträge: 4031
- Registriert: So 03 Jul 2005 13:35
- Wohnort: Mülheim/Ruhr
Re: Neue Testversion 16.40b7
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.
-
- Betatester
- Beiträge: 4031
- Registriert: So 03 Jul 2005 13:35
- Wohnort: Mülheim/Ruhr
Re: Neue Testversion 16.40b7
Beim Malen mit dem normalen Pinsel scheint mir Shift nicht mehr zum Linienziehen zu wirken. Shift hat einfach keine Funktion mehr.
-
- Betatester
- Beiträge: 318
- Registriert: Fr 28 Mai 2004 18:05
- Wohnort: Wien
Re: Neue Testversion 16.40b7
Ja, ist bekannt und wird repariert.
http://www.pl32.com/forum3/viewtopic.php?f=1&t=2545
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/
Macbook Pro, macOS X (X = neueste Version)
https://instagram.com/m_frankenstein/
https://frankenste.info/m/
-
- Entwickler
- Beiträge: 4176
- Registriert: Di 19 Nov 2002 15:49
Re: Schnittmaske
Das habe ich nun eingebaut (steuerbar über das Transparenzfeld neben dem Anzeigemodus-Popup im Ebenendialog).Martin Huber hat geschrieben:(...)bkh hat geschrieben: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.
Martin
-
- Entwickler
- Beiträge: 4176
- Registriert: Di 19 Nov 2002 15:49
Re: Neue Testversion 16.40b7
Ich werde zukünftig Haarlinien immer geglättet zeichnen (wenn die Glättung nicht ausdrücklich ausgeschaltet ist).bkh hat geschrieben:- 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).
Ja, das ist ein Anzeigeproblem. Aber durch die obige Änderung sollte es nicht mehr auftreten.bkh hat geschrieben:- 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.
Man müsste die Ebene also implizit gekapselt ausgeben. Ich werde mir das mal ansehen.bkh hat geschrieben:- 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.
Martin
-
- Entwickler
- Beiträge: 4176
- Registriert: Di 19 Nov 2002 15:49
Re: Neue Testversion 16.40b7
Das wird auch repariert.Hoogo hat geschrieben: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.
Martin
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: Neue Testversion 16.40b7
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.) Wenn ich nun dasselbe im 32 bit-Modus mache, sehe ich auf dem Bildschirm dieselben Bänder wie im 8 bit-Modus. 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.
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.) Wenn ich nun dasselbe im 32 bit-Modus mache, sehe ich auf dem Bildschirm dieselben Bänder wie im 8 bit-Modus. 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.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- Betatester
- Beiträge: 4031
- Registriert: So 03 Jul 2005 13:35
- Wohnort: Mülheim/Ruhr
Re: Neue Testversion 16.40b7
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.
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.
-
- Entwickler
- Beiträge: 4145
- Registriert: Mo 18 Nov 2002 15:30
- Wohnort: Bad Gögging
Re: Neue Testversion 16.40b7
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.Hoogo hat geschrieben: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
-
- Betatester
- Beiträge: 3674
- Registriert: Do 26 Nov 2009 22:59
Re: Neue Testversion 16.40b7
Beide Standardmethoden zur Erzeugung der Paletten (MedianCut, Octree) sollten eigentlich bei 256 Farben im Bild die optimale Palette (mit allen vorkommenden Farben) liefern.Hoogo hat geschrieben:Methode Y hatte eine andere Farbpalette erzeugt, Ergebnis war ein Bild mit Fehlerstreuung.
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.