Posts by bertram
-
-
Hallo Holger,
magst du mir zwei Bildbeispiele zukommen lassen, die sich für dein Überlagerungsproblem eignen? Ich versuche gerade, intern unsere Splineverformung für diese Aufgabe zu nutzen.
-
Egal welche Art von Drucker unter Windows als Standdarddrucker definiert ist, ist in Ji die Druckvorschau immer mit einem weißen Rand versehen ...
Und warum wird der Randabstand nicht wieder auf die 5 mm zurückgesetzt ...
Einfache Antwort:
Weil wir das vor Jahren so programmiert haben. Hätten wir geahnt, dass wir 8 Jahre später über so eine Lapalie 2 Tage diskutieren werden, dann hätten wir damals schon zwei Tage über diesen Stolperstein nachgedacht. Dann gäbe es aber heute noch keine Druckvorschau.
-
Hallo Walter,
Das Problem ist offensichtlich, dass der Wert für "DefPrintBorder" bei Auswahl des Canon-Druckers nicht neu eingelesen wird.
...
Der Wert "50" für "DefPrintBorder" wird offensichtlich immer beim Neustart des Programms und Erstanlage der Ini-Datei eingefügt, egal ob unter Windows PDF oder Canon als Standard-Drucker eingestellt ist. Ist PDF der Standarddrucker, so hat die Vorschau eine Druckbereichsbegrenzung - falsch
Der Randabstand ist in Hauptsache ein Gestaltungsmittel für den Benutzer vergleichbar einem Passepartout und nicht eine Druckereigenschaft!
Er wird willkürlich mit dem Wert 5mm initialisiert und vom Benutzer eingestellt in dem Edit "Abstand zum Papierrand". Er wird nicht von einem Drucker eingelesen. Ein Drucker kann auch nicht wissen, welchen Abstand vom Rand ich einhalten möchte. Davon gibt es (wie oben bemerkt) eine Ausnahme: wenn man auf einen Drucker wechselt, der Randlosdruck meldet, dann setzen wir den Randabstand auf 0. Und wenn du diesen Zustand als Vorgabe speicherst, dann steht dort DefPrintBorder= 0, Das kann man bei jedem Drucker wieder ändern, auch beim pdf-Drucker, und auch als Vorgabewert ablegen.
Man kann auch für jeden Drucker ein oder mehrere Layouts anlegen. Da ist der vom Benutzer eingestellte Randabstand jeweils mit gespeichert. Vielleicht hilft es dir, wenn du den Druckerwechsel mit dem Aufruf eines Layouts vornimmst, anstatt ihn im Kombinationsfeld "Drucker" auszuwählen.
-
Mir ist aber aufgefallen, dass bei einem Wechsel von einem Hardware- zu einem PDF-Printer der Abstand zum Papierrand auf Null gesetzt wird.
Ich denke auch, dass dies das einzige ist, was man vielleicht als unlogisch ansehen kann. Dabei ist das als Hilfe gedacht, für die User, die sich mit den Fein-/Eigenheiten von Druckern nicht so auskennen. Ein Durchschnittsbenutzer merkt sonst eventuell gar nicht, dass er hier bis zum Rand drucken kann.
Beachte auch den Unterschied:
Der gestrichelte Rand zeigt den vom Benutzer eingestellten Abstand zum Papierrand an.
Die roten Ränder sind durch die Eigenschaften des Druckers vorgegeben. Diese erscheinen nur, wenn es Unstimmigkeiten gibt zwischen dem, was der Benutzer einstellt, und dem, was der Drucker kann.
-
Transparenzfarbe haben wir schon probiert. Im Allgemeinen ist das für unseren Außenrahmen unbrauchbar. In Spezialfällen geht es einigermaßen: Dazu muss der Rahmen wirklich einfarbig sein und darf keinen Schatten oder Schriftzug beinhalten. Bei runden Rahmen sorgt das Antialiasing für sichtbare Artefakte und, wenn du Pech hast, fehlen Teile im Inneren des Bilds.
Das ist ein Beispiel eines 3D-Rahmens mit runder Ecke und gänzlich ohne Schatten. Während die waagrechte und senkrechte Kante sauber sind, ergibt sich In der Rundung ein Farbsaum.
So etwas stellt uns nicht zufrieden.
-
Danke für die Analyse. Da muss ich mich erst damit befassen. Allerdings:
1. Ist ein Papierdrucker ausgewählt ... Die richtige Darstellung erhält man leider nur durch Neustart des Programms.
Ein "Zurück zur Vorgabe" genügt. Das liefert auch den vorher eingestellten Drucker. Oder du legst dir verschiedene Drucker-Layouts fest und wählst das entsprechende.
-
Wir haben uns entschieden, diese Anregung nicht weiter zu verfolgen. Für eine saubere Lösung in Zusammenhang mit Schatten, Rundung und ggf. Textaufschrift ist uns der Aufwand viel zu groß.
-
Deshalb ja auch meine Überlegung, ob es nicht möglich ist, einen transparenten Farbverlauf zu bestimmen
Ich bin mir nicht sicher, ob du dir das richtig vorstellst. So ein Schatten hat selber keine Farbe sondern nimmt die Farbe des Untergrunds an. Schatten auf einem grünen Rahmen ist grünlich. Jetzt soll der Rahmen aber transparent werden, dann soll der Schatten die Färbung des noch unbekannten, künftigen Hintergrunds widerspiegeln und nicht grünlich sein.
Möglich ist vieles. Wenn man es machen will.
-
Ich dachte halt, dass Transparenz eigentlich eine Standard-Eigenschaft von png-Dateien ist.
Das stimmt natürlich schon. Wobei die Transparenz mit "Transparenzfarbe" eher etwas für Grafiken, Cliparts, Word-Formen ... ist als für Bilder. Deine Überlegung, dass ein einfarbiger Bilderrahmen sich dafür auch eignen sollte, ist vollkommen richtig.
Das Problem scheint mir eher im Detail zu liegen:
a) Wenn wir beim Speichern die png-Datei mit Transparenzfarbe versehen wollen, stellt sich die Frage, wo definiere ich diese? Erst, nachdem der Speicherndialog mit dem Typ "*.png" mit "OK" verlassen wird in einem weiteren Dialog? Schon vorher auf der Rahmenregisterkarte, wo noch gar nicht feststeht, ob man als *.png speichern wird? Eine Option, wo die Farbe des äußeren Rahmen generell als Transparenzfarbe angehakt werden kann und die nur von Bedeutung ist, wenn man *.png speichert?
b) Wenn wir die Transparenzfarbe erst beim Mischen der Bilder festlegen, umgehen wir die vorigen Fragen. Was bleibt ist immer noch das Farbproblem, das durch das Skalieren entsteht.
c) Einen Alpha-Kanal zu beschreiben für den äußeren Rahmen ist ziemlicher Aufwand und letztlich unbefriedigend wegen des Schattenverlaufs und des Antialiasing, das bei den runden Ecken eingesetzt wird.
Da müssen wir noch drüber schlafen ...
-
Das hast du aber vermutlich durch Maskierung in einem anderen Programm gemacht und nicht mit einer Transparenzfarbe?
Der Umgang mit einer Transparenzfarbe hat folgendes Problem: Wenn man ein Bild größer oder kleiner skaliert (und das macht man in der Regel, wenn man es in ein anderes einfügt), dann werden die Farbwerte durch Interpolation ermittelt. Das bedeutet, dass Farbwerte nicht exakt beibehalten werden. Bei einem zunächst sauberen weißen Bildrand bekommst du beim Skalieren kleine Farbsäume und das stört natürlich, wenn man (255,255,255)-Pixel transparent machen möchte. Der saubere Rand ist dann ausgefranst.
-
Ich arbeite gerade an einem Büchlein über Wanderungen im Odenwald. Da lag die Verwendung nahe.
Weil die Transparenz aber auch über die Farbe bestimmt wird, werden die weißen Schriftfelder auch transparent geschaltet.
Vielleicht ist es möglich für den äußeren Rahmen eine andere Farbe zu verwenden als für den Schrifthintergrund.
Wenn es größere Probleme bereitet ...
Es ist halt schwierig ohne einen Alpha-Kanal zu erzeugen dem fertigen Bild mitzuteilen, was die Transparenzfarbe ist und dass bitte nur der Rahmen transparent werden soll.
Am einfachsten könnte ich mir vorstellen, beim Mischen der Bilder eine Pipette hinzuzufügen, mit der man eine Transparenzfarbe festlegen kann.
-
Wäre es sehr aufwändig, eine Funktion einzubauen, mit der man in *.png-Dateien eine Farbe transparent schalten könnte, z. B. weiß?
Danke für die Anregung!
Verstehe ich dich richtig:
Du möchtest beim Speichern eines Bilds als png-Grafik eine Farbe als transparent definieren können. Wenn man in einem anderen Bild diese Grafik als Mischbild hinzufügt, soll die Transparenz wirken.
Denkbar wäre auch der andere Fall:
Du möchtest beim Mischen eine Farbe des Mischbilds als transparent definieren.
Wie aufwändig das ist, kann ich noch nicht sagen. Da muss ich mich erst wieder in den Sachverhalt vertiefen.
Ein Problem jedenfalls wird der Schatten sein. In deinem Beispiel wurde der Schatten auf weißem Hintergrund erzeugt und ist deswegen grau. Über andersfarbigem oder verschiedenfarbigem oder unterschiedlich hellem Hintergrund kann das unstimmig sein.
-
Meine erste Idee ist, unsere neue Spline-Verformung so zu variieren, dass sie mit 4 vorgegebenen Punkten "vernünfig" arbeiten kann. Das würde aber nicht so schnell gehen, dass du mit deinem Projekt darauf warten kannst.
-
Wäre es denkbar mehr als zwei Punkte zu ermöglichen?
Interessante Frage!
Das würde bedeuten, dass das zweite Bild nicht nur wie bisher skaliert und ausgerichtet würde. Weitere Punkte würden dann eine Verzerrung implizieren. Mit 4 Punkten wäre dann eine perspektivische Verzerrung festgelegt. Mit 3 Punkten vielleicht eine Scherung. Mit mehr als 4 Punkten wäre das dann irgendetwas Unwirkliches.
Momentan habe ich keine Vorstellung, wie sich das realisieren ließe.
-
Eine nochmals aktualisierte Version 5.3.1.1 ist online.
- Leider hatte sich seit der Version 5.3.0.1 ein Fehler eingeschlichen: Beim Öffnen eines Bilds und bei "Reset" wurden die Gradationsparameter auf Standardwerte gestellt anstatt auf die Vorgabewerte der betreffenden Kamera. Wer also in den letzten 3 Wochen einen Download gemacht hat, sollte das am besten gleich nochmal tun.
- Wir haben die Installations-Skripte aktualisiert:
"install_jpgillu.vbs" erstellt jetzt Einträge im Kontextmenü des Explorers auch bei Dateien der Typen "*.jpeg" und "*.png". (Anregung von pixelfan) Dieses Skript kann man auch aufrufen, ohne vorher ji deinstalliert zu haben.
-
Übrigens die Angabe zur Lizenz (VI) ist so gut gelöst
Danke für deine Unterstützung!
-
Die Wieskirche im "Pfaffenwinkel"
-
Efeu im Garten
-
Die Ursache ist, dass obwohl die Scannerinfo eine Ausgabeauflösung von z.B. 300 dpi ausweist, Ji im Bildgrößendialog nur 296 dpi anzeigt.
Vermutlich liegt das daran, dass du das Bild im Twain-Treiber beschneidest, siehe Handbuch
Kap. 3.10.13. In diesem Fall sind wir nicht in der Lage, die dpi-Zahl korrekt zu ermitteln. Abhilfe: den Beschnitt erst in ji vornehmen oder eben die dpi-Zahl korrigieren.
