Image Processor Pro til batch-retouch i studie

Hvis I retoucherer produktbilleder til daglig, har I kørt Image Processor en fredag eftermiddag. Et par hundrede PSD'er i en mappe, tre størrelser, en kop kaffe og håbet om, at Photoshop ikke crasher før køen er færdig. Det går som regel godt nok. Indtil køen er på 2.000 filer, deadline er mandag morgen, og tre retouchere venter på den samme maskine.

Image Processor Pro er den udgave de fleste retouchere griber efter, og længe var det det reneste batch-værktøj i Photoshop. Det er også et script, der kører inde i én Photoshop-session, og det er den grænse I rammer, så snart volumen vokser. Denne artikel går igennem, hvad IP og IPP faktisk gør, hvor de holder op med at skalere, og hvordan batch-retouch ser ud i et rigtigt produktionsmiljø.

TL;DR

Image Processor følger med Photoshop under Filer > Scripts > Image Processor. Det gemmer åbne billeder eller en mappe i JPG, PSD og TIFF i én kørsel, med valgfri resize og en action ovenpå.
Image Processor Pro er Russell Browns udvidede version - samme idé, men flere outputforudindstillinger pr. kørsel, navngivning med suffiks og kopi af metadata.
Begge kører som sekventielle JSX-scripts i én Photoshop-instans. De bliver flaskehals på store køer, kan ikke køre forskellige actions pr. rendition og overlever ikke et Photoshop-crash midt i en batch.
Den moderne stak i et studie er lagdelt: droplets og Bridge til ad hoc, UXP-plug-ins med BatchPlay til scripted produktion, ImageMagick til headless konvertering, og Adobes Photoshop API til cloud-rendering.
IP/IPP hører hjemme på retoucherens skrivebord til finish-arbejde. Bulk-eksport, navngivning og kanalspecifikke renditions hører til opstrøms for Photoshop, i en samlet pipeline.

Hvad Image Processor og Image Processor Pro faktisk gør

Image Processor er et indbygget JSX-script. I finder det under Filer > Scripts > Image Processor, eller som filen Presets/Scripts/Image Processor.jsx i Photoshops installationsmappe. Bridge har det samme script under Værktøjer > Photoshop > Image Processor, så I kan vælge filer i Bridge og sende dem videre til Photoshop med ét klik.

Scriptet gør fire ting i én kørsel: åbner hver kildefil, kører eventuelt en Photoshop-action, resizer eventuelt til en bredde × højde, og gemmer i JPG, PSD og TIFF i den kombination I vælger. Output ryger enten i kildemappen eller en mappe I peger på, og hvert format får sin egen undermappe (JPEG/, PSD/, TIFF/). For de fleste studier er JPEG-kvalitet plus "Convert profile to sRGB" hele e-handels-eksportflowet.

Image Processor Pro er den udvidede version vedligeholdt af Russell Brown og distribueret via Adobes Dr. Brown's Services-panel. Samme grundidé, men dialogen er bygget om til retouchere, der har brug for mere end ét output pr. kørsel. De vigtigste forskelle:

Flere outputforudindstillinger i én kørsel - fx en 2000 px sRGB JPG, en 1000 px firkantet crop og en TIFF i fuld opløsning i AdobeRGB i samme runde.
Navngivning med præfiks, suffiks, sekvensnummer og det oprindelige filnavn som tokens.
En action pr. preset - IPP kan køre forskellige actions for de forskellige outputstørrelser.
Valgfri kopiering af metadata, valgfri flatten, valgfri "Save for Web"-kvalitet.

Det sidste er den reelle grund til, at retouchere foretrækker IPP. I almindelig Image Processor kører hvert output gennem den samme action; i IPP kan PDP-renditionen på 2000 px få en "sharpen for web"-action, mens arkivets TIFF springer den over. Den ene feature dækker det meste af "vi har brug for forskellig behandling pr. kanal", som dukker op i et packshot-studie.

Hvor Image Processor Pro begynder at sande til

For en enkelt retoucher med 100 filer er IPP fint. Problemerne kommer ved studievolumen, og de kan ikke ordnes inde i scriptet.

Det er sekventielt og enkelttrådet. Photoshop åbner én fil, kører action, gemmer renditions, lukker, og fortsætter til den næste. Moderne maskiner har 16 kerner, og scriptet bruger én. En kø på 2.000 filer à 4 sekunder er over to timer, og retoucherens Photoshop er låst hele vejen.

Det kører i den samme Photoshop, retoucheren selv bruger. Enten tager I arbejdsstationen ud af drift mens batchen kører, eller også sætter I en sekundær maskine op som "eksport-boks". Begge løsninger er almindelige, ingen af dem er gode. Eksport-boksen bliver stille og roligt til et stykke infrastruktur uden monitorering, uden logning, og med én person der ved, hvordan den er sat op.

Det fejler grimt. Hvis Photoshop løber ind i en korrupt PSD halvvejs og crasher, mister IPP køen. Der er ingen resume. I sorterer kildemappen efter ændringsdato, finder ud af hvor scriptet stoppede, og kører resten igen. Klokken 18 om fredagen er det ikke der, retoucherne vil være.

Det ved ingenting om resten af pipelinen. Scriptet skriver filer i en mappe. Ingenting fortæller DAM'et det, ingenting siger noget til kunden, ingenting logger eksporten på et job. Det arbejde skal ligge et andet sted, og i de fleste studier er det andet sted "retoucheren kopierer manuelt over i en leveringsmappe".

Moderne batch-alternativer i studievolumen

Ud over IPP giver Photoshop og det omgivende værktøjssæt jer fire produktionsmønstre. De fleste studier ender med en kombination, ikke ét enkelt.

Droplets. Filer > Automatisér > Opret droplet gemmer en action som en lille eksekverbar fil. I trækker en mappe med PSD'er over på dropletten, og Photoshop kører action på hver fil. Droplets er fremragende til ét bestemt arbejde - samme action, samme output - og en retoucher kan lave og dele dem uden at skrive kode. Samme grænse som IPP: én Photoshop-instans.

Bridge batch og Image Processor. Værktøjer > Photoshop > Batch i Bridge er den samme motor, men med bedre udvælgelse af kildefiler. I vælger filerne i Bridge - på tværs af mapper, med metadata-filtre - og Bridge sender dem videre til Photoshop. Brugbart når "de filer jeg vil rendere" ikke er en pæn mappe.

UXP-plug-ins med BatchPlay. Adobes moderne scripting-platform afløser den ældre ExtendScript-runtime. UXP-plug-ins bruger BatchPlay-API'et til at styre Photoshop programmatisk, med rigtig async-håndtering, manifest-baseret pakning og en ordentlig debugger. Hvis studiet har et halvråddent .jsx-script, ingen rigtig stoler på, er UXP det sted, det skal flyttes hen næste gang. Photoshop UXP- og BatchPlay-referencen ligger på developer.adobe.com.

ImageMagick på kommandolinjen. Til renditions, der ikke kræver Photoshops lag-logik - sRGB-konvertering, resize, firkantet crop med padding, JPEG-kvalitet, formatkonvertering - er ImageMagick hurtigere, scriptbart og kører headless. Én magick mogrify-kommando kan behandle tusindvis af filer på alle CPU-kerner i den tid, IPP bruger på at åbne Photoshop.

magick mogrify -path out/ -resize 2000x2000 -profile sRGB.icc \
  -format jpg -quality 85 *.tif

Adobes Photoshop API. For studier, der er vokset fra desktoppen, sælger Adobe et Photoshop API i skyen som en del af Firefly Services. I poster en PSD-reference og en redigeringsbeskrivelse (udskift smart object, redigér tekst, eksportér renditions), og Adobe rendrer på serversiden. Det er det rigtige svar, når flaskehalsen er "vi kan ikke køre nok Photoshop-instanser parallelt", og det forkerte svar, når arbejdet er rigtig interaktiv retouch.

Det mønster de fleste studier lander på: ImageMagick til mekaniske konverteringer, UXP/BatchPlay til alt der skal bruge Photoshops logik, droplets til retouch-selvbetjening, og IP/IPP til finishen på skrivebordet.

De renditions studiet faktisk har brug for

Uanset hvilket værktøj der kører batchen, er listen den samme korte liste i et packshot-studie:

sRGB JPG, 2000 px lang side, kvalitet 85, indlejret ICC, metadata strippet - PDP-master til e-handels-CMS'et. De fleste platforme genkoder alligevel, men kilden skal være ren.
sRGB JPG, firkantet crop, 1200 px, hvid baggrund - markedspladsrenditionen (Amazon, Zalando, kanal-apps i Shopify). Firkantet er ikke til forhandling på de fleste markedspladser.
AdobeRGB TIFF, fuld opløsning, 16-bit, lag flatlagt, profil indlejret - arkivmaster. Brug den til genoptryk og videregivelse; lever den aldrig ud til en web-kanal.
PSD, lag bevaret, fuld opløsning - den redaktionelle kilde. Hører til i DAM'et, ikke i leveringsmappen.

Den fejl, det er værd at undgå, er at bygge "én stor render", der laver alle fire ud af én IPP-kørsel. Forskellige kanaler har forskellig navngivning, forskellige metadata-regler og forskellige review-trin. Kør dem som adskilte presets, så I kan sende PDP-renditionen ud, mens arkiv-TIFF'erne stadig encoder. Artiklen om farvestyring i retouch-pipelinen gennemgår profil-håndteringen pr. rendition.

Filnavngivning inde i IP/IPP

Almindelig Image Processor er stiv på navngivning: <originalt-navn> plus et format-suffiks og et størrelses-suffiks, scriptet selv hægter på. Der er ingen token-UI. Hvis navngivning betyder noget - og det gør det altid ved studievolumen - er IPP minimumet.

IPP har fire tokens i navnefeltet: Document Name (kildens filnavn uden filendelse), Prefix (en streng pr. preset), Suffix (det samme), og Sequence Number (med konfigurerbart startnummer og antal cifre). I bygger et navn som {prefix}_{docname}_{suffix}_{seq}, og IPP udfylder for hver fil. Det rækker til de fleste kanal-navngivningsskemaer - pdp_SKU12345_2000_001.jpg er én preset væk.

Det IPP ikke kan: hente tokens fra XMP-metadata, fra et CSV-sidecar eller fra en jobticket. Hvis filnavnet skal indeholde SKU fra et PIM og sæsonkode fra et brief, skal den mapping ske før filen rammer IPP, eller efter. I en samlet pipeline ankommer filen med SKU og sæson allerede i navnet og metadata; IPP renderer bare.

Hvor IP/IPP passer ind - og hvor pipelinen overtager

Image Processor Pro er et finish-værktøj. Det hører til på retoucherens skrivebord, til sene justeringer, enkeltstående kundeønsker og redningsjob. At køre hele studiets eksport gennem det er det samme mønster som at køre produktionen i et regneark: det fungerer ved lav volumen og koster jer stille og roligt en medarbejder ved høj.

En samlet pipeline tager de dele, der ikke er kreative - filnavngivning, rendition-matrix, kanalspecifikke eksporter, levering, audit-log - og kører dem nedstrøms for Photoshop. Retoucheren commit'er en lagdelt PSD ind i DAM'et, og pipelinen producerer PDP-JPG'en, markedspladsens kvadratiske crop og arkiv-TIFF'en, navngiver dem mod SKU'et, og pusher til distributionsmodulet. Retoucheren åbner ikke IPP til bulk-kørslen; de åbner det, når noget specifikt skal håndlaves.

Det er den arbejdsdeling, editorer og retouchere lander på, når volumen først er reel: scripts og ImageMagick til det mekaniske, UXP til studie-interne automatiseringer, IPP til skrivebordet, og en samlet platform til alt mellem retouch-app og kanal. QA-processenligger oven på den platform, ikke inde i eksportscriptet.

Tjekliste før næste batch-kørsel

Kan I på skrift sige, hvilke renditions der går til hvilken kanal og i hvilket farverum?
Hvis IPP-kørslen crasher ved fil 1.400 ud af 2.000, ved I så hvordan I genoptager uden at re-rendere de første 1.400?
Bliver retoucherens arbejdsstation blokeret under eksport, eller kører batchen et andet sted?
Lander hver eksporteret fil i DAM'et med SKU, sæson og job-ID allerede på sig?
Hvis kunden spørger "hvilken JPG blev leveret til Zalando den 14. marts?", kan I svare på under et minut?

Hvis tre eller flere svar er ubehagelige, er problemet ikke scriptet. Det er, at batch-eksport stadig er retoucherens job, og det skal det ikke være ved studievolumen.