típustól függően még a képkészítéskor használt JPG motor beállításai sem mind érhetőek el egyszerűen (a Nikon kódolva tárol el bizonyos paramétereket, pl. már a fehéregyensúlyt is), de még ha megvannak, akkor sem jutsz velük semmire, hiszen teljesen más a földolgozó motor
bizonyos dolgokat még egyszerűen le lehetne fordítani (mondjuk a "+1 élesítés" mit jelentsen), de már a színek, árnyalatok kezelése is eléggé más, és néhány funkció eleve hiányzik, vagy teljesen eltérően működik (különösen az árnyék-kompenzációs eljárások)
ezért csak gyártói program tudja ugyanazt az eredményt előállítani minden állítgatás nélkül, hiszen ott azonosak az algoritmusok, és persze ők tudják értelmezni az összes beállítást
ezt mar en is kerdeztem mashol. engem is erdekelt volna egy olyan profile, ami a kamera altal keszitett jpg-t automatice megcsinalja. azt irta a kollega, hogy nyilvan ahhoz a kamera gyartoja algoritmusa kellene, ami meg nem hozzaferheto.
pont úgy kinézni sosem fog, csak a kamera gyártójának programjával megnyitva...
(amit a fileböngészőben látsz, az a fényképezőgép által készített, RAW-ba ágyazott JPG: azt pedig csak azonos JPG motorral lehet minden játszogatás nélkül pont úgy előállítani. Más programmal csak közelíteni lehet, és nem automatikusan)
Szervusztok! A RAW fájlok konvertálása nevű index fórumban láttam, hogy szereted, szeretted a rawtherapee programot. Ezzel kapcsolatosan kérek segítséget Tőled. Hogyan tudom elérni azt, hogy az alapértelmezett képfeldolgozási módja egy képnek az legyen, ahogy az a rawtherapee állományböngészőjében látszik a digitális negatív (én PEF-fel dolgozom)? Másként: úgy nézzen ki a szerkesztésre betöltött kép, ahogy a rawtherapee állományböngészőjében eleve látszott. Gondolom a kérdésemre a megoldás nem a legegyszerűbb, és sok mindennek a függvénye. RawTherapee 4.0.8 Xubuntu linuxon kísérletezgetek. Köszönöm szépen előre is esetleges segítséget!
itt egy programozói grafikus rutinkönyvtárról volt szó.
Ez a topik raw konverterekről szól, ahol a rawkonverterek rawfeldolgozása a szempont, nem a windows rutinkönyvtárak alkalmazása nemgrafikus felhasználásra szolgálo viccmonitorfelbontásokkal.
Természetesen további kellemes rawfeldolgozást 1024x600-on atom processzorral 2G rammal, mindenkinek kell a adrenalinbomba, és ez még mindig kényelmesebb és kevésbé veszélyes mint hegyet mászni.
De lássuk konkrétabban
A kezelőfelület számomra nem volt logikus és könnyen használható, mivel nem követ semmilyen konvenciót, ami a programok általános kezelőfelületére vonatkozik.
Ezért kérdeztem, hogy más rawkonvertert láttál-e már, mert a RT kezelőfelülete nagyjából megegyezik a méltán népszerű LR felületével már ha a felület alatt azt értjük, hogy mi hol helyezkedik el a munkaterületen.
Nekem nem jön be ez a szürke felület
spec a fentemm emlitett LR szintén ilyen szürke, emellett a RT-ban kapásból 10 féle szinösszeállitás között válthatsz ha nem jön be a default szürke
Furcsa volt a baloldali navigáció a könyvtárstruktúrában
Mivel a LR-t használom nagy megelégedésssel, igy nézd el nekem, hogy mindig ezzel jövök, de a LR-ban pont ugyanigy megy a navigálás a bal oldalon ugyanilyen könyvtárstukturácal.
Én ezen a kis laptopon elég sok Windows alkalmazást használok, de mind kivétel nélkül jól alkalmazkodik a fönt említett felbontáshoz és dpi-hez. Sajnos ez a grafikus motor nem.
Ne sértsd már meg a laptopokat azzal, hogy egy mobiltelefon felbontású netbookot lelaptopozol. Megértem a készítőket, hogy eszükbe se jutott 1024x600-on egyáltalán megnézni hogy is néz ki a programjuk, nincs olyan grafikai program aminél ne lenne az 1024x768 alapkövetelmény
A legördülő listákból elég nehéz választani, főleg így a touch paddel
Na itt adom fel. Biztos vagyok benne, hogy kormánnyal vagy joystickkel is szarul kezelhető az RT felülete, még szerencse, hogy nem ezzek szoknak a népek képfeldolgozást végezni.
Eh, vitatkozzon a halál egy fotós forumokban összesen 2hsz-al rendelkező "programozóval".
Attól tartok, nem teljesen értetted meg, amit írtam: raw konvertálásról itt szó sem volt; itt egy programozói grafikus rutinkönyvtárról volt szó. Egy Atom processzorra természetesen egyáltalán nem kell egy raw konvertert optimalizálni, mivel egy Atom processzor kiváló és bőségesen gyors ilyen célokra, a Lightroom és - ahogy írtam - a Therapee is remek sebességgel konvertálja a rawot, úgyhogy ezen megállapításodat, sajnos, nem értem, mire vonatkozik.
Ez úton közölhetem továbbá az örömhírt, bár az írásomban erre is kitértem, hogy sem a Lightroomnál, sem más, a Windows gui-t használó alkalmazásoknál nem jelentkeznek azok a hibák, amikről írtam, mivel ez a képernyőfelbontás elégségesen nagy, széles körben elterjedt, és a Windows grafikus rutinkönyvtár kiválóan boldogul vele. De ez eddig is nyilvánvaló volt.
Kipróbáltam ezt a RawTherapee programot, az aktuális Win32 4.0.6.4-es verziót. Sajnos, eddig nem túl jó tapasztalataim születtek.
Biztosan egyedül vagyok ezzel, de ez a GUI szörnyű.
Én ezt most itt egy netbookon szerettem volna használni, a képernyőfelbontás 1024x600, a betűméret 120 DPI. A kezelőfelület számomra nem volt logikus és könnyen használható, mivel nem követ semmilyen konvenciót, ami a programok általános kezelőfelületére vonatkozik. Nekem nem jön be ez a szürke felület és ez a grafikus motor sem, amit használ. Furcsa volt a baloldali navigáció a könyvtárstruktúrában, mivel nem a hagyományos metódust használja, mint amit az általános Windows kezelőszervek. Amiatt kell ezt a motort használni, hogy könnyen implementálható, fordítható legyen a program az összes támogatott operációs rendszerre? Én használok több olyan programot is, amik nem a Windows standard gui api-t használják, például .Net vagy Java virtuális gépen futó alkalmazások, tehát azok is könnyen hordozhatóak más platformokra, de sokkal szerencsésebb a grafikus elemek működése.
Én ezen a kis laptopon elég sok Windows alkalmazást használok, de mind kivétel nélkül jól alkalmazkodik a fönt említett felbontáshoz és dpi-hez. Sajnos ez a grafikus motor nem. Az indulás után elég kaotikus látvány fogad. A kezelőszervek, gombok egymásra vannak csúszva, hosszan kerestem a zoom out gombot, aztán rájöttem, hogy a mellette lévő beviteli mező eltakarja, de egy-két pixel kilátszik belőle, úgyhogy nagy ügyességgel, de meg lehet nyomni. A legördülő listákból elég nehéz választani, főleg így a touch paddel, mivel ahogy rákattintok, nem gördül le, hanem azonnal eltűnik, aztán rájöttem, hogy ha kettőt kattintok, és nyomva tartom, akkor ott marad, és közben húzom, felengedéskor pedig kiválasztja. Magyar nyelvre ezzel a módszerrel majdnem lehetetlen volt átváltani, mivel olyan hosszú volt a legördülő lista, hogy kilógott a képernyőből, és ugye ahogy felvettem az ujjam, nyomban el is tűnt.
A Preferences ablak, és gondolom más párbeszédablakok külön nehézséget okoztak, mivel az aljuk úgy kilógott a képernyőből, hogy lehetetlen volt leokézni, és a kezelőszervek zöme sem látszódott. A Windows guit használó alkalmazások esetében ilyenkor van jobboldalt egy csúszka, amivel föl-le tudok lapozni. Hát itt nem volt, így a beállításokat sem tudtam rendesen módosítani. Szerintem van még egy pár száz féle netbook, aminek ilyen a felbontása.
Egy normális gui-nál alapvető, hogy egy párbeszédablak megnyitásakor az input focus valamelyik gombra, az okéra, vagy mégsemre kerül, így legalább az enterrel le tudnám okézni, de sajnos ez a gui annyira elrugaszkodott, hogy ez sem ment, így semmit nem tudtam módosítani a Preferencesben, pedig kipróbáltam volna, hogy a "Use system theme" mennyit segít a dolgon. No, sebaj, majd az asztali gépen megnézem.
A Preferences (General) párbeszédablak nekem amúgyis rettentően zsúfolt, ömlesztett, nehezen áttekinthető. Az alkotóban meg volt a szándék, hogy szeparáljon, de ez nem sikerült jól: hosszan kell nézni az ablakot, főleg ennek a 28 szürkeárnyalatos témának köszönhetően, hogy akkor most melyik checkbox és lista hova is tartozik, mert össze-vissza állnak. Érdemes volna megnézni például az ACDSee preferences párbeszédablakát, hogy milyen egy jól áttekinthető párbeszédablak.
A tervező helyében én nem arra mentem volna rá, hogy minél vagányabb darkos színséma legyen, hanem arra, hogy egyszerű, letisztut, könnyen kezelhető programfelület szülessen, amit az is tud kezelni, aki korábban sohasem látta.
Amúgy a program viszonylag elfogadható sebességgel futott, bár én nagyon türelmes ember vagyok. :-) A processzor egyébként 1,66 GHz-es Atom, és 2 GB ram.
A fölső "Find" beviteli mező is kb. két mellette lévő gombot eltakar. Ezek mért nem tudnak alkalmazkodni a képernyőfelbontáshoz és beállításokhoz? Ezt azért egy XXI. századi grafikus api-készletnek már kéne tudnia.
Aztán sikeresen betöltöttem egy-két fotót, és gyanútlanul rányomtam az "Edit current image in external editor" nevű gombra, mert kíváncsi voltam, hogy arra mit nyit meg. Na ez már sok volt, elkezdte processingolni az image-et, majd néhány perc után megjelent középen egy fehér üres ablak "Main button sendtoeditor", és azzal az egész mindenség összeomlott. Nos, nem tudom, hogy mit mondjak, én is programozó vagyok, és úgy 15 éves koromban terveztem egy gui rutinkönyvtárat - akkor még csak DOS volt -, de az ennél sokkal-sokkal stabilabban futott.
Nos, remélem, a készítő a kissé negatív kritikát sem veszi rossz néven,
és sikerül majd javítani ezeken a hibákon. Sajnos egyelőre a program
fő funkciójáról nem tudok vélemény alkotni, mert az említett összeomlások
és a kezelőfelület nehézségei miatt odáig nem jutottam,
de majd kipróbálom az asztali gépen is nagyobb monitorral.
Egyébként Ti most hogy rangsorolnátok minőség szerint a RAW konvertáló
programokat - ha mondjuk az első ötöt kéne megjelölni?
A minőségük nagyon hasonló, az árak meg ,,kissé" szórnak: RAWtherapee, Nikon Capture NX2, és a Photoshop. Talán legjobb a Nikon saját programja, de erős gép kell hozzá. mert különben idegörlő tud lenni. Ha a gép nem elég gyors, csak kötegelve érdemes használni, nálam legalábbis így működött. Hamarosan többet fogok tudni, mert megvettem az utólsó verziót, és egy szép magyar nyelvű leírást adtak hozzá. (Egy jópont a Nikonnak.)
Urak! Használhatnék Adobe Lightroomot, a 3.2-es verzió -okos barátommal szólva- mennyire releváns? Van olyan verzió, amelyik tud magyarul? Ez verzió tudás, kezelhetőség tekintetében milyen viszonyban van a Canon vázzal kapott Digital Photo Prof-fal?
A RSP-ről ellene tovább lépnem, de nagyon nehéz a váltás. Mivel épp lejárt a Lightroom próbaverziója, hát a RAWtherapee-vel játszom. Van, amiben megdöbbentően jó, például piros ingeseket fényképeztem vakuval, és a jpg-n az egész ing homogén vörös folt, míg a RAW-ból konvertálton (nyilván, ami egyedi verziót felajánl) minden egyes gyűrődés szépen látszik.
Hanem úgy általában a bőr textúrájával nem vagyok megelégedve, mintha látható pontokból állna. Ha kiveszem az élesítést, meg a zajcsökit bekapcsolom, akkor meg egyszerűen elmosódott lesz. Van valami szokásos kombináció, ami szebb lesz?
Valamint szép fekete-fehér egyszerű megoldása is érdkelne, ha valaki volna oly nagylelkű.
Nem lesz még egy olyan, mint az RSP, a fene a belüket...
valóban könnyen lehet, h ez a specifikáció egyszerűen hiányzik a RAW file-ok többségéből, így aztán muszáj ismernie az adott típust egy konverternek, h helyes színeket adjon (és expót: abban is van eltérés az egyes modellek között, hogyan használják ki az adott érzékelőt, nem ugyanakkora tartalékot hagynak a csúcsfényeknek)
de vmi más oknak (különbségnek) is kell lennie, mert ez még áthidalható lenne RAW feldolgozó program csere nélkül is, kamera-profil file-okban tárolva ezt
Más tudja valaki, hogy a BAYER szűrőt hogyan illesztik a pixelek fölé? Ha a pixel mondjuk 5 mikron széles, akkor az illesztés pontossága kb. 500 nanométer? Hogyan lehet ezt gyártani? Vannak-e szerencsésebb vagy szerencsétlenebb példányok?
A ,,színszűrő változik" hát igen erre gondoltam én is hogy a Bayer szűrő nem mindíg ugyanaz. Ez esetben viszont a szűrő számszerű fénytani adatait hiányolom a gépspecifikációból, hiszen egyértelmű hogy a gép csak azon színeket tudja visszaadni, amelyeket a színháromszögben a Bayer szűrő három alapszine közrezár. Jó lenne ha a színvisszaadást nem csak megbízhatatlan tesztekből, hanem a gyártó specifikációjából ismerhetnénk meg.
a gyártó részéről érthető: alapvetően fontos, h a gyári konverter állítgatás nélkül képes legyen ugyanazt az eredményt adni, mint a kamera JPG motorja - márpedig mivel ez utóbbi folyamatosan változik, fejlődik az új típusokkal, persze új változat kell a RAW konverterből is, ami tartalmazza ugyanazok az új/változtatott algoritmusokat
de egy külső cég által írt feldolgozónál nincsen ilyen szempont, az sosem adta ugyanazt mint a gyári, így ha a nyers adatok tárolása nem változna, nem lenne akadálya, h frissítés nélkül fölismerje az új modellek által készített file-okat is - de vmiért tényleg változnak a RAW-k, sajnos, így aztán frissíteni kell ezeket is...
pedig nem ritkán tökugyanaz az érzékelő is egy-egy új típusban
persze ha csak a színszűrő változik, az is már érthető ok lehet arra, h a földolgozáson is változtatni kelljen, különben fals színeket eredményezne - de ez tárolható lenne típusfüggetlen formában is
Teljesen igazad van. Komoly munkánál a Raw megőrzése is indokolt. Az óriás tiffek tárolása sem veszélytelen. Egyszer egy ,,szép" napon sikerült törölnöm egy koplett winchestert utánna a barátom egy hétig dolgozott az adatok visszanyerésén. A nyomoronc JPG-k 98% megmaradt , a komoly TIFF-k nagyrésze elveszett. Úgy néz ki, minél nagyobb egy file, annál könnyebben becsúszhat valami hiba.
A TIFF azért nem teljesen oké, mert mellette meg kell tartanod az eredeti RAW-t, ha jelentősen másképpen szeretnéd előhívni a képet. Hiába a TIFF, még 16 biten is eldobhatsz így adatot. És így óriási a helypazarlás. (mondjuk a TIFF eleve óriási)
A DNG ezt oldja meg, hogy egységesíti a formátumot és mellette nem kell tárolnod az eredetit. (megjegyzem, pl. a kamera által előállíott Pentax DNG nem felel meg a DNG szabványnak, külön kezelik a konverterek)
Ami számomra igazán elmebeteggé teszi a dogot, hogy a totális inkompatibilitás ellenére minden egyedi RAW formátumban megvan a TIFF TAG alapformátum, komoly headert létrehozva a fájlban. És ebben sincs két egyformán értelmezhető bit jóformán... akkor meg minek? Ugyanaz az ID az egyik gyártónál teljesen mást jelent mint a másiknál, sőt még a TAG típus (1,2,4 byte, pointer stb.) sem azonosan értelmezett. Komolyan mondom ez az iparág szégyene kicsit. Gyakorlatilag ha az első byte lenne a gyártó, kis túlzással mondva pont ennyit érne.
