Alle Jahre wieder - fange ich damit an
Platzhalter Objekte - damit meine ich vektor objekte welche den Inhalt von JPEG Dateien anzeigen.
Sie arbeiten dabei wie ein Fenster, bzw eine Linse welche über die JPEG an eine bestimmte Datei geschoben werden kann
Dabei soll es möglich sein
1) das unterliegende JPEG vor der Anzeige zu drehen
2) den Ausschnitt wählen
3) die Vergrösserung
4) Helligkeit + Kontrast
5) Adaptive Schärfe
6) durch Hereinziehen aus Programmen wie File- und Photomanager die Datei verlinken.
7) Wenn mehrere Dateien ins Fenster gezogen werden, werden die Plazhalter der Reihe nach gefüllt(!).
Andere Filter können bei Bedarf durch Arbeitsebenen realisiert werden. Das Objekt selber unterstützt die "Effekte", also Umrandung und Schatten.
Und was hat dies für einen Sinn???
- die original JPEG werden nicht verändert.
- das Projekt läd schnell, da alle Dateien nur Links sind. Die Links müssen erst beim ersten Anzeigen geladen werden, also bei mehrseitigen Fotobüchern erst viel später
- geringer Speicherbedarf für die Datei
- man kann sich eine Vorlage erstellen die dann nach Wunsch mit anderen Bildern gefüllt wird (z.b. Kalender). Daher ist (6) und (7) so wichtig
- schnellere Herstellung von Kontaktbögen (7)
Ich finde die Dokumenten Funktionen von PhotoLine sind wirklich toll, texte, vektoeren alles super. Aber, dass es derartigen Verlinkungen unterstützt ist echt eine Schande. Die Funktion "In Ebene laden" ist hier übrigens kein Ersatz, da das Bild ja permanent geladen wird.
Ich hoffe es finden sich hier ein paar Stimmen für diese Funktion, damit eine chance für die Implementierung besteht.
Viele Grüsse,
Julian
Version 5: Platzhalter Objekte
-
- Mitglied
- Posts: 736
- Joined: Tue 19 Dec 2006 19:54
- Location: München
-
- Betatester
- Posts: 1044
- Joined: Mon 07 Jan 2008 19:52
- Location: Birkenwerder / Berlin
Re: Version 5: Platzhalter Objekte
Hi Julian,
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. ABER: Die scheinbare Genialität dahinter hat ein paar ganz gewaltige Haken:
Grüße
NoSi
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. ABER: Die scheinbare Genialität dahinter hat ein paar ganz gewaltige Haken:
- Wie stellst du sicher, dass wirklich immer und in jedem Fall die richtige Datei geladen wird?
- Die Ladezeit wird nur scheinbar kürzer, weil sie "verteilt" wird - in der Realität dauert es faktisch länger
- Wie werden eingelinkte Bilder ggf. miteinander verknüpft, wenn Sie auf mehreren Ebenen unter/übereinander liegen, ohne wirklich da zu sein?
- 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!
- «Hereinziehen/verlinken»: Immer notwendigerweise mit Pfaden. Damit ist dann eine Weitergabe des Dokuments unmöglich!
- 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)
- Wird die externe Datei verschoben ist dein PL-Dokument "beschädigt"
Grüße
NoSi
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer die aktuellste Beta-Version.
-
- Mitglied
- Posts: 736
- Joined: Tue 19 Dec 2006 19:54
- Location: München
Re: Version 5: Platzhalter Objekte
Hallo NoSi,
danke fürs lesen und die weiterführenden Fragen.
Aus Programmierersicht (ich bin so einer ) ist das trivial.
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.
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.
Erkennen könnte man aber die Änderung des Seitenverhältnisses bei einer Bilddatei, sodass dies unschädlich wäre.
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
danke fürs lesen und die weiterführenden Fragen.
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.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.
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.jpgWie stellst du sicher, dass wirklich immer und in jedem Fall die richtige Datei geladen wird?
Aus Programmierersicht (ich bin so einer ) ist das trivial.
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).Die Ladezeit wird nur scheinbar kürzer, weil sie "verteilt" wird - in der Realität dauert es faktisch länger
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.
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 werden eingelinkte Bilder ggf. miteinander verknüpft, wenn Sie auf mehreren Ebenen unter/übereinander liegen, ohne wirklich da zu sein?
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)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!
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.
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.«Hereinziehen/verlinken»: Immer notwendigerweise mit Pfaden. Damit ist dann eine Weitergabe des Dokuments unmöglich!
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.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)
Erkennen könnte man aber die Änderung des Seitenverhältnisses bei einer Bilddatei, sodass dies unschädlich wäre.
Nicht beschädigt, nur nicht mehr komplett.Wird die externe Datei verschoben ist dein PL-Dokument "beschädigt"
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
Last edited by JulianZI on Fri 12 Sep 2008 10:00, edited 2 times in total.
-
- Betatester
- Posts: 4064
- Joined: Sun 03 Jul 2005 13:35
- Location: Mülheim/Ruhr
Re: Version 5: Platzhalter Objekte
Ich kann mich mit der Idee von Links auch immer mehr anfreunden.
Mein persönlicher Nutzen wäre, daß ich (wenn ich faule Sau schonmal richtig bastel) mir auch häufiger Kopien der Dateien mache. Da kommt schnell genug Masse zusammen, daß es auf meinem kleinen System eng wird. Und Ebenen austauschen wäre einfacher, die Quelle einer virtuellen Kopie ist/war ein bisschen "empfindlich", wenn man sie mit anderen Ebenen verbunden hat.
Und technisch sieht es für mich von aussen als Nichteingeweihter betrachtet auch nicht soo wild aus. So eine eingebundene Ebene müsste sich wie eine virtuelle Kopie verhalten, ein bisschen Attribut bekommen, und intern könnte das ja wie eine "unsichtbare" Quell-Ebene behandelt werden, die nicht mit gespeichert wird. Ob sich das bewährt, was es für Probleme gibt, wenn das z.B. Hintergrundebene ist, die Quelldatei verschwindet usw. könnte man ja in einer Beta testen, bevor man da großartig Arbeit reinsteckt.
Diese Wunder-Arbeitsebene zum Beschneiden, drehen, Farbsteuerung usw. würde auch zur Idee passen, Massen-Bildbearbeitung aus der Bildübersicht heraus für alle Arten von Dateien zu ermöglichen. Da will ich jetzt aber nicht weiter drauf rumreiten, die Menge der Ideen ist schliesslich unendlich Und für die Link-Ebenen bräuchte man das auch erstmal nicht.
Mein persönlicher Nutzen wäre, daß ich (wenn ich faule Sau schonmal richtig bastel) mir auch häufiger Kopien der Dateien mache. Da kommt schnell genug Masse zusammen, daß es auf meinem kleinen System eng wird. Und Ebenen austauschen wäre einfacher, die Quelle einer virtuellen Kopie ist/war ein bisschen "empfindlich", wenn man sie mit anderen Ebenen verbunden hat.
Und technisch sieht es für mich von aussen als Nichteingeweihter betrachtet auch nicht soo wild aus. So eine eingebundene Ebene müsste sich wie eine virtuelle Kopie verhalten, ein bisschen Attribut bekommen, und intern könnte das ja wie eine "unsichtbare" Quell-Ebene behandelt werden, die nicht mit gespeichert wird. Ob sich das bewährt, was es für Probleme gibt, wenn das z.B. Hintergrundebene ist, die Quelldatei verschwindet usw. könnte man ja in einer Beta testen, bevor man da großartig Arbeit reinsteckt.
Diese Wunder-Arbeitsebene zum Beschneiden, drehen, Farbsteuerung usw. würde auch zur Idee passen, Massen-Bildbearbeitung aus der Bildübersicht heraus für alle Arten von Dateien zu ermöglichen. Da will ich jetzt aber nicht weiter drauf rumreiten, die Menge der Ideen ist schliesslich unendlich Und für die Link-Ebenen bräuchte man das auch erstmal nicht.
-
- Mitglied
- Posts: 736
- Joined: Tue 19 Dec 2006 19:54
- Location: München
Re: Version 5: Platzhalter Objekte
Hallo Hoogo,
danke für den Post. Ich habe nun den Dialog oben verfeinert und entsprechende Anmerkungen nachgetragen.
Prinzipiell würde ich nur rudimentäre Bildberabeitung durch das Container Objekt zulassen. Sinn sind ja collagen und Fotobücher die damit schneller bearbeitet werden können bzw. automatisch aus Templates erstellt werden.
Viel wichtiger als die Bildbearbeitung sind hier die Möglichkieten anwenderfreundliche die Links zu setzen. Daher meine Idee:
Wenn in einem Templates mehrere leere Container sind (auch auf verschiedenen Seiten) wird das ziehen und ablegen mehrerer Dateine (aus Explorer z.b.) die Objekte der Reihe nach füllen.
Gut wäre hier noch eine Funktion um per Mausklick den Inhalt von 2 Objekten zu vertauschen oder den Inhalt zu löschen und die anderen, nachfolgenden Dateien rutschen nach.
Danke für Feedback,
Julian
danke für den Post. Ich habe nun den Dialog oben verfeinert und entsprechende Anmerkungen nachgetragen.
Prinzipiell würde ich nur rudimentäre Bildberabeitung durch das Container Objekt zulassen. Sinn sind ja collagen und Fotobücher die damit schneller bearbeitet werden können bzw. automatisch aus Templates erstellt werden.
Viel wichtiger als die Bildbearbeitung sind hier die Möglichkieten anwenderfreundliche die Links zu setzen. Daher meine Idee:
Wenn in einem Templates mehrere leere Container sind (auch auf verschiedenen Seiten) wird das ziehen und ablegen mehrerer Dateine (aus Explorer z.b.) die Objekte der Reihe nach füllen.
Gut wäre hier noch eine Funktion um per Mausklick den Inhalt von 2 Objekten zu vertauschen oder den Inhalt zu löschen und die anderen, nachfolgenden Dateien rutschen nach.
Danke für Feedback,
Julian
-
- Betatester
- Posts: 1044
- Joined: Mon 07 Jan 2008 19:52
- Location: Birkenwerder / Berlin
Re: Version 5: Platzhalter Objekte
Hi,
eine Bildbearbeitung, bei der nicht alles vom (angezeigten) Bild bearbeitet werden kann, bzw. bei der sich Elemente unterschiedlich verhalten: ist das für den Benutzer verstehbar? Reicht es nicht schon, dass Vektor- Bild- Verlauf,...-Ebenen unterschiedliche Strategien erfordern? Aber die kann man wenigstens logisch und praktisch verständlich unterscheiden. Warum jedoch ein Bild mal mit allem drum und dran, ein "anderes" (weil Extern) aber nur teilweise bearbeitet werden kann - woran erkenne ich das? Schaltet PL dann mal eben alle unbrauchbaren Funktionen aus? Kommen dann ständig «Geht nicht » Dialoge? Ist das überhaupt bedienbar?
Es hat durchaus Gründe, warum Quark und Indesign "eingelinkte" Bilder anzeigen, aber nicht relevant bearbeiten können. Aber da erwartet man das nicht - in einem Bildbearbeitungsprogramm wie PL dann aber doch. Sobald "Snapshots" gespeichert werden, um Bearbeitungsschritte in PL vorzuhalten, bekommt man das altbekannte Word-Problem: Sind die externen Quellen noch aktuell? "Pech gehabt" ist bei Fehlern (verschoben, verändert,...) keine akzeptable Antwort, weder aus Entwickler- noch aus Anwendersicht, denn hier wird die Tür zu "Unfällen" weitestmöglich aufgestoßen. Oder warum sind die Standards u.a. bei Word, OOffice, etc. so eingestellt, dass Bilder geladen und nicht verlinkt werden???
So nett das theoretisch klingt: In der Praxis wird es kaum jemand nutzen. Ich würde als PL-Entwickler meine Zeit anders in das Produkt investieren. Statt immer komplexerer Funktionen sollten die vorhandenen (z.T.) intuitiver erreich- und nutzbar werden, die Anordnungen im Programm sind "gewachsen" und könnten im Rahmen einer "15" evtl. mal reorganisiert werden, etc. . PL kann schon so viel, aber nur so wenige wissen davon bzw. können es nutzen - das ist imho bzgl. Kundennutzen und -bindung/-gewinnung momentan die größere Herausforderung!
Grüße
NoSi
P.S. Ich bin ebenfalls Entwickler, meine (Spezial-)Programme kommen u.a. bei Verlagen, Autohäusern, Unis, Unternehmen, zum Einsatz. Die sind zwar nicht ansatzweise so komplex wie PL, aber ich investiere sehr viel Mühe in den Anspruch, dass sie selbst für einen DAU ohne Anleitung intuitiv bedienbar sind. Die Reaktionen der Kunden zeigen, dass ich das wohl ganz ordentlich hinbekomme. Wie viel ein Programm wirklich kann, hängt davon ab, was der Benutzer damit hinbekommt. Dabei gehe ich davon aus, dass die Bereitschaft zum Lesen von Hilfen, etc. gegen null geht und beim "rumprobieren" das Interesse bei Erfolglosigkeit mit jeder Minute länger exponentiell nachlässt (Anfängerproblematik). Die tollste Funktion ist für den "Poweruser" nichts wert, wenn sie nicht stressfrei auch nach 3 Monaten Nichtnutzung bedient werden kann. Zwangsläufig hat das "natürliche" Grenzen (von nix kommt nix...), aber das sollte immer im Augenwinkel sein. Denn gerade bei PL kommt noch eine wichtige Komponente dazu: Das Überleben des Produkts ist bei diesem Marktpreis dramatisch von verkauften Stückzahlen abhängig. Je mehr das Programm also gut, zielsicher und mühelos einsetzen können (ggf. nur 10% der Funktionen, aber die souverän), desto besser ist das für alle Beteiligten.
eine Bildbearbeitung, bei der nicht alles vom (angezeigten) Bild bearbeitet werden kann, bzw. bei der sich Elemente unterschiedlich verhalten: ist das für den Benutzer verstehbar? Reicht es nicht schon, dass Vektor- Bild- Verlauf,...-Ebenen unterschiedliche Strategien erfordern? Aber die kann man wenigstens logisch und praktisch verständlich unterscheiden. Warum jedoch ein Bild mal mit allem drum und dran, ein "anderes" (weil Extern) aber nur teilweise bearbeitet werden kann - woran erkenne ich das? Schaltet PL dann mal eben alle unbrauchbaren Funktionen aus? Kommen dann ständig «Geht nicht » Dialoge? Ist das überhaupt bedienbar?
Es hat durchaus Gründe, warum Quark und Indesign "eingelinkte" Bilder anzeigen, aber nicht relevant bearbeiten können. Aber da erwartet man das nicht - in einem Bildbearbeitungsprogramm wie PL dann aber doch. Sobald "Snapshots" gespeichert werden, um Bearbeitungsschritte in PL vorzuhalten, bekommt man das altbekannte Word-Problem: Sind die externen Quellen noch aktuell? "Pech gehabt" ist bei Fehlern (verschoben, verändert,...) keine akzeptable Antwort, weder aus Entwickler- noch aus Anwendersicht, denn hier wird die Tür zu "Unfällen" weitestmöglich aufgestoßen. Oder warum sind die Standards u.a. bei Word, OOffice, etc. so eingestellt, dass Bilder geladen und nicht verlinkt werden???
So nett das theoretisch klingt: In der Praxis wird es kaum jemand nutzen. Ich würde als PL-Entwickler meine Zeit anders in das Produkt investieren. Statt immer komplexerer Funktionen sollten die vorhandenen (z.T.) intuitiver erreich- und nutzbar werden, die Anordnungen im Programm sind "gewachsen" und könnten im Rahmen einer "15" evtl. mal reorganisiert werden, etc. . PL kann schon so viel, aber nur so wenige wissen davon bzw. können es nutzen - das ist imho bzgl. Kundennutzen und -bindung/-gewinnung momentan die größere Herausforderung!
Grüße
NoSi
P.S. Ich bin ebenfalls Entwickler, meine (Spezial-)Programme kommen u.a. bei Verlagen, Autohäusern, Unis, Unternehmen, zum Einsatz. Die sind zwar nicht ansatzweise so komplex wie PL, aber ich investiere sehr viel Mühe in den Anspruch, dass sie selbst für einen DAU ohne Anleitung intuitiv bedienbar sind. Die Reaktionen der Kunden zeigen, dass ich das wohl ganz ordentlich hinbekomme. Wie viel ein Programm wirklich kann, hängt davon ab, was der Benutzer damit hinbekommt. Dabei gehe ich davon aus, dass die Bereitschaft zum Lesen von Hilfen, etc. gegen null geht und beim "rumprobieren" das Interesse bei Erfolglosigkeit mit jeder Minute länger exponentiell nachlässt (Anfängerproblematik). Die tollste Funktion ist für den "Poweruser" nichts wert, wenn sie nicht stressfrei auch nach 3 Monaten Nichtnutzung bedient werden kann. Zwangsläufig hat das "natürliche" Grenzen (von nix kommt nix...), aber das sollte immer im Augenwinkel sein. Denn gerade bei PL kommt noch eine wichtige Komponente dazu: Das Überleben des Produkts ist bei diesem Marktpreis dramatisch von verkauften Stückzahlen abhängig. Je mehr das Programm also gut, zielsicher und mühelos einsetzen können (ggf. nur 10% der Funktionen, aber die souverän), desto besser ist das für alle Beteiligten.
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer die aktuellste Beta-Version.
-
- Entwickler
- Posts: 4232
- Joined: Tue 19 Nov 2002 15:49
Re: Version 5: Platzhalter Objekte
Hallo,
von mir nur ein kleiner Kommentar zu den 64-Bit:
Unter Mac OS stellt sich das anders dar: da ist mittlerweile ein großer Teil der Anwender in der Lage, 64 Bit-Software einzusetzen. Und mit der nächsten OS-Version wird es meiner Ansicht nach ein entscheidender Nachteil sein (zumindest für kleine Anbieter wie uns, bei "Großen" wird oft mehr verziehen), wenn man 64-Bit nicht anbietet.
Caches sind zweischneidig. Gerade bei knappem Speicher können sie das Programm auch extrem langsam machen.
Martin
von mir nur ein kleiner Kommentar zu den 64-Bit:
Unter Windows gebe ich dir recht: für den normalen Anwender ist 64-Bit momentan uninteressant, da kaum jemand ein ein 64-Bit-Windows hat.JulianZI wrote:Ich sehe hier ein gewaltiges Potential neue Kunden zu begeistern - wogegen ich 64 Bit im Moment als weitesgehend uninteressant ist.
Unter Mac OS stellt sich das anders dar: da ist mittlerweile ein großer Teil der Anwender in der Lage, 64 Bit-Software einzusetzen. Und mit der nächsten OS-Version wird es meiner Ansicht nach ein entscheidender Nachteil sein (zumindest für kleine Anbieter wie uns, bei "Großen" wird oft mehr verziehen), wenn man 64-Bit nicht anbietet.
Das ist definitiv ein Nachteil.JulianZI wrote: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.
PhotoLine wurde unter Intel schätzungsweise 15% schneller ohne eine spezielle Optimierung, weil unter 64-Bit mehr Register zur Verfügung stehen.JulianZI wrote: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.
Caches sind zweischneidig. Gerade bei knappem Speicher können sie das Programm auch extrem langsam machen.
Die eigentliche 64-Bit-Version kostete kaum Arbeitszeit. Was aufwendig war, waren die nötigen Vorarbeiten. Unter Windows war das der Wechsel auf einen neuen Compiler mit neuen Bibliotheken, und unter Mac OS war das die Entfernung der letzten "Altlasten". Beides waren Arbeiten, die wir früher oder später sowieso machen mussten (unter Windows evtl. später, und unter Mac OS eher früher).JulianZI wrote:Sinn macht 64bit bei Virtualisierung. Nur soviel zu meiner Einschätzung wie Programmierzeit sinnvoll aufgeteilt werden sollte.
Martin
-
- Mitglied
- Posts: 736
- Joined: Tue 19 Dec 2006 19:54
- Location: München
Re: Version 5: Platzhalter Objekte
Hallo,
Und was den Sinn der Platzhalter betrifft - die Funktion "Bildkatalog erzeugen" führt bei der Einbettung von lediglich 64 Bildern (auf 3 seiten) bereits zu einer Datei von 185MB und das Programm hängt sich beim Abspeichern fast auf. Bei Verwendung der oben genannten Platzhalter, insbesondere unter Verwendung des Konzepts des progressiven Laden der JPEG, bliebe das Programm bedienbar und Laden und Speichern ginge ordentlich schnell. Damit könnte man eine solches Dokument noch bearbeiten, was bei kompletter Einbettung wirklich keinen Spass macht.
Das Konzept wäre ja nur im Dokumenten Modus aktiv - im Bildmodus macht es gar keinen Sinn und wäre nicht verfügbar. Damit wäre dem Anwender auch klar wann er/sie was erwarten kann. Man kann also ein Bild aus dem RAW entwickeln, verändern und dann als TIFF oder JPEG unter einem anderen Namen ablegen. Diese Kopie dann in beliebigen Dokumenten unter Verwendung der Platzhalter verwenden, für den Ausdruck oder die Erstellung von Bestell JPEG bzw PDF Dateien die dann irgendwo hochgeladen werden. Zur Zeit bin ich gezwungen die Platte mit redundanten Daten zu füllen. Das ist ein Problem wenn man noch kontrolliert Backups machen möchte.
PhotoLine hat so tolle Textmöglichkeiten, im Moment macht deren Verwendung aber keinen Spass, wenn das Dokument viele Seiten hat und entsprechend viele Bilder eingebettet sind. Weil alle Bilddaten mitgespeichert werden, werden die PLDs riesig gross und man füllt die Platte wenn man backup/versions Kopien macht. Alles kein Problem bei Platzhaltern.
Viele Grüsse,
Julian
Besagte Platzhalterobjekte würden sich wie Vektorebenen verhalten. Dies gegenüber dem User aber auch von der Programmierung her, soweit ich das sehe. Dies schliesst sogar die Umrandung ein, welche man auch barbeiten könnte. Die Füllung der Graphik ist einfach das externe Bild nach besagtem Crop + Skalierung. Ich sehe hier keinen Konzeptbruch, wirklich nicht. Und grossen Programmieraufwand auch nicht, da alles schon da ist. Nur das progressive JPEG laden, bzw. das Update nach dem Seitenwechsel bzw. vor dem Druck.NoSi wrote:eine Bildbearbeitung, bei der nicht alles vom (angezeigten) Bild bearbeitet werden kann, bzw. bei der sich Elemente unterschiedlich verhalten: ist das für den Benutzer verstehbar? Reicht es nicht schon, dass Vektor- Bild- Verlauf,...-Ebenen unterschiedliche Strategien erfordern? Aber die kann man wenigstens logisch und praktisch verständlich unterscheiden. Warum jedoch ein Bild mal mit allem drum und dran, ein "anderes" (weil Extern) aber nur teilweise bearbeitet werden kann - woran erkenne ich das? Schaltet PL dann mal eben alle unbrauchbaren Funktionen aus? Kommen dann ständig «Geht nicht » Dialoge? Ist das überhaupt bedienbar?
Und was den Sinn der Platzhalter betrifft - die Funktion "Bildkatalog erzeugen" führt bei der Einbettung von lediglich 64 Bildern (auf 3 seiten) bereits zu einer Datei von 185MB und das Programm hängt sich beim Abspeichern fast auf. Bei Verwendung der oben genannten Platzhalter, insbesondere unter Verwendung des Konzepts des progressiven Laden der JPEG, bliebe das Programm bedienbar und Laden und Speichern ginge ordentlich schnell. Damit könnte man eine solches Dokument noch bearbeiten, was bei kompletter Einbettung wirklich keinen Spass macht.
Das Konzept wäre ja nur im Dokumenten Modus aktiv - im Bildmodus macht es gar keinen Sinn und wäre nicht verfügbar. Damit wäre dem Anwender auch klar wann er/sie was erwarten kann. Man kann also ein Bild aus dem RAW entwickeln, verändern und dann als TIFF oder JPEG unter einem anderen Namen ablegen. Diese Kopie dann in beliebigen Dokumenten unter Verwendung der Platzhalter verwenden, für den Ausdruck oder die Erstellung von Bestell JPEG bzw PDF Dateien die dann irgendwo hochgeladen werden. Zur Zeit bin ich gezwungen die Platte mit redundanten Daten zu füllen. Das ist ein Problem wenn man noch kontrolliert Backups machen möchte.
PhotoLine hat so tolle Textmöglichkeiten, im Moment macht deren Verwendung aber keinen Spass, wenn das Dokument viele Seiten hat und entsprechend viele Bilder eingebettet sind. Weil alle Bilddaten mitgespeichert werden, werden die PLDs riesig gross und man füllt die Platte wenn man backup/versions Kopien macht. Alles kein Problem bei Platzhaltern.
Das sehe ich genauso - oben abgebildeter Dialog sollte aber ausreichend intuitiv sein. Wie gesagt, ich sehe als Zielgruppe nicht die User welche täglich den Hochpass einsetzen, sondern diejenigen, die ein Photobuch zusammen klicken wollen. Und dies soll vor allem schnell gehen und das Programm soll dabei flink reagieren. Im Moment ist das nicht so, auch bei 2GB RAM nicht.NoSi wrote:Wie viel ein Programm wirklich kann, hängt davon ab, was der Benutzer damit hinbekommt. Dabei gehe ich davon aus, dass die Bereitschaft zum Lesen von Hilfen, etc. gegen null geht und beim "rumprobieren" das Interesse bei Erfolglosigkeit mit jeder Minute länger exponentiell nachlässt (Anfängerproblematik). Die tollste Funktion ist für den "Poweruser" nichts wert, wenn sie nicht stressfrei auch nach 3 Monaten Nichtnutzung bedient werden kann.
Wenn es keine grosse extra Mühen macht, ist "64 Bit ready" sicher ein gutes marketing label. Unter diesem Aspekt positiv. Oben genannte Platzhalter machen aber buchstäblich ein neues Kapitel auf und ich sehe schon den Artikel in FotoHits oder c't welcher nur dieses Feature behandelt. Ich denke der Aufwand wird vergleichsweise gering sein, vielleicht eine Woche für den Prototyp, aber der Effekt - wow. Ihr würdet Euch damit auch von der Menge der Bildbearbeitungstools absetzen und Euerem Dokumentenmodus Leben einhauchen. Das meiste ist ja bereits da.Martin Huber wrote:PhotoLine wurde unter Intel schätzungsweise 15% schneller ohne eine spezielle Optimierung, weil unter 64-Bit mehr Register zur Verfügung stehen.
Caches sind zweischneidig. Gerade bei knappem Speicher können sie das Programm auch extrem langsam machen.
Viele Grüsse,
Julian
-
- Mitglied
- Posts: 736
- Joined: Tue 19 Dec 2006 19:54
- Location: München
Re: Version 5: Platzhalter Objekte
So könnte es aussehen, wenn man sich eine Vorlage gebastelt oder einen Reisebericht verfasst hat, und diesen dann am Ende mit Bildern versieht.
Die Blockade gegen diese Idee kann ich nicht verstehen. Die aktuelle Implementierung, mit immer eingebetteten Bildern, lässt ein vernüftiges Bearbeiten eines mehrseitigen Dokuments nicht mehr zu, sobald es zuviele Bilder sind (bei mir: 64 auf 3 Seiten). Da machen dann auch der tolle Textumfluss und die verbundenen Textspalten keinen Spass mehr.
Mit diesem Konzept könntet Ihr einen Dialog anbieten, der mit ein paar Klicks ein rudimentäres Photobuch erstellt. (ähnlich dem Kontaktbogen). Sowas werden die Anwender gerne nutzen.
Ich verstehe ich nicht, wieso dies einen so hohen Programmieraufwand mit sich brächte. Immerhin können Vektorebenen bereits jetzt mit Bilddaten "gefüllt" werden. Gegenüber dem, was PL32 sonst so kann, ist dies wirklich ein Klacks.
Ich bitte daher sehr darum, die Idee zumindest provisorisch zu verwirklichen, um den Aufwand und den Nutzen abzuschätzen. Vielleicht auch jemanden fragen, der nicht der typische Bildberabeiter ist. Jemanden, der seine Bilder einfach nur präsentieren will.
Herzliche Grüsse,
Julian
Die Blockade gegen diese Idee kann ich nicht verstehen. Die aktuelle Implementierung, mit immer eingebetteten Bildern, lässt ein vernüftiges Bearbeiten eines mehrseitigen Dokuments nicht mehr zu, sobald es zuviele Bilder sind (bei mir: 64 auf 3 Seiten). Da machen dann auch der tolle Textumfluss und die verbundenen Textspalten keinen Spass mehr.
Mit diesem Konzept könntet Ihr einen Dialog anbieten, der mit ein paar Klicks ein rudimentäres Photobuch erstellt. (ähnlich dem Kontaktbogen). Sowas werden die Anwender gerne nutzen.
Ich verstehe ich nicht, wieso dies einen so hohen Programmieraufwand mit sich brächte. Immerhin können Vektorebenen bereits jetzt mit Bilddaten "gefüllt" werden. Gegenüber dem, was PL32 sonst so kann, ist dies wirklich ein Klacks.
Ich bitte daher sehr darum, die Idee zumindest provisorisch zu verwirklichen, um den Aufwand und den Nutzen abzuschätzen. Vielleicht auch jemanden fragen, der nicht der typische Bildberabeiter ist. Jemanden, der seine Bilder einfach nur präsentieren will.
Herzliche Grüsse,
Julian
-
- Mitglied
- Posts: 364
- Joined: Thu 12 Jul 2007 17:16
- Location: Wien, Austria
Re: Version 5: Platzhalter Objekte
Mir gefällt die Idee sehr, dies zu integrieren. Das ist ja ein Standardfeature der 'großen' DTP-Programme, das Arbeiten mit Platzhaltern, das tatsächliche Bild bleibt verschiebbar, skalierbar, bearbeitbar, austauschbar etc.
Es ist ja ziemlich aufregend, dass PhotoLine einen so großen Bogen über Bildbearbeitung, DTP und Vektorgrafik spannt, und Ziele oft auch unerwartet schnell erreicht. Ich denke nur z.B. an die Bearbeitung sehr großer Bilddateien (800 MB +): vor einiger Zeit hatte ich das thematisiert, weil ich Probleme mit Panorama-Renderings hatte. Die Entwickler haben das sogleich aufgegriffen, und sehr kurze Zeit später war die Fähigkeit, auch noch viel größere Dateien darzustellen und zu bearbeiten in PhotoLine integriert.
Das war unglaublich!
Wer weiss also, wie sich die Sache mit den verknüpften Bildern noch entwickelt...
Im Augenblick scheint es allerdings wenig Spielraum für neue Features (so wie dieses), oder auch für Usability-Verbesserungen, die einen größeren Programmieraufwand benötigen, zu geben (z.B. Scrollbar und/oder Tabs für Dialoge, wie z.B. bei Lightroom, Bibble, RawTherapee).
Aber wenn das aktuelle 64-Bit-Ziel erreicht ist, wer weiss, was danach noch alles möglich ist...!
Michael
Es ist ja ziemlich aufregend, dass PhotoLine einen so großen Bogen über Bildbearbeitung, DTP und Vektorgrafik spannt, und Ziele oft auch unerwartet schnell erreicht. Ich denke nur z.B. an die Bearbeitung sehr großer Bilddateien (800 MB +): vor einiger Zeit hatte ich das thematisiert, weil ich Probleme mit Panorama-Renderings hatte. Die Entwickler haben das sogleich aufgegriffen, und sehr kurze Zeit später war die Fähigkeit, auch noch viel größere Dateien darzustellen und zu bearbeiten in PhotoLine integriert.
Das war unglaublich!
Wer weiss also, wie sich die Sache mit den verknüpften Bildern noch entwickelt...
Im Augenblick scheint es allerdings wenig Spielraum für neue Features (so wie dieses), oder auch für Usability-Verbesserungen, die einen größeren Programmieraufwand benötigen, zu geben (z.B. Scrollbar und/oder Tabs für Dialoge, wie z.B. bei Lightroom, Bibble, RawTherapee).
Aber wenn das aktuelle 64-Bit-Ziel erreicht ist, wer weiss, was danach noch alles möglich ist...!
Michael
-
- Betatester
- Posts: 1044
- Joined: Mon 07 Jan 2008 19:52
- Location: Birkenwerder / Berlin
Re: Version 5: Platzhalter Objekte
Auf was für einem Rechner? Ich habe schon ganz andere Dokumente mit diversen Bildern um Umflüssen erstellt und hatte nicht das Gefühl, dass mich PL signifikant ausbremst. Zumindest ging es immer deutlich flotter, als mit den angeblich professionell(er)en Alternativen von Quark und Adobe. Ich habe sogar schon Aufträge aus Indesign rausgenommen und mit PL erledigt, weil damit hat es geklappt, während Indesign sich einen Wolf geladen hat... .JulianZI wrote:Die Blockade gegen diese Idee kann ich nicht verstehen. Die aktuelle Implementierung, mit immer eingebetteten Bildern, lässt ein vernüftiges Bearbeiten eines mehrseitigen Dokuments nicht mehr zu, sobald es zuviele Bilder sind (bei mir: 64 auf 3 Seiten). Da machen dann auch der tolle Textumfluss und die verbundenen Textspalten keinen Spass mehr.
Grüße
NoSi
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer die aktuellste Beta-Version.
-
- Mitglied
- Posts: 736
- Joined: Tue 19 Dec 2006 19:54
- Location: München
Re: Version 5: Platzhalter Objekte
Hallo,
Für einen nuen Test hab ich einfach die Katalogfunktion aus dem Dateibrowser verwendet und ein Verzeichnis mit 64 Dateien, mit jeweils (nur) 4.6 MegaPixel geladen.
Erstellung des Katalogs dauerte ungefähr 10 sek
Wechsel von Seite 1 auf Seite 2 ca 6 sek
1. Abspeichern als PLD 15 sek und die Datei ist 256MB gross
2. Abspeichern als PLD 13 sek
Das Wechseln von Seite zu Seite und zurück dauert sehr lange wenn viele Bilder auf der Seite sind. Kann es sein, dass hier die Bilder immer neu dekodiert werden. Damit passiert ja schon dies was ich vorheschlagen habe, nur dass ich es vorziehen würde wenn die Daten aus externen Dateien geladen würden. Damit könnte man in kleine Projekt Dateien speichern.
Der Vorschlag des progressiven Ladens eines JPEG soll bitte nicht untergehen. Für die Anzeige am Bildschirm reicht es wirklich, wenn die JPEG nur soweit wie nötig geladen werden. Dann wird die Anzeige und der Seitenwechsel richtig flink werden.
Das Konzept wird ganz entscheidend zur Datensicherheit beitragen, da die Dateien kleiner sind und schneller Speichern. Somit kann man öffters speichern und auch mehrere Versionen.
Ob "Alternativen von Quark und Adobe" schneller oder langsamer sind kann ich nicht sagen. ACDSee PhotoSlate ist aber auf jeden Fall sehr viel schneller, und dies auch wenn man 300 Bilder in eine Übersicht druckt. Auch andere Programme bieten heute eine Druckfunktion in der logische Kopien der Bilder ausgegeben werden, z.b. Picasa welches für jedes Bild ein paar Manipulationen speichert. Nichts anderes würde der Platzhalter auch tun, das original Bild nehmen und nach ein paar Manipulationen ausgeben. Weder muss das Originalbild verändert werden, noch werden (eingebettete) Kopien angelegt.
Übrigens, das Konzept würde sich auch gut eignen alle Bilder eines Verzeichnisses einzeln in einem bestimmten Format (Seitengrösse, Rahmen etc) zu drucken. Dafür Liste von Dateien in Dokument ziehen, die Bilder füllen die Platzhalter und die letzte Seite wird solange dupliziert solange Dateien in der List sind. Sprich 1* drag&drop anstatt X Seiten erstellen, auf jede Seite ein Bild ziehen, jedes Bild skalieren und positionieren etc.
Grüsse,
Julian
Ich habe eine Core Duo 2.4G mit 2GB RAM.Auf was für einem Rechner?
Für einen nuen Test hab ich einfach die Katalogfunktion aus dem Dateibrowser verwendet und ein Verzeichnis mit 64 Dateien, mit jeweils (nur) 4.6 MegaPixel geladen.
Erstellung des Katalogs dauerte ungefähr 10 sek
Wechsel von Seite 1 auf Seite 2 ca 6 sek
1. Abspeichern als PLD 15 sek und die Datei ist 256MB gross
2. Abspeichern als PLD 13 sek
Das Wechseln von Seite zu Seite und zurück dauert sehr lange wenn viele Bilder auf der Seite sind. Kann es sein, dass hier die Bilder immer neu dekodiert werden. Damit passiert ja schon dies was ich vorheschlagen habe, nur dass ich es vorziehen würde wenn die Daten aus externen Dateien geladen würden. Damit könnte man in kleine Projekt Dateien speichern.
Der Vorschlag des progressiven Ladens eines JPEG soll bitte nicht untergehen. Für die Anzeige am Bildschirm reicht es wirklich, wenn die JPEG nur soweit wie nötig geladen werden. Dann wird die Anzeige und der Seitenwechsel richtig flink werden.
Das Konzept wird ganz entscheidend zur Datensicherheit beitragen, da die Dateien kleiner sind und schneller Speichern. Somit kann man öffters speichern und auch mehrere Versionen.
Ob "Alternativen von Quark und Adobe" schneller oder langsamer sind kann ich nicht sagen. ACDSee PhotoSlate ist aber auf jeden Fall sehr viel schneller, und dies auch wenn man 300 Bilder in eine Übersicht druckt. Auch andere Programme bieten heute eine Druckfunktion in der logische Kopien der Bilder ausgegeben werden, z.b. Picasa welches für jedes Bild ein paar Manipulationen speichert. Nichts anderes würde der Platzhalter auch tun, das original Bild nehmen und nach ein paar Manipulationen ausgeben. Weder muss das Originalbild verändert werden, noch werden (eingebettete) Kopien angelegt.
Übrigens, das Konzept würde sich auch gut eignen alle Bilder eines Verzeichnisses einzeln in einem bestimmten Format (Seitengrösse, Rahmen etc) zu drucken. Dafür Liste von Dateien in Dokument ziehen, die Bilder füllen die Platzhalter und die letzte Seite wird solange dupliziert solange Dateien in der List sind. Sprich 1* drag&drop anstatt X Seiten erstellen, auf jede Seite ein Bild ziehen, jedes Bild skalieren und positionieren etc.
Grüsse,
Julian
-
- Betatester
- Posts: 4064
- Joined: Sun 03 Jul 2005 13:35
- Location: Mülheim/Ruhr
Re: Version 5: Platzhalter Objekte
Hab den Bildkatalog noch nie ausprobiert. Sieht aber so aus, als ob die Originalbilder in voller Auflösung eingebunden würden. Vielleicht machen das die schnellen Programme anders? Oder gibt es da beim Bildkatalog eine Option, den Kram runterzurechnen?
-
- Mitglied
- Posts: 736
- Joined: Tue 19 Dec 2006 19:54
- Location: München
Re: Version 5: Platzhalter Objekte
Es gibt die Möglichkeit nur die Vorschau einzubinden. Das ist dann richtig flott. Bei JPEG würde es sich noch anbieten die Datei zu 1/1, 1/2 bzw 1/4 bzw 1/8 zu laden. Das geht mit den meisten JPEG Dateien. Prinzipiell muss ja nur soviel Daten geladen werden wie für einen 300dpi Ausdruck erforderlich sind. Für den Bildschirm wären nur Daten für 96dpi erforderlich, wenn es Platzhalter gäbe, könnte man für den Druck noch nachladen.Hab den Bildkatalog noch nie ausprobiert. Sieht aber so aus, als ob die Originalbilder in voller Auflösung eingebunden würden. Vielleicht machen das die schnellen Programme anders? Oder gibt es da beim Bildkatalog eine Option, den Kram runterzurechnen?
Im Moment macht es für den Katalog eine riesen Unterschied wieviel Megapixel die Dateien haben - die Grösser der JPEG ist hingegend egal.
4.6MP (DP1 Dateien) brauch nur in etwa 13.8MB pro Bild, wogegen es bei der D300 über 36MB sind. Da sind bei 60 Dateien dann 2GB voll und Schluss ist.
Ich wiederhol mich - mit Platzhaltern wären auch 300 Bilder in einem Katalog kein Problem.
Sorry, dass ich so nerve - ich sehe hier einfach die Chance für Photoline populär zu werden. Es gibt ja vielfältigste Bildbearbeitunge, sogar Picassa macht einige Sachen richtig gut (Automatischer Weissabgleich und die non-destruktive Änderungen). Aber so richtig gut drucken und dann noch tolle Sachen wie Arbeitsebenen und Vektor Effekte, das findet man nicht.
Grüsse,
Julian
-
- Betatester
- Posts: 4064
- Joined: Sun 03 Jul 2005 13:35
- Location: Mülheim/Ruhr
Re: Version 5: Platzhalter Objekte
Hm... Ne, ich vermute, das wäre in der Praxis doch nicht so ohne NebenwirkungenJulianZI wrote:Ich wiederhol mich - mit Platzhaltern wären auch 300 Bilder in einem Katalog kein Problem.
Zur Darstellung auf dem Bildschirm, zum Verrechnen mit weiteren Ebenen usw. muß das Programm ja doch irgendwie an die Daten ran, und dazu hat man die doch besser im Speicher, als daß bei jedem! Klick auf ein Ebenensymbol oder jeder! Aktion alle eingebetteten Bilder von der Platte geholt, decodiert usw... werden müssten.
Jetzt könnte man ja sagen "egal, wird für die Bildschirmanzeige ein Bild im Speicher gehalten, was der Bildschirmauflösung entspricht, komplett wird nur bei Zoom >100% und Bedarf geladen". Dann kracht es plötzlich wenn jemand 20 100MPx-Ebenen übereinanderlegt. Oder Arbeitsebenen mit Radius wollen nicht mehr richtig arbeiten. Oder es tauchen komische Ränder auf, wenn Ebenen nur noch mit verringerter Auflösung durchgerechnet werden. Oder weiß der Geier, was sonst noch so im Detail alles passieren kann.
Ich denke, das derart perfekt zu machen, daß man mehr Bilder einbetten und gescheit bearbeiten kann, als in den Speicher passen, macht viele Experimente, Überlegungen und Fehlschläge nötig, und am Ende würde man alles wegwerfen müssen, was man bisher schon so hatte. Ich denke, daß die Adobe-Experimente zu den Gigapixel-Bildern in diese Richtung gehen, und davon wird man in CS5 bestimmt noch nichts sehen.
Ist aber alles nur spannendes Kristallkugellesen 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