Vet du om det finns möjlighet att köra stansen på en server så man kan komma åt den från flera datorer.

Hm, vad betyder/innebär “stansen”?

En gång i tiden stansade man hålkort som man sen matade datamaskinen med för att köra programmet.

Ja, jag kommer ihåg det från typ 1978, vi hade på den tiden ett lagerredovisningsprogram där inputten gjordes av någon som hålslog/stansade en massa avlånga pappkort. När datorn hade surrat ett tag så spottade en matrisskrivare ut kilovis med pyjamaspapper (och alla gapade av förvåning över den fantastiska tekniken).
OT, sorry.
Photo Mechanic Plus är modernare än så.
:)

Ja Jonas det kan man. Den frågan har varit uppe i Camera Bits forum för Photo Mechanic Plus. Det verkar mer vara en licensfråga än en teknisk fråga. Så detta är en viktig skillnad mot Lightroom som är strikt single user och inte fler samtidiga användare än en. Åtminstone tidigare avrådde Adobe från att köra mot samma databas från flera datorer då databasen då kunde bli korrupt.

Photo Mechanic skalar bättre än Lightroom som förutom att vara strikt single user inte heller klarar av att hantera och söka i fler databaser än en samtidigt. Det är en av PM Plus verkliga fördelar. En annan är att PM Plus även är otroligt anpassningsbart till skillbad från LR som är mer av "one size fits all". Baksidan är att ribban ligger högre och det kräver att man sätter sig in i hur det funkar om man vill ha max produktivitet ur programmet.

En annan för mig viktig fördel är att jag kan välja en RAW-konverterare jag gillär bättre än LR:s Develop-del. Äntligen finns ett för många bättre alternativ än LR, men för de som bara stirrar på pengarna och inte värderar sin tid särskilt högt, så blir det säkert klart dyrare att välja PM Plus och Capture One, Photolab eller något annat för efterbehandling också.

Supporten är dessutom lika snabb och bra som många vittnat om. Programmet är en verkligt mogen produkt som funnits i över 20 år även om just databasen är helt ny. Jag har inte stört mig på några buggar i egentlig mening MEN det finns några riktigt märkliga och illa fungerande lösningar. En av dessa är "Rename"-funktionen som ger verkligt snurriga resultat om man inte ser upp med inställningarna i "Preferenses". Även en del av IPTC-hanteringen borde hållas samman bättre i menyerna. Tog mig ett tag att fatta hur det hängde ihop.

I övrigt tycker jag PM Plus varit min enskilt bästa fotoinvestering hittills under mina 50 år som aktiv fotograf. 1900 spänn för det man får är en ren skitsumma för ett bildorienterat halvt DAM (ja man kan ju inte få allt för 50 spänn, men det vore fantastiskt om de kunde öppna upp även for taggnibg av andra filtyper än bilder och video såsom exv. PDF:er och Office-dokument.

En generell metadatabas kan man ganska enkelt göra själv i t.ex. MySQL eller SQLite.

Det som kan vara svårt är att integrera med bildvisning, men det är knappast raketkirurgi det heller om man har lite programmeringsvana.

Det är klart att du ska göra det Per - om du har långtråkigt och inte vet vad du ska göra av din tid. Jag föredrar dock att köpa över 20 års förfining i dialog med professionella användare som Camera Bits lagt ner för att skapa en mogen produkt med arkivdatabas och istället lägga den tiden på att få verklig ordning på mitt bildarkiv.

Jag är rätt säker på att du underskattar starkt vad som krävs för att utveckla en väl fungerande och verkligt produktiv applikation såsom Photo Mechanic.

Då ser vi väl inte dig här på ett tag då - hör av dig och tala om hur det går och när vi kan Beta-testa!

Ja, jag skulle också överväga ett inköp av Photo Mechanic om jag hade ett stort behöv av en bättre metadatabas för mina bilder.

Men jag skulle inte sitta och vänta på att Camera Bits skulle inkorporera finessen att lagra metadata för alla slags filer i programmet om jag hade ett stort behov av det.

Jag har inte väntat på dem. Jag har redan pratat med dem om detta. Jag tror de skulle kunna bredda programmets användningsområde rätt mycket om de öppnade upp även för andra format och Photo Mechanic har redan en massa saker på plats för att det skulle kunna funka med rätt små medel. Det finns redan gränssnitt för att kunna ha olika scheman för olika datatyper på plats och likaså för godkända filassociationer m.m.

DAM-tillverkare som PhotoWare var helt bildtillvända från början de med men de tvingades öppna upp för alla typer av fildata för att bredda sin marknad när tidningsmarknaden dog. Hade de inte gjort det så hade de inte fått sälja systemet till Stockholms Stadsmuseum, för det var där det jobbet gjordes i samarbete med museet och den svenska generalagenten Buildpix i Lund. Om Camera Bits skulle göra detsamma så tror jag det blir en Win-Win för både de och oss och det vore en verklig selling point även i konkurrensen med Lightroom. Även fotografer behöver få ordning på sin mess av PDF:er och Office-dokument m.m.

De skulle behöva öppna så att inte bara IPTC stöds i formulären utan även andra namnrymder i XMP. Det finns redan idag sektionering i de formulär där man konfigurerar inmatningsformulären så det enda som skulle behövas där är att man gör exv. XMP:s Dublin Core namnrymd tillgänglig.

Jag undrar om det är så enkelt att göra en metadatahanterare värd namnet själv. Även i Photo Mechanic ser man ju spår efter hur man anpassat sig till hur IPTC utvecklats över tid och en del fält har blivit utfasade (men finns kvar av kompatibilitetsskäl). En del vill köra IPTC "classic" medan andra föredrar att IPTC-bakas in i XMP-datat. En del vill skriva in RAW-data in i RAW-filsoriginalen medan andra föredrar "sidecars" o.s.v. Så jag tror inte det är så lättsnutet som det kanske verkar trots allt. På toppen av det så behöver man utveckla riktigt effektiva gränssnitt och processer för att ett sådant program inte ska ratas rakt av p.g.a. ineffektivitet.

Sådana här program kan bara finna nåd hos användarna om det tillför något och verkligen är mer produktiva än det som de flesta redan har vilket är ett annat ord för Lightroom. Så varför göra något helt eget när de flesta redan har Lightroom "gratis" och inte ens använder det fullt ut.

Ska man ge sig på ett berg av många 10 000-tals ja kanske 100 000-tals bilder, så står man initialt inför ett berg av metadataarbete och det krävs både en vettig strategi och systematik exv. när det gäller benämning av foldrar och filer för att man ska komma till skott tillräckligt fort för att inte tappa sugen. Men gör man det så ger programmet nytta från första stund. Sedan blir det bara bättre och bättre ju mer tid man lägger på att förse bilderna med kontext och key words m.m.

OK! Bra om Camera Bits lyssnar på dig. Då slipper du anlita mig för att lösa problemet. :)
Men jag ska kanske skriva ett sånt program ändå, för att se om det är komplicerat eller plättlätt.
Ett grafisk gränssnitt ger jag mig dock inte på. Det har ingenting med grundfunktionalitet att göra.

Jag har haft ett par rätt omfattande mailkonversationer med Camera Bits om möjligheten att få dem att stöda även textdokument såsom Office-filer och PDF:er m.m. Egentligen vill jag att man stöder alla typer av filer genom att erbjuda möjlighet att hänga på sidecarmetadatafiler (*.XMP) som man redan nu kan göra på både RAW och XMP-kompatibla filer såsom DNG, JPEG och TIFF. Där kan man dessutom välja att skriva in detta data i filerna i PM om man vill.

Per, någon form av gränssnitt kommer du faktiskt att behöva och jag förstår inte varför du skulle tveka inför det. Alla moderna utvecklingsmiljöer har väl stöd för sånt och har de inte det så finns det säkert att köpa från tredjepartstillverkare. Det duger inte med någon statisk figgning av din SQL-databas utan den måste kunna skötas via ett dynamiskt grafiskt gränssnitt annars kommer nog ingen annan än du själv att vara intresserad av den lösningen.

XMP/IPTC-scheman och datastrukturer måste man ju kunna hantera på ett rationellt sätt som användare. En stor del av Photo Mechanics gränssnitt består ju just av de formulär man använder för att definiera hur ens mallar och inmatningsformulär ska se ut, vilka element och inbyggda variabler som ska användas. När man gör det så definierar man även de scheman som sedan jobbar i bakgrunden.

Jag tror inte man kommer runt det om man ska jobba med denna typ av metadata.

Ett lämpligt gränssnitt är en SQL-tolk.
OM jag ger mig på det här är det givetvis inte för att sälja eller ens för att gära någon annan glad.