Hallo,
Ich kenne das ".lay"-Schema nur von paar Kunden meiner Kunden (alles Firmen mit der "Dynamik" von Ozeanriesen, die vor 10-15 Jahren mal irgendwelche Automatismen eingerichtet haben und an denen wenn möglich ohne Änderungen die nächsten 400 Jahre festhalten wollen)
Die ".lay"-Verfechter ignorieren relativ elegant, daß ".lay" nur und ausschließlich funktioniert, solange ausschließlich Macs im Spiel sind. Sobald auch nur ein PC mitspielen soll, muß man dem entweder die Lays umbenannt zur Verfügung stellen (super-simpel per Skript automatisierbar -- das nutzen auch einige unserer Kunden) oder aber auf das "layouts"-Schema ausweichen.
Das ist das eigentliche Problem (das mit dem "Feinbildname länger 27 Zeichen --> Lay unsichtbar" ist ja seit AFP 3.x keines mehr).
Wenn man sich diesem Problem nicht stellen muß (weil Mac-only oder mittels irgendeinem Mechanismus sichergestellt, daß die Windows-Layout-Plätze, die im Spiel sind, für ihre Plattform passend benamste Lays zur Verfügung gestellt bekommen), dann fällt es einem leicht, pro ".lay" zu plädieren. Ansonsten ist das ein simples K.O.-Kriterium, über das man nicht weiter nachdenken müsste.
Kann man doch ganz simpel, indem man guckt,
wo das Bild eigentlich liegt.
Und die sterben alle, wenn sich das ändert und man ihnen vorher erklärt, daß auch da, wo kein ".lay" dran ist, ein Lay drin sein kann?
Keine Ahnung, wie der Zugriff bzw. das "zur Verfügung stellen" der Grobbilder umgesetzt wird. Aber via WebShare kann man ganz simpel gewissen Usern nur die Erlaubnis erteilen, Grobbilder runterzuladen (könnte in WebShare sogar durch Anpassung des wsdownload.pl-Skripts dafür sorgen, daß die Suffixes on-the-fly beim Download nach ".lay" gewandelt werden, wenn man lustig ist), man kann das dito mittels jedem anderen beliebigen Automatismus, der Bilder zur Verfügung stellt, genauso machen. Meines Erachtens geht es hier eigentlich nur darum, Leuten mitzuteilen, daß aufgrund im graphischen Gewerbe heute üblichen Produktionsbedingungen, etwas, das die letzten 'zig Jahre so war, halt nun auf einmal anders ist. Wenn man den Grund dazu nachfüttert, dann wird sowas auch gefressen (zumindest meiner Erfahrung nach), auch wenn natürlich erstmal das übliche "So kann man nicht arbeiten"-Geschrei einsetzt...
Wie suchst Du denn danach? Wenn Du das am Mac per Finder machst, dann schränk halt Deine Suche ein auf Dateien, die nicht den Creator-Code "GAGA" haben ("GAGA" ist ein Beispiel).
Es ist doch so simpel. Per default bekommen die Lays den Creator-Code von Photoshop zugewiesen, was immer wieder dazu führt, daß irgendwelche Schlaumeier Lays per Doppelklick öffnen, das Grobbild in Photoshop aufgeht, sie irgendwelche Änderungen dran machen und anschl. das Geflenne groß ist, weil das Grobbild kein Grobbild mehr ist (also auch kein OPI-Replacement stattfindet) sondern nur noch ein niedrig aufgelöstes und retuschiertes Feinbild ist.
Abhilfe total simpel möglich (und meines Erachtens in den meisten Workflows zu 100% wünschenswert).
Man setzt den Creator-Code für Lays auf irgendwas, bspw. "GAGA":
und fortan haben alle Lays eben diesen Creator Code (und dementsprechend kann man ihre Anzeige auch simpel im Suchdialog ausblenden lassen bzw. das gleich in den Finder-Defaults so einstellen). Wenn man sich nun noch ein Mini-Tool am Mac schreibt/zulegt, das für eben den Creator-Code registriert ist, dann geht das bei einem Doppelklick aufs Lay auf. Und das kann dann warnen, daß es sich um ein Grobbild handelt, anbieten, das dazugehörige Feinbild darzustellen oder in Photoshop zu öffnen, whatever. Setzen Kunden von uns alles zu ihrer vollsten Zufriedenheit ein und sehen keinen Nachteil von "layouts" vs. ".lay" bzgl. Deiner oben angebrachten Punkte bzgl. des "Handling"...
Zusammenfassend: Meiner Meinung/Erfahrung nach ist ein Festhalten an Grobbildern mit ".lay" in erster Linie einer eher konservativen Grundhaltung geschuldet, die auch nur funktioniert, solange ausschließlich Macs im Spiel sind und Windows-Clients außen vor bleiben bzw. ignoriert werden (gibt es ja vielerorts tatsächlich noch). Auch sind meistens Installationen betroffen, die an ".lay" hängen, bei denen eh nur ein verschwindend kleiner Teil der Helios-Features auch praktisch genutzt wird, d.h. das Meiste an Helios-Workflow-Potential brachliegt.
Ich hab es andererseits schon 'zigmal mitbekommen, daß Kunden von Kunden die Benamung mit ".lay" bis aufs Messer verteidigt haben (weil sie irgendwelche prähistorischen Bilddatenbanken oder Workflow-Lösungen oder meist am Schlimmsten intern erstellte Skriptchen, die bisserl Automatisierung ins Spiel bringen, im Einsatz haben) und sobald dann dort eine Abteilung mit Windows ins Spiel kam, dieses eherne Festhalten an ".lay" schneller gekippt werden sollte, als man schauen bzw. es umsetzen konnte. Insofern bin ich da inzwischen sehr skeptisch, was die Stichhaltigkeit der Argumente angeht, wenn sich das Fähnlein dann immer so dermaßen schnell dreht ;-)
Gruss,
Thomas
