Version 5: Platzhalter Objekte

[JulianZI]

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".

Das 100% nachladen halte ich nicht für wichtig. Für das Arrangieren reicht das kleine Bild total. Es ist nur wichtig, dass beim Ausdruck bzw. Export nach PDF oder JPEG das ganze Bild geladen wird. Nachladen macht Sinn nach Grössenänderung, damit in der 100% Ansicht man eine andequate Darstellung hat.

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 auf solche Arbeitsebenen muss man verzichten. Ganz ehrlich, ausser Gradations und Sättigungs Arbeitsebene verwende ich fast nie etwas. Wenn man mehr braucht, muss man das Bild halt dann doch einbetten - bzw. fest einladen indem man auf einfach auf "Ebene fixieren" klickt.

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

Stimme zu - für die meisten Sachen würde eine ganz einfache Lösung reichen. Ich denke hier lohnt es das 80-20 Konzept zu verfolgen. 80% der Probleme lösen in 20% der Zeit.

Dein Problem mit dem Katalog wäre diese einfache Sache aber keine Lösung

Ich denke schon. Wichtig ist nur das "intelligente" nachladen und cachen der Bilder. Also nur in der Auflösung die sinnvoll ist (wg. Crop, Bildschirmauflösung und angezeiger Seite).

Ich selber verwende gerne einen Zeitstempel gesteuerten chache. Die Daten die am längsten nicht genutzt wurden, fliegen raus. Ich habe einen PDF Viewer programmiert - da bekommt man ganz leicht probleme wegen zu vieler Bilder. Der cache löst das.

Viele Grüsse,
Julian

[NoSi]

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. [...] ACDSee PhotoSlate ist aber auf jeden Fall sehr viel schneller, und dies auch wenn man 300 Bilder in eine Übersicht druckt.

Schau dazu mal diesen Thread an. Die vergleichst hier imho Äpfel mit Birnen. Wenn es dir um Übersichten geht, ist die (auch im zitierten Thread gestellte) Frage, ob man dafür Originalbilder ins Dokument laden muss, oder stattdessen kleingerechnete Bilder. Dass dies u.a. von ACDSee so gemacht wird, will ich mal spekulieren - denn alle anderen Tools in diese Richtung arbeiten so - außer PL (warum auch immer...). Das ist aber genau genommen nur ein Skriptingproblem, denn PL hat alles, um es genauso zu machen, wie die anderen Programme - halt nicht fest verdrahtet.

Grüße
NoSi

[NoSi]

Ich wiederhol mich - mit Platzhaltern wären auch 300 Bilder in einem Katalog kein Problem.

Ach ja? Wir werden die Bilder denn dargestellt? Die müssen erst mal geladen (Originalgröße) und dann „auf Maß“ gerechnet werden. Jedesmal beim Öffnen der „kleinen“ Datei. Bei Standard-JPGs (~3,5MB) nehmen wir mal rund 1 Sek. (optimale Bedingungen für Ladegeschwindigkeit, nutzbarem RAM, etc.) und nur 60 auf einer Seite. Das bedeutet: 1 Minute für die erste Anzeige jeder Seite. Und Änderungen (Filter, etc.) erzwingen - wenn´s was taugen soll - jeweils das Neuladen des Bildes, Filtern, etc. - wieder runter rechnen.

Wo da der Gewinn liegt, ist mir nicht ganz klar. Da importiere ich doch lieber die Dinger gleich klein (s. mein vorheriger Beitrag in diesem Thread) und habe alles stressfrei in der Kiste. Wenn es dir eh nur um das „mal schnell was zeigen“ geht, ist das die erheblich unkompliziertere Lösung.

Grüße
NoSi

[NoSi]

So könnte es aussehen, wenn man sich eine Vorlage gebastelt oder einen Reisebericht verfasst hat, und diesen dann am Ende mit Bildern versieht.

Das bekommst du im Übrigen ganz einfach mit vorhandenen Bordmitteln von PL. Ich bau dazu eine Anleitung, da das u.a. auch mir und anderen bis vor wenigen Minuten noch nicht klar war, wie einfach es eigentlich ist - die folgt in Kürze!

Grüße
NoSi

[JulianZI]

Ich wiederhol mich - mit Platzhaltern wären auch 300 Bilder in einem Katalog kein Problem.

Ach ja? Wir werden die Bilder denn dargestellt? Die müssen erst mal geladen (Originalgröße) und dann „auf Maß“ gerechnet werden. .

Eben nicht - JPEG erlaubt es normalerweise das Bild progressiv zu laden. Hier wird das Bild erst nach und nach verfeinert. Die Standard JPEG Bibliothek hat diese Möglichkeit eingebaut. Für eine Vorschau ist es komplett ausreichend das JPEG nur zu 1/8 zu laden, abhängig von der Objektgrösse natürlich.

Es macht auch Sinn die berechnete Vorschau mit dem Dokument abzuspeichern - das hatte ich vorher schon erwähnt. Man könnte die Wahl ermöglichen das Dokument mit leeren Objekte (mit Dateiname), mit Vorschau oder in perfekter Qualität anzuzeigen. Bei 150 Seiten würde ich im ersten Modus öffnen, dann die zu bearbetende Seite suchen und erst dann auf Vorschau wechseln.

Ich gehe auch nicht unbedingt von 60 Bilder auf einer Seite aus, eher 16-20 im Falle eines Kataloges. Bei einer Collage würden es wohl nur 1-6 sein. Im Falle von 2 Bildern pro Seite hätte mein Dokument dann 150 Seiten. Dieses Dokument würde trotzdem ordentlich schnell laden, da zunächst nur Seite 1 dekodiert werden muss.

Die zugewiesene Bearbeitungen würden auch nur zum Teil ausgeführt - also Helligkeit/Kontrast nur auf das kleine Bild. Schärfe (wenn überhaupt verwendet) gar nicht. Diese Einstellung ist nur für den Druck ausschlaggebend und kann in dem genannten Dialog beurteilt werden. Es gibt hier einige Möglichkeit die Anzeige zu beschleunigen. Und z.b. Picasa macht es vor, wie flink das gehen kann.

Jedesmal beim Öffnen der „kleinen“ Datei. Bei Standard-JPGs (~3,5MB) nehmen wir mal rund 1 Sek. (optimale Bedingungen für Ladegeschwindigkeit, nutzbarem RAM, etc.) und nur 60 auf einer Seite. Das bedeutet: 1 Minute für die erste Anzeige jeder Seite. Und Änderungen (Filter, etc.) erzwingen - wenn´s was taugen soll - jeweils das Neuladen des Bildes, Filtern, etc. - wieder runter rechnen.

60 Bilder auf einer Seite werden den 2GB Adressraum sprengen. (Bei 12 Megapixel Bilder). Das geht also jetzt nicht bei 32bit, mit meinem Vorschlag würde es gehen wenn die 60 Objekte werden sehr klein sein und die Bilder nur teilweise geladen werden. Auch für den Druck muss nur im Speicher gehalten werden was nötig ist, um 300dpi zu versorgen. Ok, mit 64bit kann man mehr Speicher addressieren - aber ist dies die Lösung? Es würde nur die Grenze verschieben. Spätestens die neue 21Megapixel Bilder (Canon 5D II) machen dann wieder alles kaputt.

NoSi, dank Dir für die kritische Hinterfragung. Ich bin aber nach wie vor der Meinung, das Problem ist lösbar, und dies sogar relativ unkompliziert.

Grüsse,
Julian

[JulianZI]

So könnte es aussehen, wenn man sich eine Vorlage gebastelt oder einen Reisebericht verfasst hat, und diesen dann am Ende mit Bildern versieht.

Das bekommst du im Übrigen ganz einfach mit vorhandenen Bordmitteln von PL. Ich bau dazu eine Anleitung, da das u.a. auch mir und anderen bis vor wenigen Minuten noch nicht klar war, wie einfach es eigentlich ist - die folgt in Kürze!

Das ist sicher interessant - löst aber diese Probleme nicht
- Bilddaten werden in riesige PLD Datei komplett eingebettet
- Lage Speicherdauer der PLD Datei
- Alle Bilder werden geladen um nur Seite 1 anzusehen
- Sequentielles laden einer Liste in alle Platzhalter (mit einem geht es derzeit über "Bild in Ebene laden")
- kein automatisches Einladen (vgl Idee mit Kalender bei dem nur der Hauptpfad geändert werden muss)
- Anzahl der Bilder durch Speicher begrenzt

Aber ich halt mich jetzt zurück - habe alles gesagt. Vielleicht nimmt ComputerInsel die Idee ja auf, oder auch nicht. Es wäre auf jeden Fall ein Feature welches eine deutliche Aufwertung gegenüber allen anderen Programmen darstellen würde.

Grüsse,
Julian

[Hoogo]

...und ich denke (und wenn es auch nur Spekulation ist ):
-"Dateilinks" und "nur Vorschaubilder im Speicher halten" sind 2 paar Schuhe.
-Die reine Link-Geschichte scheint mir nicht sooo kritisch, würde aber Dein Problem nicht lösen.
-Im Programm nur die Vorschau zu haben und das richtige Bild nur für irgendwelche Druck- oder Export-Geschichten zu halten ist inkonsistent. Beim Reduzieren auf eine Ebene wären die Zugriffe sicher auch gut uswusw... Schon diese einfache Variante scheint mir gar nicht so ohne zu sein.
-Und die Vorschaubilder "ordentlich" und konsistent verwendbar zu machen ist ein ganz anderes Kaliber.

[NoSi]

Eine Bildübersicht mit 171 Bildern (Digitalkamera, 9M), inkl. reichlich Platz für Kommentartext belegt als PLD-Datei 857K auf der Platte und ist in ca. 3 Sek. erzeugt (einmalige Vorarbeit nicht mitgerechnet, die dauert ca. 30 Sek.).

Hier ein Screencast wie es geht.

Das lässt sich natürlich noch beliebig modifizieren (Text oben, Bildgröße, etc.) - das Verfahren bleibt dafür immer gleich.

In dieser Performance mit der unendlichen Bandbreite an Formatierungs- und Gestaltungsmöglichkeiten wüsste ich adhoc kein Programm, dass da auch nur annähernd für diese Aufgabe - und dann noch in dieser Geschwindigkeit - herankommt.

Das Video ist „in Echtzeit“ auf einem Dual Core 2,3Mhz, 3GB Speicher entstanden.

Grüße
NoSi

[JulianZI]

Eine Bildübersicht mit 171 Bildern (Digitalkamera, 9M), inkl. reichlich Platz für Kommentartext belegt als PLD-Datei 857K auf der Platte und ist in ca. 3 Sek. erzeugt (einmalige Vorarbeit nicht mitgerechnet, die dauert ca. 30 Sek.).

Hier ein Screencast wie es geht.

Das lässt sich natürlich noch beliebig modifizieren (Text oben, Bildgröße, etc.) - das Verfahren bleibt dafür immer gleich.

In dieser Performance mit der unendlichen Bandbreite an Formatierungs- und Gestaltungsmöglichkeiten wüsste ich adhoc kein Programm, dass da auch nur annähernd für diese Aufgabe - und dann noch in dieser Geschwindigkeit - herankommt.

Das Video ist „in Echtzeit“ auf einem Dual Core 2,3Mhz, 3GB Speicher entstanden.

Danke - super gemacht. Die Bilder sind nur mega klein (ich kannte die checkbox "nur Vorschaubilder").

Als Kontaktabzug mag das ok sein, aber ich rede doch eigentlich von Photobüchern und Collagen. Die Katalogfunktion war nur ein Mittel die Grenzen schnell auszuloten.

In dieser Performance mit der unendlichen Bandbreite an Formatierungs- und Gestaltungsmöglichkeiten wüsste ich adhoc kein Programm, dass da auch nur annähernd für diese Aufgabe - und dann noch in dieser Geschwindigkeit - herankommt.

Ähm .... - Du hast hier Bilder mit einer Kantenlänge von maximal ein paar hundert Pixel eingebunden. Da kann man nicht weiterbearbeiten und jedes Bild vielleicht 2.5*2,5 cm gross drucken.

Gerhard hat an anderere Stelle gesagt:

Hier die JPEG-Dateigrößen zu summieren ist nicht korrekt, da PhotoLine die JPEGs auf der ersten Seite - und nur die Julian - enpackt. Das wäre übrigens auch bei ausgelagerten Bildern nötig, da der Anwender jederzeit Zugriff darauf haben muss, wenn er die Bilder bearbeiten will.

Ich hatte dies schon vermutet (s. http://www.pl32.com/forum3/viewtopic.ph ... sd=a#p7786), da der Seitenwechsel bei meinem Katalogbeispiel solange dauerte. Das heisst also - es ist schon fast alles fertig. Es fehlt einfach die Funktion sich den Bildinhalt von draußen zu ziehen - oder sehe ich das falsch. Es wäre schade wenn der Gedanke aus politischen Gründen (Datensicherheit, Fehlbedienung) nicht weiter verfolgt würde.

Ich möchte wirklich niemanden ärgern und Äpfel mit Birnen vergleichen, aber Google hat den Trend mal wieder erkannt und Picasa 3 kommt mit einer raffinierten Collagenfunktion. (In V2 war die noch sehr simpel) Wie üblich wird hier mit virtuell veränderten Bilder gearbeitet, d.h. die Änderungen (Helligkeit, etc) wird erts bei der Produktion angewandt.

Hier ein Screenshot - ich finde das sieht beängstigend gut und praktisch aus - wenn auch ich gerne eine Lösung in PL32 hätte, da man dann noch alle anderen Features nutzen kann, Text setzen, Rahmen für die Bilder etc.


Grüsse,
Julian

[NoSi]

Also ich stelle - ganz raffiniert - Skalierung und Winkel per erweiterten Ebeneneigenschaften ein. Dann muss ich mir keinen Abfummeln. Ansonsten dreh / Skalier ich die Ebene mit der Maus nach Augenmaß, da brauch ich dann keine "Ansage".

Was die Bildgröße betrifft, habe ich bereits auf die Lösung verwiesen - hier muss nur noch eine Option «Auf Größe skalieren» in den Import-Dialog und du kannst damit „organisierte“ Photobücher mit vernünftiger Bildqualität in der gewünschten Größe machen.

Was die Collage von Picasa angeht: In welcher Auflösung wird gearbeitet, welche Auflösung und welche Farbräumene kann ich ausgeben, wie viele Seiten kann ich damit erzeugen,... ? Mag ja sein, dass Picasa erst mal „hui“ aussieht, aber für die Kohle, die dahinter steht ist das Resultat nüchtern betrachtet nicht wirklich toll, weil doch sehr enge Grenzen gesteckt sind. Dein Fotobuch bleibt dir damit ebenfalls unerreichbar, oder habe ich das mißverstanden, dass du halt doch gern Rahmen und Texte setzen würdest (was dann ja wohl offenbar nicht geht)?

Soweit ich PL verstanden habe (oder das zumindest glaube), dürfte dein Ansatz des „Nachladens“ ein nicht triviales Problem für die gesamte PL-Struktur sein. Denn ein „virtuelles Bild“ in einer Bildbearbeitung verändern ist imho nicht mal eben so erledigt, wenn man dabei gewisse Qualitätsansprüche bei der Ausgabe und der Verarbeitung hat. Nicht ohne Grund bieten Quark und Indesign nur marginale Möglichkeiten der Bearbeitung für (verknüpfte) Bilder. Und diese Produkte kommen aus Häusern, die sich seit Jahr(zehnt)en thematisch mit der Sache auseindersetzen, aber seltsamerweise bis jetzt außer Einbinden keine echten Bearbeitungsfunktionen anbieten - da stagniert es ebenfalls seit Jahr(zehnt)en. Das machen die sicher nicht, weil sie inkompetent sind. Ich bin sicher, die haben da schon drüber nachgedacht und wissen, warum sie es lassen.

Grüße
NoSi

[JulianZI]

Hallo NoSi,

Stimm Dir zu bezgl. Picasa - Sieht Hui aus geht aber (zum Glück) nicht all zu weit. Mehrseitiges geht nicht.

Also ich stelle - ganz raffiniert - Skalierung und Winkel per erweiterten Ebeneneigenschaften ein. Dann muss ich mir keinen Abfummeln. Ansonsten dreh / Skalier ich die Ebene mit der Maus nach Augenmaß, da brauch ich dann keine "Ansage".

Ich war ehrlich gesagt selber überrascht, wie gut sich dieses Rad benutzen lässt. "Ansage" hier nebensächlich, witzig ist, dass dies alles über einen Knopf geht.

Was die Bildgröße betrifft, habe ich bereits auf die Lösung verwiesen - hier muss nur noch eine Option «Auf Größe skalieren» in den Import-Dialog und du kannst damit „organisierte“ Photobücher mit vernünftiger Bildqualität in der gewünschten Größe machen.

Diese Option fehlt in der Tat.

Was die Collage von Picasa angeht: In welcher Auflösung wird gearbeitet, welche Auflösung und welche Farbräumene kann ich ausgeben, wie viele Seiten kann ich damit erzeugen,... ?

Keine Ahnung. Am Ende wird ein recht grosses JPEG erzeugt welches locker auf DinA3 belichtet werden kann. Bei der Berechnung die ein Weilchen dauert, fliessen dann alle Manipulationen der Elemente mit ein. So schlecht ist das gar nicht.

Mag ja sein, dass Picasa erst mal „hui“ aussieht, aber für die Kohle, die dahinter steht ist das Resultat nüchtern betrachtet nicht wirklich toll, weil doch sehr enge Grenzen gesteckt sind. Dein Fotobuch bleibt dir damit ebenfalls unerreichbar, oder habe ich das mißverstanden, dass du halt doch gern Rahmen und Texte setzen würdest (was dann ja wohl offenbar nicht geht)?

Genau das habe ich eigentlich gesagt.

Es geht hier übrigens nicht um "mein" Fotobuch sondern um eine Erweiterung der Nutzungsmöglichkeit von PL32 im Allgemeinen. Hier hilft es auch nicht, dass ein "Poweruser" klar mit dem Programm kommt. Es geht mir darum eine logische Funktionalität mit Euch Betatestern zu entwickeln, die den üblichen Hobby Fotografen anspricht. Ob ich klar komme ist im Grunde völlig egal.

Soweit ich PL verstanden habe (oder das zumindest glaube), dürfte dein Ansatz des „Nachladens“ ein nicht triviales Problem für die gesamte PL-Struktur sein. Denn ein „virtuelles Bild“ in einer Bildbearbeitung verändern ist imho nicht mal eben so erledigt, wenn man dabei gewisse Qualitätsansprüche bei der Ausgabe und der Verarbeitung hat.

Wenn das Bild als Inhalt eines Vektors behandelt wird, dürfet es nicht so wild sein. Schon jetzt werden auch bereits jetzt die Ergebnisse von Ebenenberechnungen, z.b. in Gruppen gecacht - andrenfalls müsste ja für jede Ausgabe alle Berechnungen neu durchlaufen werden. Demnach gibt es bereits den nötigen code.

Grüsse,
Julian

[JulianZI]

Ich denke ich verplemper hier meine Zeit. Solange sich die Entwickler nicht mal die genannten Referenzen ansehen (Picasa 3 und insbesondere ACDSee FotoSlate) ist das nur Frust.

Nochmals, damit diese Thread Sinn macht: Der Sinn der Platzhalter ist es mit Vorlagen arbeiten zu können. Der Bildkatalog wäre nur eine eine Anwendung davon.

Hier noch ein Ausschnitt aus einer e-mail vom mir an den support vom 15. September 2005

Haben Sie darüber nachgedacht verlinkte Bilder in Dokumenten zu unterstützen, also ein Dokument welches Bildplatzhalter enthält welche dann beim Öffenn mittels fester Pfade nachgezogen werden?

Inbesondere wenn man Fotoalbums drucken möchte wäre dies sehr praktisch. Die platzhalter objekte müssten sich eigentlich nur den
Ausschnitt aus der Quelldatei merken und deren Skalierung, alle anderen Transformationen die die Ausgangsdaten verändern müssen kann man ja für derartige ebenen
deaktivieren.

Vielleicht kann man sowas relativ leicht als Vektor option implementieren, also eine property für einen vektor pfad welcher eine Datei nachläd. Der Pfad würde dann auch
gleich den Umriss bestimmen. Praktisch wäre natürlich wenn nur die Dateien geladen würden welche für die sichtbare Seite des Dokuments nötig sind.

Evtl vielleicht auch nur kleiner versionen der JPEG daten um Speicher zu sparen.
Das tool ACDSee Photo Slate macht dies recht gut, hat aber sonst fast keine Möglichkeiten.

[Hoogo]

Ich denke ich verplemper hier meine Zeit. Solange sich die Entwickler nicht mal die genannten Referenzen ansehen (Picasa 3 und insbesondere ACDSee FotoSlate) ist das nur Frust.

Versteh' ich, hab ja selber solche "Dauerbrenner" an Vorschlägen. Aber ich weiß ja, wie es bei mir auf der Arbeit ist: 2/3 der Zeit gehen für Support drauf, viele kleine Änderungswünsche haben das Programm im Laufe der Zeit sehr unübersichtlich gemacht, ununterbrochen kommen total wichtige Sachen dazwischen, oder eine Bank als Kunden, die Mitarbeiter wegsaugt wie ein Schwamm... Da können Sachen schonmal ein halbes Jahrzehnt liegen bleiben.

Ich seh das aber inzwischen auch was entspannter Mag ja Schade sein, wenn man da so das Bild im Kopf hat, wie toll das Programm doch mit der und der Option wäre, aber andererseits hab ich ja auch nicht den Streß mit der Programmierung und den ganzen Macken und Problemen, die dann doch auftauchen, sondern kann die Füße hochlegen und "macht mal..." sagen

[JulianZI]

Danke Hoogo,

wenigstens einer der mich versteht - sniff.

Wg. meiner Kreativität hier muss ich dazu sagen, dass ich viel mit Anwendungsentwicklung zu tun habe und auch Kontakt zu vielen Herstellern, u.a. wegen der von mir entwickelten PDF engine. Auch treffe ich öfters Hobby Fotografen und glaube dabei gewisse Trends zu sehen. Photoline war mir von Anfang an sympathisch - weswegen ich es empfehle wo ich kann.
Hier im Forum finde ich, wird von den Entwicklern auf die Posts zuwenig eingegangen (und auch nicht genau genug gelesen) - das ist umso weniger zu verstehen, als es ja nicht allzuviel Posts pro Tag sind. Das empfinde ich als schade.

Viele Grüsse,
Julian

[NoSi]

wenigstens einer der mich versteht - sniff.

Wg. meiner Kreativität hier muss ich dazu sagen, dass ich viel mit Anwendungsentwicklung zu tun habe und auch Kontakt zu vielen Herstellern, u.a. wegen der von mir entwickelten PDF engine. Auch treffe ich öfters Hobby Fotografen und glaube dabei gewisse Trends zu sehen. Photoline war mir von Anfang an sympathisch - weswegen ich es empfehle wo ich kann.
Hier im Forum finde ich, wird von den Entwicklern auf die Posts zuwenig eingegangen (und auch nicht genau genug gelesen) - das ist umso weniger zu verstehen, als es ja nicht allzuviel Posts pro Tag sind. Das empfinde ich als schade.

Viele Grüsse,
Julian

Naja - verstehen tu ich den Wunsch schon. Allerdings würde ich das erheblich stärker abstrahieren, damit PL nicht in ungeahnte Tiefen stürzen kann. Tendentiell könnte ich mir z.B. vorstellen, dass das PBF (PhotoBookFormat)-Format evtl. eine Lösung sein könnte. Daran erkennt PL dann - «ok, jetzt wird´s virtuell» - und arbeitet mit anderen Strategien, als innerhalb von PLDs. Wenn das dann noch irgendwie auf Photobook-Dienste (z.B. ifolor.de, fotokasten.de,...) getuned werden kann, hätte man endlich eine Anwendung, die einen nicht zum Wahnsinn treibt und könnte höchstwertige Resultate in Kleinserie fertigen - aber eben evtl. auch als PDF (Render as...). Wobei das jetzt ein Blick mit einem hochbrennweitigen Fernglas in die Zukunft ist.

Was das "die lesen nicht" betrifft, liegst du imho falsch. Sie antworten nicht, bzw. nur das Nötigste. Dass Ideen umgesetzt werden, sieht man ja z.B. bei der Formel-Lösung (Beta 14.90B5). Das ging ja fast in Lichtgeschwindigkeit. Ich glaube, das ist die Konkretheit eines Vorschlags maßgeblich - wenn du selbst entwickelst kennst du das doch: Wenn dir jemand präzise erklären kann was er will, kannst du es mit dem vorhandenen Abgleichen und Handeln. Mit "man müsste/könnte/sollte" schlägt sich kein Entwickler gerne rum und wartet gerne mal ab,... .

Grüße
NoSi