berland

Nei, dette er ikke spesielt genialt.

Jeg ser noen showstoppere:

* Proprietær teknologi, det betyr at dette blir begrenset til dette firmaet, eller til en håndfull som velger å lisensiere det, og dermed får det aldri noen særlig utbredelse, og da er det bare å glemme det.

* Problemet som det liksom løser er ikke noe problem. Minnekortpris er ikke noe problem. "Problemet" med å håndtere to filer løses på en bedre måte ved å bruke arbeidsflytprogramvare som håndterer de to filene samtidig.

* Det kommer til å koste penger. Bruke penger på å løse et problem man ikke har?

Jeg blir lettere sjokkert av at det kan finnes et marked for å selge en bitteliten komponent av arbeidsflyten for bildebehandling som separat programvare til hele 200 dollar.

Jeg kommer ikke på noen objektiver som passer til alle kravene dine, jeg tror ikke du finner det. Jeg vil likevel anbefale deg å starte med Nikon 16-85 VR, selv om det ser ut som den koster rundt 4400 kr.

Samt, med flyttall så blir fargeverdiene mer nøyaktig. 0,00034565 er mer nøyaktig når man skal bearbeide videre, enn om fargen ble 70. Altså lettere å unngå feil i effekter pga avrundinger.

Det er vel ikke overgangen heltall til flyttall som er viktigst, det er overgangen fra 8-bit til 32-bit, om disse bitene brukes til heltall eller til flyttall har ikke like viktige konsekvenser.

Jeg regner med det er enklere for programmererene å tenke flyttall mellom 0 og 1, på den andre siden er heltall litt bedre for portabilitet (flyttallsberegninger kan fort variere i de siste sifferene på ulike plattformer) mellom mye rar hardware og for framtida. TeX er et eksempel på noe som har valgt heltall pga. portabilitet.

Trykk på penselikonet og tegn i bildet ved å holde inne museknappen. Verre er det ikke. Med effekter mener du kanskje det du får ved å høyreklikke i bildet og finne noe under 'Filter'-menyen?

Gimp og Picasa er ikke samme type program (de forsøker å gjøre forskjellige ting), så de er ikke helt sammenlignbare.

Jeg vet ikke om noe bedre fri programvare enn Gimp for bilderedigering.

Man kan si hva man vil om Wikipedia (engelsk/norsk) per i dag ang. kvalitet. Det som jeg mener er viktigere, er hva man tror er situasjonen om 10 år. GFDL-lisensen medfører at wikipedia's kvalitet kommer til å stige monotont. Noe annet enn en GFDL-kompatibel lisens for snl tror jeg betyr at jeg ikke vil bruke tid på det, da det ikke vil være framtidsretta.

Det viktigste med Wikipedia er innholdet, og innholdet er pga. lisensen, uavhengig av organisasjonen bak Wikipedia. Det gir oss garantier for at innholdet kommer til å være tilgjengelig og editerbart selv om stiftelsen bak Wikipedia en gang skulle gå dukken. Sånne garantier er helt nødvendige for at store norske leksikon skal bli en passe suksess.

Dersom Store Norske tør utgi leksikonet under GFDL, så er det all ære og berømmelse til dem for å klare se framover i tid. Det er det få i den proprietære businessverden som klarer.

Non steder man får tak i themes og shit til denne tlf'n? Og non måte å få den raskere? Er jo gørrtreg..

Telefonen er skandaløst treg ja. Tre-fire sekunder å søke i kontaktlista for hvert tegn jeg trykker, og jeg kan aldri taste fort, fordi jeg etter hvert trykk må sjekke at telefonen fikk tastetrykket med seg.

Det går visstnok an å overklokke telefonen, du finner mer info via google.

Anbefaler deg 10mm. Ta med deg en runde med objektivet i fjellet med en kamerat som løper litt rundt noen dager i forveien, slik at du får sett på hvordan bildene blir med tanke på forvrengning. Mye forvrengning nært kantene selvsagt, noen ganger blir det stygt, andre ganger kan det gi en ønsket effekt for slike motiver.

Se litt i krystallkula og tenk litt grunnleggende økonomiske prinsipper. Friheten til Linux (dvs. GPL-lisensen) gjør at enhver programmeringsluring rundt omkring på verdens universiteter/høyskole/gutterom/jenterom har muligheten til å gjøre operativsystemer og/eller programvare bedre, ved å bidra på toppen av det alle andre har gjort. Ingen firma i verden er store nok til å kunne mobilisere like mye programmeringskompetanse, og produsere kode med akademisk perfeksjon og samtidig tjene penger.

Det ligger i forretningsmodellen til Microsoft (og Apple, og alle andre aksjeselskap) at perfekt kode ikke er nødvendig, de skal bare lage god nok (eventuelt pen nok innpakning) til at de tjener penger. Så lenge folk stort sett har kun prøvd et eneste alternativ (beklager, det holder ikke med spede mislykkede forsøk på å installere noe annet) så lever man i sin egen lille verden og tror at man kan sette merkelappen "bra" på programvaren/OS'et man bruker. Enhver med litt økonomisk forståelse skjønner at dette er helt meningsløst. Forretningsmodellen forteller mer, og den tilsier at her er det mye å gå på kvalitetsmessig.

Wikipedia er helt tilsvarende, og her er det også lisensen som utgjør hele forskjellen. (Wikipedia er kun den tekniske løsningen, det er innholdet sammen med lisensen GFDL som er det viktige). Ingen kan lenger mobilisere nok luringer (som skal ha lønn) til å slå Wikipedia på innhold og kvalitet og samtidig tjene penger.

GPL/GFDL-lisensene gjør at Darwins prinsipper for evolusjon kan anvendes, og da er ikke jeg i tvil om hvilken vei utviklingen vil gå, og på hva jeg selv vil bruke tida mi på.

Jeg anbefaler Hugin (kryssplattform). Sist jeg prøvde photomerge i Photoshop var den langtfra god nok, den kunne ikke korrigere for optikkprojeksjoner (eller hva jeg nå skal kalle det) eller vignettering. Hugin (jeg har bare prøvd linux-versjonen) er utrolig bra, last inn en serie med bilder og så kverner den gjennom (tar noen minutter, avanserte ting gjøres) og spytter ut høykvalitets panorama.

Bildet kunne hatt godt av mer kontrast.

Sist jeg sjekket hadde ikke Lite-versjonen støtte for å bruke mer enn én kjerne om gangen. Da er jeg nødt til å ha Pro-versjonen. Har dette endret seg siden folk her sier man klarer seg med Lite?

(Er det noe jeg gjerne skulle hatt en fire-åtte kjerner for, så er det Bibble)

Hvordan gjør dere det med lagring av bilder?

Har etterhvert en full liten lagringsenhet med bilder, men burde kanskje begynne å tenke på back up alà prinsippet bedre føre var.....

Hva bruker du til å lagre dine bilder på?

Hvor mange steder lagrer du bildene?

Hvor stor kapasitet bør en lagringsenhet ha?

Bedre med flere små, enn en stor?

Hvor oppbevarer du enheten(e)?

Hvor ofte tar du back up?

 

På forhånd tusen takk for svar.

Har backup av bildene på alle datamaskiner innenfor huset, og også på to steder utenfor huset.

Jeg kjører kun backup til harddisker på maskiner som står på, ikke noe DVD-brenning (det tar for mye tid), og jeg formaterer aldri minnekortet før backup er tatt internt i huset og også ut av huset (anta alltid at din harddisk vil kræsje når som helst).

Backupprogramvare er "rsync", gratis og kryssplattform (open source). Det tar meg ett sekund å initiere en backup. Dette er viktig, tar det for lang tid å ta backup, blir det ikke gjort.

I disse tider der det er en monoton stigende utvikling blant fri programvare, så hadde jeg aldri i verden startet med å lære meg programmeringsspråk som er tuftet på en proprietær grunntanke (les: alt fra Microsoft). Min anbefaling er å holde seg unna det som ikke gir deg plattformuavhengighet, skal man se 10 år framover i tid så er det lite tvil om at det vil lønne seg (kun på kort sikt er det klart det fortsatt kan være økonomi i proprietære systemer).

Anbefaler Nikon 70-300 VR.

... Det er en del kameraer som ikke kommer opp som ekstern disk, slik at man må bruke drivere eller software for å kopiere over bildene. ...

Akkurat det er jo en god grunn til å holde seg langt borte fra akkurat de kameraene.

Mine bilder ligger derfor lagret som følgende:

E:\Bilder\<År>\<Måned>\(<Begivenhet>\)

Jeg lagrer som /bilder/2007/01 osv. Hvis det er en spesiell begivenhet/tur så heter kanskje katalogen /bilder/2007/01-glittertind. Fungerer fint for meg, da blir katalogene sortert riktig, og jeg har alle bildefiler på samme nivå i filhierarkiet.

Som råd til andre har jeg et jeg synes er veldig viktig, det er å være skeptisk til å bruke kommersiell programvare for å organisere bildene, med mindre man selv skjønner og vet at tiden man bruker på å kategorisere/sortere/legger til metadata ikke blir bortkastet om programvaren plutselig opphører å eksistere. Her skal man tenke 10-50 år fram i tid (eller så langt du vil). Jeg blir overrasket om ikke en hel del av formatene og databasestrukturene som noen av dagens programvare er helt uleselige da.

Selv vet jeg ikke hvilke program som hadde passert dette nåløyet hos meg, da jeg kjører helt min egen struktur, kun basert på kataloger. Inni f.eks. 01-januar ligger nef-filene, jpg-filene og også txt-filer som jeg bruker som bildetekst. Dette er jeg sikker på jeg vil klare nyttiggjøre meg om 50 år.

Siden alt ligger inni en katalog, er dette veldig enkelt å synkronisere for backup. Jeg bruker rsync.

Jeg finner det ikke nevnt i testen, men det er da et viktig poeng hvilket filsystem man kjører på SSD-disken. Jeg antar man har kjørt NTFS, som vel som alle andre filsystemer er optimalisert (ihvertfall til en viss grad) til harddisker og deres egenskaper (tenker spesielt på høy aksesstid). Har man ikke slike flaskehalser på mediet sitt bør man holde seg unna FAT32/NTFS (og de tilsvarende på andre operativsystemer). SSD-disker har en flaskehals i skrivehastighet, og filsystemene som brukes bør derfor muligens rettes inn mot dette.

Det finnes to open source-alternativer som jeg kjenner til, JFFS2 og YAFFS (med sine svakheter de også forøvrig).

En ting er ihvertfall sikkert, jeg kjøper ikke en slik disk for å tynge den ned med et uegnet filsystem. Testene som ble gjort i artikkelen som ikke gikk direkte på fysiske egenskaper, synes jeg blir mer intetsigende når filsystemet som var brukt har et fortrinn på det ene mediet (dog, SSD kom jo godt ut likevel).

En helt annen ting jeg har tenkt litt på i det siste er hvor lenge det vil være program som leser NEF-filene mine, så en gang jeg har for mye fritid burde nok en DNG-versjon blitt laget også.

Helten din heter Dave Coffin, som har reverse engineeret NEF-formatet (og de fleste andre), og vedlikeholder et ANSI C program i åpen kildekode for å dekode råformatfilene. Kildekode i ANSI C for å gjøre dekoding er den beste nåværende garanti jeg kan tenke meg for at datamaskiner om 50 er i stand til å dekode NEF-filer jeg tar i dag.

Se http://en.wikipedia.org/wiki/Dcraw

Filserveren min i dag består av Windows Xp, så blir for mye jobb å gå over til linux.

En liten NB: Min løsning er helt plattformuavhengig. Det går på Windows XP (via cygwin) eller på Linux, Mac eller hvilket som helst unix-løsning du kan komme på.

Jeg hadde ikke stolt på å hatt bildene kun ett sted, RAID eller ikke. RAID hjelper ikke mot brann, men hjelper litt mot harddiskkræsj. Siden RAID ikke løser problemene med diskkræsj helt, så gidder jeg ikke selv bruke tid på det, jeg synkroniserer heller mot ulike maskiner, også utomhus. Til synkronisering bruker jeg 'rsync' (open source og plattformuavhengig), og for thumbnailgenerering (og webversjongenering) bruker jeg imagemagick (open source og plattformuavhengig) via bash-script.

Jeg er veldig bevisst på å ikke gjøre meg i minst mulig grad avhengig av noe som helst kommersiell programvare. Det vil overraske meg om den kommersielle programvaren i dag for lagring og backup er kompatibel med seg selv om 10 år, hvis leverandøren i det hele tatt eksisterer.

Et eksempel på bash-script for thumbnailgenerering kan kikkes på fra http://www.pvv.ntnu.no/~berland/nef/. NB: Det vil muligens kreve noen små modifikasjoner for å kunne brukes på andre og på andre utestede plattformer.

Det var det jeg forslo. Og så vidt jeg kan se, så ser det ut som om det lønner seg å nedskalere i Photoshop.

Det er jeg ikke sikker på om jeg er umiddelbart enig i ut fra bildene. Hvordan var oppskarpingsinnstillingene i kameraet? Jeg ser muligens primært forskjellig unsharpen mask på de to 6MP-bildene.

(jeg mener jeg har ganske gode grunner til å påstå at selve interpoleringen i kameraet er god nok, men jeg tviler ikke på at andre effekter og innstillinger kan gjøre noe)

Først og fremst kommer jeg til å bruke bildene på dataen, altså ikke printe dem ut, og da har jeg jo ikke bruk for de mange pixlene (med mindre jeg skal kroppe ol.) ettersom skjermen min kun er 1280*.. Får jo ikke utnyttet ekstra pixler da uansett, derfor lurer jeg på om jeg likesågodt kan skyte med lavere oppløsning. Dette ville jeg gjort om det ikke hadde noe annet å si for kvaliteten, enn at jeg får færre pixler.

Svaret er ja, da kan du likesågodt skyte med lavere oppløsning.

Men jeg må få si at jeg synes spørsmålet er litt rart... hvis du tar bilder i en situasjon der ren bildekvalitet faktisk er viktig, så bør du unngå jpeg uansett. Hvis du i det hele tatt vurderer å sette ned oppløsningen så kan ikke skarphet og bildekvalitet være så fryktelig viktig.

Og satt i den sammenheng, så er egentlig svaret på trådstarters spørsmål nei, det har ikke noe særlig å si om man går ned til 6MP JPG-filer.

om jeg senker oppløsninga fra L (best kvalitet, Large) til M (medium, og da ca 6MP), vil jeg jo selvfølgelig få bilder som opptar mindre plass, men vil dette resultere i tilsvarende dårligere kvalitet på bildene?

En reduksjon fra 10MP til ca 6MP vil gi en "tilsvarende" reduksjon i kvalitet, ja. Om det er synlig, kan du bare selv bedømme. Jeg vil tro du må lete (med lupe) etter forskjellen, den er målbar, men ikke lett synlig.

Jeg vil anta at kameraet bruker kubisk interpolering, noe annet ville vært utrolig rart, og da er det svært lite mer å hente på å skalere i Photoshop eller lignende i stedet for, denne forskjellen vil det overraske meg om er målbar. Jeg antar også at kameraet nedskalerer (interpolerer) direkte fra raw-data, så det er aldri noen 10MP jpg-bilder med i prosessen som forstyrrer. Her skal man også tenke på at 10MP-dataene også er Bayer-interpolert opp, 10MP jpg-bildet som du kan få ut har egentlig ikke så mye informasjon i seg som det gir inntrykk av.

Med mindre du setter virkelig dyr optikk på kameraet ditt, så tror jeg egentlig ikke det er noe særlig å hente på de siste 4 MP. Og hvis du bare skal ha JPG til slutt uansett, og ikke trenger RAW, så vil jeg si at det er bare å fyre i vei på 6MP.

NB: Nå har jeg bare tatt antall piksler og interpolering med i vurderingen. Hvis medium-settingen din også innebærer lavere JPG-kvalitet, så kommer det i tillegg, og vil da i såfall sikkert innebære en større degradering enn selve pikselnedskaleringen.