News und Tutorials zu Adobe Photoshop

[GastForen Programme Print/Bildbearbeitung Adobe Photoshop Probleme mit DropletDecompiler von xtools

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Print/Bildbearbeitung - Photos, Layout, Design
Themen
Beiträge
Moderatoren
Letzter Beitrag

Probleme mit DropletDecompiler von xtools

mockingbird
Beiträge gesamt: 13

20. Okt 2011, 11:14
Beitrag # 1 von 12
Bewertung:
(4789 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,
ich habe das Problem, dass ich aus einer Aktion in PS CS5 (Mac OSX 10.6.8) ein Droplet geschrieben habe, die Aktion ist mir aber durch einen Absturz abhanden gekommen. Dieses Droplet soll eigentlich ein in CameraRaw bearbeitetes Bild aus der Bridge per Drag and Drop scharfzeichnen und in PSO CMYK umwandeln und dann sichern. Die Datei ist ein jpg, hat aber das aus workflowtechnischen Gründen das suffix .jpeg. Das Ergebnis ist dann ein gleichnamiges jpg mit dem suffix .jpg (ps-standard)
Nun ist das ja nicht so schwer. Ich habe mal eben eine neue Aktion geschrieben und ein neues Droplet geschrieben. Komischerweise will mir PS nun eine Kopie als PSD sichern und ruft einen Dialog auf. Das geschieht beim ursprünglichen Droplet nicht. Leider konvertiert das ursprüngliche Droplet aber nicht in den richtigen CMYK Farbraum (Newspaper, ich brauche aber PSO LWC). Deshalb musste ich also eine neue Aktion schreiben - mit dem merkwürdigen Ergebnis.

Habe nun schon etliche Versuch gemacht, aber keinen Erfolg gehabt. Da fand ich den DropletDecompiler von xtools, der im Mai 2010 bei einigen Leuten wohl sehr gut funktioniert hat. Nun wollte ich das Droplet dekompilieren und einfach in der daraus resultierenden Aktion den Farbraum neu einstellen und dann neu als Droplet abspeichern. Leider bekomme ich aber bei dem Versuch, mein Droplet zu dekompilieren folgende Fehlermeldung:

"Message: file.open ist keine Funktion

File: /Applications/Adobe Photoshop CS5/Presets/Scripts/xtools/apps/DropletDecompiler.jsx
Line: 15635
Error Name: ReferenceError
Error Number: 24
Line: (15626) var file = Stream.convertFptr(fptr);
Line: (15627) file.open("w") || Error.runtimeError(9002, "Unable to open output file \"" +
Line: (15628) file + "\".\r" + file.error);
Line: (15629) file.encoding = 'BINARY';
Line: (15630) file.write(str);
Line: (15631) file.close();
Line: (15632) };
Line: (15633) Stream.readFromFile = function(fptr) {
Line: (15634) var file = Stream.convertFptr(fptr);
Line: (15635) >> file.open("r") || Error.runtimeError(9002, "Unable to open input file \"" +
Line: (15636) file + "\".\r" + file.error);
Line: (15637) file.encoding = 'BINARY';
Line: (15638) var str = '';
Line: (15639) str = file.read(file.length);
Line: (15640) file.close();
Line: (15641) return str;
Line: (15642) };
Line: (15643) Stream.readStream = function(fptr) {
Line: (15644) var str = new Stream();
Line: (15645) str.str = Stream.readFromFile(fptr);

[DropletDecompiler.jsx]
main()
main()
exec()
runProcess([Object:[object Object]],undefined)
process([Object:[object Object]],undefined)
exceptionMessage([Error:Referenzfehler: file.open ist keine Funktion])"

Mmmhhhhhh....

Weiß jemand was das bedeutet? Bin kein Entwickler und kann nur ein Bissl AS.

Das Javascript DropletDecompiler ist hier in den xtools zu bekommen:

http://sourceforge.net/...cripts/files/xtools/

Beste Grüße und Dank im Voraus,
mockingbird
X

Probleme mit DropletDecompiler von xtools

mockingbird
Beiträge gesamt: 13

21. Okt 2011, 12:21
Beitrag # 2 von 12
Beitrag ID: #482780
Bewertung:
(4737 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo zusammen, super dass schon 50 Leute meinen Beitrag gelesen haben, schade, dass noch niemandem was dazu eingefallen ist. Vielleicht liegt es an meiner etwas ausschweifenden Schreibe! Also kurz gesagt: ich suche eine Möglichkeit, aus einem Droplet die ursprüngliche Aktion zu dekompilieren. Als einzige Möglichkeit habe ich ein Javascript namens DropletDecompiler von xtools gefunden. Das funktioniert bei mir leider nicht (Fehlermeldung im Originalbeitrag). Gibt es eine andere Möglichkeit, wieder an die aktion zu kommen? Und wenn nicht, kann jemand der sich mit javascript auskennt das Script mal bei sich testen? Vielleicht geht es ja nur bei mir nicht...

Beste Grüße,
mockingbird


als Antwort auf: [#482712]

Probleme mit DropletDecompiler von xtools

thomas_bredenfeld
Beiträge gesamt: 197

21. Okt 2011, 12:59
Beitrag # 3 von 12
Beitrag ID: #482785
Bewertung:
(4722 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
hi mockingbird!

ein erster verdacht dreht sich bei möglichweise um einen "speichern"- bzw. "speichern unter"-schritt in der aktion. dabei kommt es erfahrungsgemäß immer wieder mal zu problem und hier hat sich meines wissens auch von cs4 zu 5 was geändert. wie und was genau, müßte ich jetzt erst auspropbieren. hab die photoshop automation schon länger nicht gebraucht ...

---

hast du in bezug auf den decompiler mal hier http://ps-scripts.sourceforge.net/xtools.html rein geschaut? das schaut mir auf den ersten blick recht gut erklärt aus.

was ich dort zumindest mal auf anhieb nicht gefunden habe, sind hinweise, ob das auch mit cs5 geht ... es haben sich beim scripting von cs5 nach 5 einige änderungen ergeben. die neueste version von diesem decompiler ist allerdings von 04/2011, scheint also recht aktuell zu sein.

---

die fehlermeldung ist kaum erhellend, weil sie aus dem compiler selbst kommt und nicht aus dem dekomplierten droplet.

---

eine ganz andere möglichlichkeit ist die, statt eine aktion aufzuzeichnen, das ganze als script abzulegen und dann von bridge aus zu starten. ist allerdings um einiges komplizierter als ein droplet aus einer aktion zu machen.

lg
tb


als Antwort auf: [#482712]

Probleme mit DropletDecompiler von xtools

Thomas Richard
  
Beiträge gesamt: 19168

21. Okt 2011, 13:38
Beitrag # 4 von 12
Beitrag ID: #482787
Bewertung:
(4710 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Du solltest dein konkretes Problem für andere nachvollziehbar machen.

Was sollen wir mit 'Drag & Drop aus Bridge'? Was soll das bei einem Droplet?
Was und wie hast du die Problematik mit dem falschen Dateisuffix behoben? PS kann das von sich aus auf diesem Weg nicht ohne weiteres.

Zum eigentlichen Problem: Hier geht das (bis auf die obigen Randproblematiken).


Zum Sekundärproblem Droplet-Decompiler: Der rennt hier in den selben Fehler, dass er wohl die Zieldatei nicht anpacken darf.
Zitat Line: (15627) file.open("w") || Error.runtimeError(9002, "Unable to open output file \"" +



als Antwort auf: [#482780]
(Dieser Beitrag wurde von Thomas Richard am 21. Okt 2011, 13:40 geändert)

Probleme mit DropletDecompiler von xtools

mockingbird
Beiträge gesamt: 13

21. Okt 2011, 22:40
Beitrag # 5 von 12
Beitrag ID: #482830
Bewertung:
(4672 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Thomas,

Zitat Du solltest dein konkretes Problem für andere nachvollziehbar machen


nun, ich glaubte, dass das für meine Anfrage zu kompliziert sei. Ich arbeite seit 14 Jahren mit PS in den Versionen 2.0-CS5. In sofern bin ich mit Aktionen sehr versiert und in den seltensten Fällen muss ich - um kleinere "Unmöglichkeiten" zu umgehen an den Aktionen herumtüfteln. Es gibt bei den ca. 100 Aktionen in meiner Aktionspalette viele, die ich schon mit PS 5 geschrieben habe und sich nun durch ca. 7 Versionen durchschleifen. Ich arbeite in einem Zeitschriften/Magazin Verlag und es haben sich für unterschiedlichste Anforderungen und Kunden viele Aktionen angehäuft.

Konkret geht es um einen Workflow, der folgendermaßen aussieht:

Hunderte Redaktionsbilder werden von einer Software analysiert und optimiert. Diese Bilder (jpg) sehe ich mir in der Bridge an und vergleiche sie mit dem Originalbild um eine fehlerhafte Optimierung herauszufiltern. Die Bilder, die mir noch nicht gut genug erscheinen korrigiere ich mit einem CameraRaw Preset aus der Brigge heraus oder lege in CameraRaw manuell Hand an. Da ich es in beiden Fällen mit JGS zu tun habe, müssen Original und Variante unterschiedliche Suffixe haben, so dass der Dateiname gleich ist. Also das eine (optimiert) heißt .jpg, das andere .jpeg. Sind die Bilder nun nach meinem Geschmack, so müssen sie nur noch in cmyk umgewandelt werden, also in das je nach Papiersorte benötigte CMYK-ICC-Profil. Hierfür habe ich mir eine PS-Aktion geschrieben (Setzte Farbeinstellung, In Profil umwandeln; Renderingpriorität rel. farbmetrisch oder aber perzeptiv, je nach Erfordernis; Sichern). Aus dieser Aktion entstand ein Droplet, das auf dem Desktop liegt. Soweit, so gut.
Wenn ich die "normalen" jpgs aus der Bridge heraus auf dieses Droplet ziehe, so werden sie in cmyk gewandelt und im gleichen Ordner übersichert. Wenn ich aber ein jpg auf das Droplet ziehe, welches aufgrund der CameraRaw Korrektur Metadaten beinhaltet, dann generiert PS plötzlich einen "Sichern unter" Dialog, der das Bild als Kopie im PSD-Format sichern will. Aber eben nur bei diesen Bildern, die in CameraRaw bearbeitet wurden.
Spaßeshalber habe ich ein altes Droplet ausprobiert, von dem ich aber keine Aktion mehr habe. Und - oh Wunder - das Bild (.jpeg) wurde in cmyk gewandelt und zu zu meiner Überraschung als .jpg gesichert. Wow! Nur leider ist in dem Droplet ein falsches cmyk-Profil verankert und deshalb will ich es dekompilieren da ich ja die Originalaktion nicht mehr habe, um herauszubekommen, wie dieses Wunder entstehen konnte.
Dieser Sicherndialog als PSD taucht übrigens nur auf, wenn es sich um das Sichern eines JPG handelt. Lasse ich durch das Droplet ein TIF generieren, geht alles gut. Nur leider sollen es JPGs sein wägend er zehnfachen Datenmenge des TIFs.

Deshalb als die Frage, ob jemand vielleicht den Decompiler unter CS5 zum Laufen bekommt oder weiß, wie ich den Code des scripts verändern muss, dass es läuft. Vielleicht ist es ja auch ein Rechteproblem.

Besten Gruß,
mockingbird


als Antwort auf: [#482787]

Probleme mit DropletDecompiler von xtools

Thomas Richard
  
Beiträge gesamt: 19168

21. Okt 2011, 23:44
Beitrag # 6 von 12
Beitrag ID: #482831
Bewertung:
(4659 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Antwort auf [ mockingbird ] Da ich es in beiden Fällen mit JGS zu tun habe, müssen Original und Variante unterschiedliche Suffixe haben, so dass der Dateiname gleich ist.

DAs hört sich für mich krank an.

Antwort auf [ mockingbird ] Also das eine (optimiert) heißt .jpg, das andere .jpeg. Sind die Bilder nun nach meinem Geschmack, so müssen sie nur noch in cmyk umgewandelt werden, also in das je nach Papiersorte benötigte CMYK-ICC-Profil. Hierfür habe ich mir eine PS-Aktion geschrieben (Setzte Farbeinstellung,

Wofür soll das gut sein? Vor allem ohne sie vorher gesichert zu haben und am Ende der Aktion zurückzuschreiben, ist sowas bäääh.

Antwort auf [ mockingbird ] In Profil umwandeln; Renderingpriorität rel. farbmetrisch oder aber perzeptiv, je nach Erfordernis; Sichern). Aus dieser Aktion entstand ein Droplet, das auf dem Desktop liegt. Soweit, so gut.

Ja, bis dahin war mir auch alles so klar.

Antwort auf [ mockingbird ] Wenn ich die "normalen" jpgs aus der Bridge heraus auf dieses Droplet ziehe, so werden sie in cmyk gewandelt und im gleichen Ordner übersichert. Wenn ich aber ein jpg auf das Droplet ziehe, welches aufgrund der CameraRaw Korrektur Metadaten beinhaltet, dann generiert PS plötzlich einen "Sichern unter" Dialog, der das Bild als Kopie im PSD-Format sichern will.

Und das wundert dich?
ACR erzeugt ein neues Bild in das dass ERgebnis oder ein SM aus ACR eingesetzt wird. Das macht _jeder_ RAW Converter so, denn die RAWs sind per Definition tabu.

Antwort auf [ mockingbird ] Spaßeshalber habe ich ein altes Droplet ausprobiert, von dem ich aber keine Aktion mehr habe. Und - oh Wunder - das Bild (.jpeg) wurde in cmyk gewandelt und zu zu meiner Überraschung als .jpg gesichert.(Und dieses Droplet beinhaltet auch den Import aus ACR? Da würde ich mal passend dazu die alten PS und ACR Versionen durchprobieren.
Bei mir hier wird das JPEG im Unterscheid zu einem RAW überspeichert, wenn ich im ACR 6.5 nach Modifikationen auf 'Bild öffnen klicke.
Befindet sich das soeben überspeicherte JPEG nun in PS und ich wandle in CMYK und Schärfe per USM, kann ich nicht einfach drüberspeichern (Cmd-S bringt den Sichern unter Dialog… ein sicheres Zeichen dafür, dass es eine grundsätzlich neue Datei ist, oder eben irgendwas im Bild eine direkte Speicherung als JPEG verhindert (Umstellen auf 16 Bit wäre z.B. ein triftiger Grund - in diesem Fall ist es aber nicht der Verursacher). Selbst ein Cmd-S direkt nach dem Öffnen aus dem ACR heraus, führt zum Sichern unter Dialog.

Antwort auf [ mockingbird ] Wow! Nur leider ist in dem Droplet ein falsches cmyk-Profil verankert und deshalb will ich es dekompilieren da ich ja die Originalaktion nicht mehr habe, um herauszubekommen, wie dieses Wunder entstehen konnte.
Dieser Sicherndialog als PSD taucht übrigens nur auf, wenn es sich um das Sichern eines JPG handelt. Lasse ich durch das Droplet ein TIF generieren, geht alles gut. Nur leider sollen es JPGs sein wägen der zehnfachen Datenmenge des TIFs.

auch Tiffs lassen sich JPEG komprimieren ;-) aber das ist ne andere Baustelle.

Antwort auf [ mockingbird ] Deshalb als die Frage, ob jemand vielleicht den Decompiler unter CS5 zum Laufen bekommt oder weiß, wie ich den Code des scripts verändern muss, dass es läuft. Vielleicht ist es ja auch ein Rechteproblem.

Ich nicht. Und ein Rechteproblem mag ich jetzt mal ausschliessen ich hab es unter nem recht frischen Testadmin probiert.
Ich würde mich jetzt mal daran machen was Thomas Bredenfeld bereits angeführt hat: Nimm den Sichern unter Dialog mit in die Aktion (wenn er sich eh nicht verhindern lässt), parametriere ihn ordentlich und schau obs besser wird.
Wie du damit dein falsches Suffix wieder loswirst ist mir aber immer noch schleierhaft – aber das scheint ja nicht zu stören.

Ich hab aber auch immer noch nicht wirklich nachvollziehen können, wie das aus dem ACR ein Droplet anwirfst, oder ist der Schritt ACR mit in der Droplet Aktion?
Wie geht das?


als Antwort auf: [#482830]

Probleme mit DropletDecompiler von xtools

mockingbird
Beiträge gesamt: 13

22. Okt 2011, 03:44
Beitrag # 7 von 12
Beitrag ID: #482835
Bewertung:
(4634 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hi Thomas,

Antwort auf: DAs hört sich für mich krank an.


Ich bin nicht krank, ich versuche nur, mit gegebenen Mitteln (im Verlag) etwas vergleichbares wie die vorher/nachher-Funktionalität aus Lightroom zu simulieren. Wenn Du in deiner unübertrefflichen Weisheit eine "gesündere" Methode kennst lass mich daran teilhaben. Übrigens ist .jpeg kein "falsches" Suffix sondern ein durchaus gebräuchliches, siehe:

http://de.wikipedia.org/...amenserweiterungen/J

Antwort auf: Wofür soll das gut sein? Vor allem ohne sie vorher gesichert zu haben und am Ende der Aktion zurückzuschreiben, ist sowas bäääh


Was von

Zitat Also das eine (optimiert) heißt .jpg, das andere .jpeg. Sind die Bilder nun nach meinem Geschmack, so müssen sie nur noch in cmyk umgewandelt werden, also in das je nach Papiersorte benötigte CMYK-ICC-Profil. Hierfür habe ich mir eine PS-Aktion geschrieben (Setzte Farbeinstellung


hast du nicht verstanden? Nur so ist es ja möglich beide Bilder nebeneinander in der Bridge zu vergleichen.

Antwort auf: Und das wundert dich?
ACR erzeugt ein neues Bild in das dass ERgebnis oder ein SM aus ACR eingesetzt wird. Das macht _jeder_ RAW Converter so, denn die RAWs sind per Definition tabu.


Nun, genau das macht aber das Droplet, das ich dekompilieren will. Ich will ja rausfinden, wie das funktionieren kann. Ich dachte eigentlich, das hätte ich deutlich gemacht.

Antwort auf: auch Tiffs lassen sich JPEG komprimieren ;-) aber das ist ne andere Baustelle


Zitat TIFF ist, neben PDF und EPS, ein wichtiges Format zum Austausch von Daten in der Druckvorstufe in Verlagen und Druckereien, weil es das von ihnen verwendete CMYK-Farbmodell unterstützt. Im Internet wird das TIFF genutzt, um Anwendern, wie etwa Verlagen, hochaufgelöste Bilder in druckfähiger, verlustfreier Qualität zur Verfügung zu stellen. Dabei wird in Kauf genommen, dass diese Dateien ein Mehrfaches der Größe eines verlustbehaftet komprimierten JPEG-Bildes haben. TIFF hat sich so als Quasi-Standard für Bilder mit hoher Qualität etabliert.


http://de.wikipedia.org/...ed_Image_File_Format

Das ein TIF auch komprimiert werden kann, ist mir schon klar aber wird aus diversen Gründen im Verlag nicht gemacht. Einige davon liegen in der Weiterverarbeitung und den unterschiedlichen Programmen - beispielsweise die TIFF-G4 RIPS, die die Daten für Axel Springer aufbereiten - die daran beteiligt sind und mit komprimierten TIFs Fehler produziert haben, aufgrund derer Kunden eine Gutschrift verlangten. So einfach ist das... Geld regiert die Welt

Und wie es bei der Wikipedia heißt: "TIFF hat sich so als Quasi-Standard für Bilder mit hoher Qualität etabliert" damit ist natürlich ein unkomprimiertes TIF gemeint, auch wenn LZW verlustfrei ist. LZW bringt aber auch nicht so viel bei Bildern mit hohem Farb- und Luminanz-Umfang

Zitat Nimm den Sichern unter Dialog mit in die Aktion (wenn er sich eh nicht verhindern lässt), parametriere ihn ordentlich und schau obs besser wird.


Der "Speichern unter" Dialog sichert aber in einen definierten Ordner und nicht immer in den Ordner, in dem das Original liegt. Und der Trick, dies doch hinzubekommen ist mir gerade zu aufwendig. In CS5 gibt es beim erstellen des Droplets leider keinen Dialog, bei dem ich definieren kann dass PS immer in den Originalordner sichert. Es gibt nur "Speichern und Schließen" oder die Möglichkeit, auf das Speichern der Aktion zurück zu greifen, was aber normalerweise einen definierten Pfad beinhaltet.

Aber genau darin mag die Lösung des Problems liegen, vielleicht sollte ich doch den Trick benutzen, um im "Speichern unter"-Dialog in der Aktion ein: "In: Datei oder Ordner nicht gefunden" zu produzieren, wodurch PS automatisch in den Originalordner sichert.

Zitat Ich hab aber auch immer noch nicht wirklich nachvollziehen können, wie das aus dem ACR ein Droplet anwirfst, oder ist der Schritt ACR mit in der Droplet Aktion?
Wie geht das?


Aus ACR wird das Droplet nicht bedient.

Ich habe vor mir das Fenster der Bridge. Nun vergleiche ich das automatisch optimierte jpg mit dem Original ->Es ist noch nicht gut genug -> +R öffnet das jpg in ACR -> Bild verbessern -> auf fertig klicken -> wieder zurück in Bridge -> nächstes Bild -> alle fertig -> alle bearbeiteten Bilder auswählen -> drag & drop auf Droplet auf Desktop -> PS macht den Rest -> Kaffee trinken :-)

ALR 3 hat zwar ein komfortableres GUI aber die Weiterverarbeitung läuft aus der Bridge und ACR flüssiger.

Nun haben wir zwar daran herumlaboriert, wie ich das Problem des Bildbearbeitungs-flows beheben bzw. umgehen kann, aber meiner eigentlich Frage: wie kann ich ein Droplet mit dem DropletDecompiler dekompilieren bin ich leider noch nicht näher gekommen. Denn das ist es, was mich besonders interessiert...

Davon abgesehen finde ich es nicht sehr amüsant, hier im Forum als "krank" "bäääh" oder irgendwie als dämlich behandelt zu werden. Ich bin kein kleiner Junge, dem man mit solchen Sprüchen kommen kann. Wer was Sinnvolles zum Thema zu sagen hat bzw. Verbesserungsvorschläge zu einer komplexen Arbeitsumgebung - in der jährlich tausende von Bildern möglichst effektiv bearbeitet, optimiert und weiterverarbeitet werden müssen - geben kann ist gerne gesehen, sollte sich aber um die allgemein übliche Höflichkeit bemühen. Auch wenn mein Name vielleicht andere Assoziationen hervorrufen mag ;-)

Best Regards,
mockingbird


als Antwort auf: [#482831]

Probleme mit DropletDecompiler von xtools

Thomas Richard
  
Beiträge gesamt: 19168

25. Okt 2011, 18:35
Beitrag # 8 von 12
Beitrag ID: #483044
Bewertung:
(4534 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Eigentlich ist mir das ja hier zu doof, aber damit keiner behaupten kann, dass nicht wenigstens ich mir Mühe gegeben habe:

Hast du den Decompiler mal aus PS CS4 gestartet, da läuft er hier mit PS CS4 Aktionen – PS CS5er Aktionen scheinen mir nach einem Blick in ein identische Aktion in Form eines Droplets aus CS4 und CS5 wieder komplett anders gestrickt zu sein.



Zum Rest halte ich mich jetzt raus, weil wenn hier jemand dicke Backen macht, weil man ihn darauf hinweist, dass es kein guter Stil ist, eine Aktion mit dem Verstellen der Usersettings zu beginnen, und sie am Ende nicht wieder zu restaurieren; oder es nicht hinbekommt, in der Bridge 2 Bilder zu vergleichen, die nicht im selben Ordner liegen, ist alles weitere, aus meinem bescheidenen Kenntnisstand der Materie heraus, vergebene Liebesmüh.


als Antwort auf: [#482835]

Probleme mit DropletDecompiler von xtools

mpeter
  
Beiträge gesamt: 4623

26. Okt 2011, 11:29
Beitrag # 9 von 12
Beitrag ID: #483074
Bewertung:
(4488 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Moin,

Mocking Bird high in a tree
Looks like you got the best of me
Mocking Bird singing his song
Well Mocking Bird mocking me
now that you're gone

ab dafür ...


als Antwort auf: [#483044]

Probleme mit DropletDecompiler von xtools

-hans-
Beiträge gesamt: 748

18. Nov 2011, 20:37
Beitrag # 10 von 12
Beitrag ID: #484759
Bewertung:
(4278 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Herr mockingbird,

probieren Sie es doch mal mit einer Kombination von AS und Aktion. Das folgende Script konnte ich nur mit PS CS3 testen, gerade im Öffnen-Dialog könnten hier ein paar Unwegbarkeiten stecken ...

Aktion im Script ändern,als Programm sichern, als Droplet nutzen:
Code
on open theFiles 
repeat with i from 1 to count of theFiles
set theFile to (item i of theFiles) as text
try
tell application "Adobe Photoshop CS3"
open file theFile showing dialogs never
set myDoc to current document

do action "MeineAktion" from "Standardaktionen" --hier Deine Aktion

set jpegSaveOptions to {class:JPEG save options, embed color profile:true, format options:optimized, quality:12}
save myDoc in file theFile as JPEG appending no extension with options jpegSaveOptions --no extension behält suffix".jpeg"
close myDoc

end tell
on error e
display dialog e giving up after 5
close myDoc saving no
end try
end repeat
end open


Insofern die bearbeitete Datei als *.jpg sicherbar ist, sollte das funktionieren.

Liebe Grüße

Hans-Gerd Claßen

P.S. die Aktion darf natürlich keine öffnen oder sichern Elemente haben ::))


als Antwort auf: [#482835]

Probleme mit DropletDecompiler von xtools

mockingbird
Beiträge gesamt: 13

27. Nov 2011, 21:31
Beitrag # 11 von 12
Beitrag ID: #485246
Bewertung:
(4163 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Herr Claßen,
vielen Dank, das klappt sehr gut :-)
so konnte ich zwar mein droplet nicht dekompilieren, aber mit Ihrem Script hat sich das erübrigt. Ich werde mich nun intensiver mit dem Steuern von PS mittels Script befassen. Tatsächlich Hilfe zur Selbsthilfe!
Thanks a lot

Beste Grüße,
mockingbird


als Antwort auf: [#484759]

Probleme mit DropletDecompiler von xtools

-hans-
Beiträge gesamt: 748

27. Nov 2011, 22:05
Beitrag # 12 von 12
Beitrag ID: #485247
Bewertung:
(4150 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Kein Problem :)

Bei den Jpg-SaveOptions gibt es noch ein paar Optionen.
Am besten mal mit dem ScriptEditor das Funktionsverz. der PS.app öffnen und nachschauen ...

Schönen Rest

Hans-Gerd Claßen


als Antwort auf: [#485246]
X

Veranstaltungskalender

Hier können Sie Ihre Anlässe eintragen, welche einen Zusammenhang mit den Angeboten von HilfDirSelbst.ch wie z.B. Adobe InDesign, Photoshop, Illustrator, PDF, Pitstop, Affinity, Marketing, SEO, Büro- und Rechtsthemen etc. haben. Die Einträge werden moderiert freigeschaltet. Dies wird werktags üblicherweise innert 24 Stunden erfolgen.

pdf-icon Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.

Veranstaltungen
01.03.2023 - 09.03.2023

Online
Mittwoch, 01. März 2023, 00.00 Uhr - Donnerstag, 09. März 2023, 00.00 Uhr

Online Webinar

Wie gehen wir mit diesen Veränderungen um? Was ist notwendig, damit wir die Digitalisierung im Unternehmen klappt? Veränderungsprozesse verstehen und entsprechend handeln Mitarbeiter als Botschafter Webseite mit WordPress erstellen SEA /SEO (Ads aufschalten)

Ja

Organisator: B. Isik - SNF Academy

Kontaktinformation: B. Isik, E-Mailinfo AT snfa DOT ch

https://www.fernstudiumfitness.ch/digitalisierung-schweiz/