Hallo NoSi,
danke fürs lesen und die weiterführenden Fragen.
die Idee mit dem Verlinken ist ja nicht wirklich neu; das machen u.a. InDesign und Quark, man kann es bei Word und Konstorten einstellen.
Hab ich nicht behauptet. Ich hab diese Funktion in einem Programm namens ACDSee PhotoSlate sehr gerne benutzt und seitdem immer wieder hier zur Diskussion gebracht. "Gewaltige" Haken sehe ich überhaupt nicht. Besagtes Programm hat aber im System rumgepfuscht, nur deswegen hab ich es nicht mehr. Das Update hab ich mir nicht mehr angeschaut, wobei der PhotoManager 10 schon genial ist (und sich auch prima mit PL32 verträgt). Daher mein Wunsch nach Unterstützung externe Dateimanager. Der PL32 Browser ist praktisch, besonders für die Mehrfachkonvertierung, einen Bild Manager mit Datenbankfunktion kann (und muss!) er aber nicht ersetzen.
Wie stellst du sicher, dass wirklich immer und in jedem Fall die richtige Datei geladen wird?
Dateiname und Pfad. Eine gute Option wäre es dem Dokument eine Liste von Pfaden mitzugeben welche bei Bedarf geändert werden kann (=Dokument Variablen). Damit könnte ein Kalender blizschnell durch Änderung des Bildpfades mit neuen Bildern versorgt werden, vorausgesetzt die heissen dann auch z.b. 1.jpg ... 12.jpg
Aus Programmierersicht (ich bin so einer
) ist das trivial.
Die Ladezeit wird nur scheinbar kürzer, weil sie "verteilt" wird - in der Realität dauert es faktisch länger
Nur wenn sofort alle Bilder geladen würden. Sinn macht das ganze, wenn nur die Bilder für die benötigte Seite eines Dokuments geladen wird. Auch ist es insbesondere bei JPEG möglich, nur soviel Bilddaten wie benötigt zu laden. Für einen Kontaktabzug (bilder sind 5*3cm) muss nicht ein 6 Megapixel bild geladen werden, sondern das JPEG nur "angeladen" werden - änlich wie zur Erstellung(Anzeige von thumbnails (progressives laden).
Sehr schwer zu programmieren, aber denkbar ist auch das progessive laden der anderen Bilder während der Arbeit. Sinnvoll bei Mehr-CPU. Ich wage aber nicht sowas zu wünschen da es sehr komplex und fehler trächtig ist.
Besser wäre es man wählt einen Modus unter "Anzeige" um alle Bilder nur in geringer Qualität anzuzeigen und erst bei Druck wird die ganze Datei gezogen.
So kann man ein 32 Seiten Fotobuch öffnen, Bilder arangieren und drucken - ohne dass der Rechner schlapp macht.
Wie werden eingelinkte Bilder ggf. miteinander verknüpft, wenn Sie auf mehreren Ebenen unter/übereinander liegen, ohne wirklich da zu sein?
Das geht nicht und ist auch nicht nötig. Bildmanipulationen die über ein paar Grundoperationen hinausgehen können mit Arbeitsebenen realisiert werden. Malen oder radieren kann man in den Bildern also NICHT. Prinzipiell könnte man eine transparente Ebene drüberlegen, ich bräuchte das nicht bzw. würde dann eine echte Bildebene nehmen.
Wie sollen von dir genannte Einstellungen "virtuell" gespeichert werden? Und die müssen dann jedesmal "live" eingerechnet werden, was die Arbeitsgeschwindigkeit in den Keller zieht!
Ich würde "on the fly" eine Bildebene aus den geladenen Daten erstellen, bei der die genannten Operationen der Reihe nach ausgeführt werden. Für die weitere Anzeige ist das Objekt eine Bildebene und verhält sich auch so. Erst bei Änderung der Objekt Eigenschaften (ein Dialog mit Vorschau und OK/ABBRECHEN bietet sich an) wird das ganze wiederholt. Eine Verkleinerung der Bildebene wird im Dokument eingebettet (100*100 thumbnail)
Der Dialog könnte den Crop + Rotation anzeigen zuzüglich genannte Helligkeits / Kontrast Steuerung sowie eine einfache Schärfe Vorwahl. Das könnte ein paar Regler mit Presets sein, passt super zum derzeitigen Konzept.
Oben drüber steht dann den Pfad und der Name. Pfad ist eine Combo die auch genannte Dokumentenvariablen anzeigt. Der Dialog muss auch das draufziehen eines Bildes vom Dateimanager unterstützen.
Mein erster Vorschlag für den Dialog:
Anmerkungen:
a) Bei der Drehung wird von dem Bild in Querformat ausgegangen (egal welches Format es wirklich hat). Wenn ein hochkant Bild verlinkt wird, wird einfach die entsprechende Drehung (alsu "R") voreingestellt. Der Sinn ist, dass nachträgliche drehungen keine negative Auswirkung haben.
b) Die Feineinstellung wirkt auf das gekippte Bild um Linien geradezurichten.
c) Quelle Skalieren kann verwendet werden, um in einem kleineren Objekt ein grösseres Bild anzuzeigen. Diese Skalierung verändert aber die Bilddaten und die Auflösung der Arbeitsdaten. Sie macht Sinn, wenn das Objekt recht klein im Verhältnis der Bilddaten ist. Das Ergebnis dieser optionalen Skalierung und des Crops wird aber IMMER auf die Objektgrösse angepasst, unter Beibehaltung des Seitenverhältnisses. Ob Ränder gelassen werden oder beschnitten wird kann man unten wählen.
d) Helligkeit/Kontrast
Nur einfache Einstellungen sind Nötig. Komplizierte Sachen lassen sich über Arbeitsebenen lösen
e) Nachschärfen
Ist wichtig, wenn man die Skalierung gewählt hat. Man kann also auf 50% skalieren und dann etwas nachschärfen um klare Druckdaten zu bekommen.
f) Aktion
Ich habe noch eine Auswahlbox "Aktion" vorgesehen. Ob dies implementierbar ist weiss icht nicht. Gedacht ist letzendlich eine abschliessende Überarbeitung der Bilddaten. Crops und Drehung sowie ebeneneffkte gehen natürlich nicht.
e) Einpassen
Wie oben gesagt werden die Bilddaten immer skaliert. Hier kann man aber wählen, ob rand gelassen wird oder ausgeschnitten oder das Seitenverhältnis angepasst.
Das Rechteck (crop) spieglet das Seitenverhältnis des Objektes wieder. Wenn man es hier ändert (das seitenverhltnis) wird die Breite/Höhe des Objekts beim Beenden ensprechend angepasst. Normalerweise wird man das Rechteck aber nur skalieren und den Auschnitt wählen.
f) Effekte
öffnet die Effektauswahl für das Objetk. Man kann Schatten oder Umriss wählen.
«Hereinziehen/verlinken»: Immer notwendigerweise mit Pfaden. Damit ist dann eine Weitergabe des Dokuments unmöglich!
Weitergeben will ich mein Dokument gar nicht. Für den Druck könnte ich eine PDF erzeugen, da sind die Bilder dann drin. Oder es gibt eine Funktion zum erzeugen eines PL32 dokuments mit eingebetteten Bildern zusätzlich zu den Pfaden. Diese werden dann sattdessen genommen. Muss aber eine Option sein, sodass im Normalfall die Datei so klein wie möglich ist.
Externe Änderungen verändern dein PL-Dokument (kann nützlich sein, bei Bildern will man das aber im Regelfall eher nicht, insbesondere, wenn evtl. Korrekturen angewandt werden)
Wer sein externes Bild cropt, ist hier selber schuld. Anpassung der Belichtung (bzw. neuerstellung eines JPEG aus einem RAW) ist aber positiv. Dann wird die neue Version genommen. Der Anwender muss natürlich etwas den Überblick haben und wissen, dass seine Vorlage keine weiteren Helligkeitsänderungen vornimmt.
Erkennen könnte man aber die Änderung des Seitenverhältnisses bei einer Bilddatei, sodass dies unschädlich wäre.
Wird die externe Datei verschoben ist dein PL-Dokument "beschädigt"
Nicht beschädigt, nur nicht mehr komplett.
Als einfach Lösung könnte man dann den Dateinamen anzeigen, schöner wäre es o.g. Thumbnail anzuzeigen, sodass man sich die Datei wieder suchen kann.
Bei der Diskussion letzen Jahres wurde die Idee von einigen als interessant empfunden. Viele Leute lieben auch Ihre Photobücher und die PDF Ausgabe würde hier auch richtig Sinn machen.
Das Argument des evtl Datenverlust kann ich nicht gelten lassen, da dieser eigentlich immer vorkommen kann. Schon das Überspeichern eines JPEG mit 10% Kompression bedeutet quasi eines Verlustes der Daten. Im Grund beugt das Konzept gerade solchen Bendienfehlern vor und zwingt zur Verwendung von Arbeitsebenen zur verlustfreine Bildmanipulation! Auch die geringer Dateigrössen werden Datenverlusten vorbeugen, Bildverzeichnisse werden einfach nicht so schnell aufgebläht wenn die originaldaten nicht jedes mal eingebettet werden. Ein Photobuch mit 10 Bilder ist bereits jetzt unsäglich gross.
Ich sehe hier ein gewaltiges Potential neue Kunden zu begeistern - wogegen ich 64 Bit im Moment als weitesgehend uninteressant ist. Einfach weil es funktional nichts bringt, sondern bisher nur etliche Einschränkungen wie Programmfehler (anderer Programme, nicht PL32) und plugins ebenfalls 64bit sein müssen. Die Geschwindigkeitssteigerung könnte mit ein paar Optimierungen (vor allem cache) auch erreicht werden. 64bit ist nicht per se schneller, vor allem nicht wenn man mit byte daten arbeitet. Sinn macht 64bit bei Virtualisierung. Nur soviel zu meiner Einschätzung wie Programmierzeit sinnvoll aufgeteilt werden sollte.
Hoffe auf feedback,
Julian
Und für die Link-Ebenen bräuchte man das auch erstmal nicht.
Für meine Zwecke würde ein einfacher Link ins Dateisystem reichen, für Dein Problem mit dem Katalog wäre diese einfache Sache aber keine Lösung