Annons

Bildbehandlingsprogram

Produkter
(logga in för att koppla)
Nedanstående bildbehandlingsprogram
använder jag.

CorelDraw 9 (Mycket bra)
Ulead Photoimpact 8 (Bra)
Paintshop pro (Bra)
Adobe imagestyler (Mycket bra)
Adobe Photoshop 4 (Sådär)
 
Harald: bra förklarat.. lite "overkill" kanske.. jag förstod det.. men jag har programmerat en hel del.. skulle jag inte ha gjort det så skulle jag lika gärna kunnat tro att du förklarade hur en dieselmotor fungerar typ :)
 
Inte för att starta en programmeringsdiskussion men ramminne och snabbhet är två saker varvid beräkningar med större antal decimaler kräver att varje pixel för en bild lagras i ramminnet med fler bitar än annars vilket resulterar i att mer minne tas upp hos datorn. Vilket programmeringsspråk man väljer beror på många olika saker men i princip är assembler ett av dom snabbare. Vad gäller kompilerade och interpreterade språk är assembler ett kompilerat.
 
Visst kompilerar man assemblerkod men man har ju en helt annan möjlighet att styra vad som ska hända och hur, om man skriver i assembler. Dessutom är det så att programmeringseliten även ger sig in i den kompilerade koden och ”hackar” därför att man anser att kompilatorerna är dåliga på vissa saker. Man har speciella editorer för detta. Det man vill optimera är just programmens effektivitet.
Som jämförelse kan jag ta upp ett fall som numera är historia. Det fanns ett DOS-program som hette dBaseII. Det var ett databasprogram skrivet i assembler och man hade, under lång tid, ”filat” på detta program för att få ner storleken på den exekverbara filen och samtidigt få programmet snabbt. Utvecklingskostnaden för detta program bedömdes dock för hög och att göra olika språkversioner bedömdes som orimlig p.g.a att även dessa fick göras i assembler. Därför skrevs nästa version, dBaseIII, i programspråket C. Den exekverbara filen blev mycket större och fick delas upp i flera s.k. overlay-filer som lästes in och slängdes ut vid behov. Vissa funktioner i dBaseII gjordes mer än 100 gånger snabbare än i dBaseIII.
Det jag ville peka på i mitt inlägg är att Photoshop, i många avseenden, är ett väldigt speciellt program. Det kanske är svårt att komma in i till att börja med och det är kanske lite dyrt men frågan är om det är oskäligt dyrt. Det tycks ju som om Photoshop dessutom nästan fått monopol på den professionella marknaden. Det är väl å andra sidan därför man har råd att kosta på sig assemblerkod…
När det gäller att lära sig Photoshop så har det funnits en hel del bra gratiskurser på nätet. De jag nu tittat på har gått och blivit betalkurser… Konkreta frågor om Photoshop och tips om t ex ramar, oskarp mask etc. finns ju här på forumet men finns någon bra gratis grundkurs på nätet???
När det gäller priset så är det svårare att påverka. Jag fick en skarp version 3.0 med en Microtekskanner och sedan var det bara att gradera upp…
Faktum är att det finns mer ”specialare” i Photoshop. Programmet för ju egna anteckningar i bildfilerna som används för att ställa in parametrar i programmet nästa gång man laddar in bilden. Andra program uppfattar inte dessa minnesanteckningar men de brukar försvinna om man lagrar bildfilen från ett annat bildbehandlingsprogram…
 
slabbe skrev:

Kan det (färghanteringen) påverka resultatet om man skall skriva ut saker på en vanlig hemma-bläckstråleskrivare? Eller bryr sig den i allmänhet bara om gamla hederliga R, G och B?
Är CMYK viktigt för att det är det som är standard, eller innehåller det mer information?

/Mattias - lite frågvis :)


Jag vill bara tillägga att RGB kan återge flera miljoner färgnyanser på skärmen, medan CMYK fungerar genom att "skjuta"olika nyanser in i varandra och långtifrån kan återge lika många nyanser som RGB.Därför är det bättre om man använder CMYK även om man skriver ut sin bild på en bläckstråleskrivare.Dässutom är det tillrådligt att använda sig av TIF-formatet(istället för t.ex.JPG).Detta för att undvika alltför hårda JPG-komprimeringseffekter.
 
steinick skrev:

Nej, man ska skicka RGB-data till sin bläckstråleskrivare. Skrivarens drivrutin konverterar till CMYK.

Så är det.
Skickar du som CMYK får du sämre och färre färger eftersom filen konverteras två gånger, först i operativsystemet till RGB och sedan till skrivarens CMYK som Lars-Erik beskriver. Du förlorar färger vid varje konvertering.

Dessutom, om du skickar som CMYK så är frågan vilken CMYK?
När du gör om filen till CMYK så har du skapat färginformation anpassat för en viss tryckpress, troligen standardbestruket papper tryckt i USA eftersom det är standardinställningen i Photoshop.
 
Det är möjligt att vi lämnat Tommys ursprungliga fråga nu men jag brukar också köra med RGB mot skrivaren… …fast det är ofta problem tycker jag. Om man ställt in datorn så att det ser bra ut i Photoshop och Internet Explorer etc. så kan man ju vara ganska säker på att det inte stämmer med grundinställningen mot skrivaren. Jag ställer därför in speciella värden i profiler i skrivarens set up så att utskriften stämmer med bildskärmens utseende. Det är inte så lätt eftersom bildskärmen lyser av sig själv och ett papper reflekterar ljuset. Jag har bl a använt Photoshops testbild med en utökad gråkil för att justera färgstick och kontrast. Jag har fått göra olika profiler för glossy, blankt och matt papper samt ytterligare nya profiler för olika pappersfabrikat… Det går lätt att hålla reda på profilerna eftersom man kan döpa dem med beskrivande namn.
Fick ett tips om att låta ett RIP-program analysera och justera bilden i samband med utskriften men det funkar inte utan speciella justeringar som jag tycker att man inte har kontroll på. Om en bild har t ex mycket rött så dämpas det röda av RIP-programmet. Om man istället justerar in profiler i skrivarens set up så har man låst koppling mellan bildskärmsbilden och skrivarbilden.
Har någon fått något RIP-program att fungera?
 
Tack för alla svar och för visat intresse.
Jag har via mail blivit tipsad om att ´cracka` program.Jag vill inte göra det.Vad tycker fotosidans medlemmar?
OK att cracka program?
Jag tycker inte det,även om det är frestande och inte alls svårt.
 
För att känna på och lära mej ett program kan jag tänka mej att köra med en knäckt version. Däremot skulle jag inte kunna tänka mej att använda ett knäckt program kommersiellt. Enl. uppgifter i vissa tidningar har tydligen var tredje program som används kommersiellt inte korrekt licens. Enanvändarlicens används t ex på två datorer eller 10-licens används utan antalsbegränsare i nätverk… Jag tycker att man måste ha en viss förståelse för att de som utvecklar programvaror måste ha betalt. Då blir ju programmen förhoppningsvis både bättre och billigare!
 
Haraldus skrev:
däremot köra med asseblerkod i kritiska programdelar i sina ?skarpa? program. Ett program som är skrivet i ?snygg assemblerkod? kan vara 100 eller 1000 gånger snabbare än program skrivna i kompilerad kod. I och med detta kan man kosta på sig mycket större räknenoggrannhet. Det är alltså egentligen inte något problem med tillgång på RAM utan det är tiden som är problemet. (En viss funktion i ett kompilerande språk t ex C++ eller Java kanske resulterar i flera tusen mikroinstruktioner medan samma sak kanske kan skrivas med 50 mikroinstruktioner av en driven assemblerprogrammerare?)
[lite offtopic]
Jag tror att det framförallt var förr i tiden som det fanns mycket att vinna på att själv göra innerloopar/hela program direkt i assembler. Idag är det viktigast att utnyttja cache-minnet effektivt (t ex, arbeta med lagom stora bitar av minnet/bilden åt gången) och få effektiv pipelineing (blanda instruktioner på bra vis och undvika hopp). För att uppfylla det senare kan det ibland vara en poäng att kolla på den av C/FORTRAN/x-kompilatorn genererade assembler-koden, och göra eventuella ändringar i källkoden (man kan ofta "lura" kompilatorn att generera en vettigare serie processorinstruktioner om det behövs).
 
Haraldus skrev:
Det jag ville peka på i mitt inlägg är att Photoshop, i många avseenden, är ett väldigt speciellt program.
Genom att berätta att Adobe till viss del använder assembler i Photoshop? Det är inget konstigt med att gå över till assembler i kritisk kod även om dagens kompilatorer gör ett fantastiskt jobb. Däremot så blir man mer låst till hårdvaran. Om jag inte missminner mig så har väl redan Adobe haft en del problem med att hinna med i Apples svängar. Ser man sedan till vad som händer på PC-sidan (Intel Xeon och AMD Opteron) så lär Adobes kodapor få en del att göra. Det är möjligt att man kan underlätta det genom att prata med hårdvaruabstraktionslagret men då känns det som om man missar poängen... Dessutom är det inte roligt att underhålla assembler.

Snälla... Det är inte många som har någon uppfattning om lågnivåprogrammering så jag tror inte att den här delen av tråden är av allmänt intresse och den förklarar så gott som ingenting. Kan ni inte bara lägga ner den?

Förresten -- jag är vare sig kodapa eller ''programmeringselit'' men visst händer det att jag öppnar en hexeditor då och då...
 
Tommy J skrev:
OK att cracka program?
Är det inte enklare att stjäla programmet direkt från butikshyllan? Om någon upptäcker dig så kan du alltid säga att stölden avser privat bruk. Nej... jag tycker inte att det är OK att knäcka program.

Adobe Photoshop är ett industriverktyg och då kostar det därefter. Om du inte har råd med industriverktyg så ska du kanske söka efter verktyg som riktar sig åt privatanvändare.
 
Tommy J skrev:
Tack för alla svar och för visat intresse.
Jag har via mail blivit tipsad om att ´cracka` program.Jag vill inte göra det.Vad tycker fotosidans medlemmar?
OK att cracka program?
Jag tycker inte det,även om det är frestande och inte alls svårt.

Jag tycker det är fel.

Att sedan Adobe verkar ha en avslappnad attityd till piratkopierandet av Photoshop är en annan sak. De verkar utgå från att de flesta piratkopior inte används. De finns bara på hårddisken för att ägaren skall imponera. De menar att yrkesanvändarna köper sina licenser och de flesta piratkopior aldrig skulle säljas(Mitt minne av en interjuv i Cap&Design i våras).

Jag tycker att Photoshop Elements verkar vara en vettig investering. Enligt Adobes hemsida är det få saker som saknas, bl.a. CYMK. Det är bättre än att använda en piratkopior.
 
Oscar skrev:
Du får nog ge lite mer belägg för detta påstående.. det verkar för mig väldigt konstigt om inte gimp och andra bildbehandlingsprogram använder tillräckligt stora flyttal vid olika operationer så att information förloras... Det finns ingen anledning för programmerarna att göra på annat vis om man inte varit väldigt sparsam med ramminne.

I GIMP 1.3.x representeras varje färg med 8 bitar. Det innebär att RGB och alpha-kanalen får plats i 32 bitar. Det planeras för stöd av bla 16-bitar/färg i framtida GIMP versioner.

Det finns dock redan nu en version av GIMP som stödjer 16 bitar per färg, men den är mer inriktad mot redigering av rörlig film och har sämre stöd för redigering av stillbilder.Se mer info på: http://filmgimp.sourceforge.net/

Photoshop har stöd för 16 bitar/färg. Jag vet inte om den alltid använder 16 eller om man kan växla mellan tex 8 och 16.

Fler bitar kräver såklart mer minne. De flesta har kanske gott om RAM-minne, men RAM-minne är långsamt och fler bitar borde ge färre träffar i cachen och därmed sämre prestanda.
 
Det är två olika saker.
8 resp. 16 bitars bilder är ett mått på antalet nyanser som finns i bilden. Detta påverkar i och för sig resultatet när bilden förändras.

När man pratar om dubble-byte och så vidare har det med hur programmet beräknar nya effekter. Enkelast kan man säga att ju fler byten som används, ju mindre blir avrundningsfelen.

Ett exempel:
ta bort 10% från färgen 135, det vill säga 13,5. Då får du färgen 121. Ta sedan bort ytterligare 10% (12,1) och så får du 109. Räknar du med decimaler så blir det 121,5 och 109,35. Du får ett mer exakt resultat. I detta fallet blir slutresultatet detsamma, färg 109, men om du fortsätter lite till så upptäcker du att du får avrundningsfel.

Tekniken används också i ljudbehandlingsprogram. Även om det är CD-ljud, 16bitar, eller mer vanligt 24 bitarsljud, så använder programmen 32 bitar vid förändring. Samma sak i vissa videoredigeringsprogram.
 
Om man kör Photoshop i 8-bitars mode och gör t ex ”Rotera bild” 1 grad eller ”Spara kopia” och konverterar från .TIF till JPG så blir resultatet mycket bättre i Photoshop jämfört med andra bildediteringsprogram därför att man INTERNT I PHOTOSHOP kör med dubbelbyte eller ännu fler siffror.
En liknande effekt finns ju i skannrar. En skanner som levererar 8 bit ut dvs 24 bit totalt måste ha en hårdvara (=AD-omvandlare) på minst 36 bit för att ge de 24 bitarna hög kvalitet.
När det gäller primärminnesåtgången så förstår jag inte riktigt resonemanget. Alla program läser ju in en ”skvätt” t ex ett block eller annan lämplig datamängd, bearbetar den och lagrar den i en noteringsfil. Det är inte alls säkert att bearbetningen går fortare om man har t ex 1024 MB jämfört med 256 MB. Förresten klarar inte Win 98 av att hantera mer än 256 MB. Inte ens Win 2000 kan utnyttja ett stort primärminne på ett effektivt sätt tillsamman med Photoshop.
Att hantera många siffror internt är givetvis mer datorresurskrävande men hur lång tid det tar beror också på hur programmet behandlar algoritmerna internt.
Det jag ville ha sagt är att jag ser Photoshop som oumbärligt därför att Photoshop ger högre kvalitet vid t ex konvertering från .TIF till .JPG. Man får alltså bilder med högre kvalitet vid samma filstorlek. Dessutom har jag fått för mej att Photoshop generellt sett processar snabbare än andra bildbehandlingsprogram. (Observera att jag INTE är någon handelsresande i Photoshop! Tvärtom, men jag tycker att det är kul att jobba med bra grejer!)
Ser att Anders redan förklarat det här fast på ett annat sätt…
 
Anders:

Ja, som du påpekar använder säkert många verktyg och plugins algoritmer som internt arbetar med större precision eller flyttal. Men i "GIMP-kärnan" representeras varje färg med 8 bitar och jag ville påpeka problemet att varje algoritm får 8 bitar som indata och måste lämna ifrån sig ett resultat på 8 bitar till "GIMP-kärnan".
 
Harald:

Vi missförstår nog varandra eftersom vi syftar på olika saker med ordet "internt". Du menar tex rotations-algoritmens interna beräkningar och jag tänker på de datastrukturer som tex rotations-algoritmen får sin indata från och returnerar sitt resultat till när algoritmen är klar.

Vi missförstår antagligen varandra även om minnesåtgångsaspekten. Oscar skrev att "Det finns ingen anledning för programmerarna att göra på annat vis om man inte varit väldigt sparsam med ramminne." Jag ville då lyfta fram att en viktig anledning till att vara sparsam med RAM är att bussen mellan CPU och RAM ofta är långsam. Dessutom tror jag att de olika cache:arna mellan CPU och RAM får färre träffar om mer data måste skickas. Men det sistnämnda beror förståss på i villket mönster minnes-accesserna sker.

Hurvida Photoshop, GIMP eller något annat program är snabbast eller ger bäst resultat har jag ingen aning om. Det får du diskutera med någon annan.
 
ANNONS
Upp till 6000:- Cashback på Sony-prylar