Auto Adjust Photo

Szoftver

Egy szoftvert fejlesztek, amelyet publikálni szeretnék néhány fórumon, mert jó lenne visszajelzés a szoftver működését illetve használhatóságát illetően. Sajnos eddig nagyon kevés visszajelzést kaptam az letöltések számához képest. Ha valakinek kedve támad kipróbálni, szívesen veszek mindenfajta véleményt.

Leírás:

  • INGYENES Automatikus Fotó beállító szoftver
  • Egyetlen klikkeléssel korrigálja a kép színeit

A program azt a célt szolgálja, hogy egy tetszőleges fotó képet automatikusan tudjunk beállítani, más szóval legjobban láthatóvá tenni mindössze egyetlen klikkeléssel. Ez a kép kontrasztjának, színegyensúlyának és gammájának analizálás utáni automatikus beállítását jelenti.

Nem minden eredeti kép színbeállítása megfelelő. Némelyek lehetnek túl sötétek, túl világosak, vagy éppen a színeik túl sárgák. Lehet a középtónusa túl sötét - ekkor például hiába tartalmaz sok világos színt, általában akkor is sötétnek tűnik. A program ezeket a paramétereket igyekszik analizálás alapján a lehető legmegfelelőbben beállítani.

Főként olyan felhasználók számára jelenthet ez kényelmet vagy megoldást, akik nem értenek a képek beállításához bonyolult grafikai programokkal, vagy éppen nem akarnak nagy képmennyiség esetén sok időt tölteni a fotók egyenkénti kézi beállításaival.

Név: aaPhoto

Használat (parancssorból): $aaphoto mappa_neve

Linkek:

http://log69.com
http://log69.com/aaphoto.html

Letöltés (linux verzió):

http://log69.com/downloads/aaphoto_linux.tar.gz
http://log69.com/downloads/linux/aaphoto

( trey | 2007. 07. 08., v – 20:47 )

"Licenc

Ez egy szabad szoftver; terjeszthető illetve módosítható a GNU Általános Közreadási Feltételek dokumentumában leírtak szerint -3. vagy későbbi verzió-, melyet a Szabad Szoftver Alapítvány ad ki."

A licencleírása egy kicsit fura. Ez GPLv3 (és későbbi) akar lenni?

--
trey @ gépház

Igen,

Ez Gpl 3 vagy későbbi.

Ez a GNU hivatalos GPL 2-es magyar fordítása, a gnu.org tartalmazza is erre a fordításra mutató linket, legalábbis a 3-as kiadás előtt erre mutattak.

Most már a fordításokat nem hivatalosnak írják és a 3-as verzióhoz még nincs magyar link, de az angol verzió a 2-es és 3-as rövidített leírás tekintetében megegyezik.

( gabor v | 2007. 07. 08., v – 21:17 )

Szerintem hasznos. Egy megjegyzés: nem akarod library formájában (is?) megcsinálni? Szerintem érdemes az ui-t különvenni magától az analizáló/javító algoritmustól meg a különböző képformátumoktól is. Így pl. be lehetne építeni sok programba. Ha megfelelően el vannak választva ezek a funkciók a kódban akkor nem is tart sokáig megcsinálni. Csak egy ötlet.

Szia,

De természetesen már előkészítettem erre is. Speciel a windows-os Irfanview-nak fejlesztettem plug-inként elsősorban, mert azt hiányoltam/om sok képnézegető programban, hogy nemigazán van 1-klikk-es megoldás a színek automatikus beállítására, vagy éppen csak lineárisan levágják a hisztogram két szélét ezzel kontrasztosabbá téve a képet.

Maga a színkorrekciós rutinom (aaRGB) meghívása nagyon egyszerű: a bemenethez kell a képet RGB tároló tömb kezdete + szélesség és magasság, és csak meg kell hívni. Saját magába visszaírja a korrigált képet.

Az "Eye of Gnome"-nak írtam egy levelet (ha nem is az én megoldásommal), de hogy jó lenne valami kis szinkorrekció a nézegetőbe.

Kölün statikus lib-be azért nem fordítotttam, mert ugye GPL-essé tettem és így letölthető a forrás. Ott meg van egy egyszerű "aargb.h", amit bárhova befordíthatnak. Ez teljesen független más kódtól.

Amúgy köszi a pozitív véleményt.

Üdv.

Igen, értem a különbséget a GNU GPL-hez képest.

Viszont én nagyon hiszek a nyílt forráskódú szférában és nem találom jó ötletnek, ha engedi a licensz a kommercionális, zárt kódú szoftverekbe az implementációt.

Szerintem az egész nyílt forráskódú közösség csak az egymás nyílt kódjából tud építkezni, viszont a zárt kódú fizetős szoftverek nem hoznak pluszt és fejlődést hosszú távon.

Legalábbis szerintem. Éppen azért mert a továbbfejlesztést, illetve a módosítást nem szükségszerű publikálni ezek után.

dehogy erted... ezek szerint.

az LGPL eseten ugyanugy kotelezo kiadni a modositasokat, amit a te kododon vegeznek, csak annyi a kulonbseg a GPL-hez kepest hogy hozza linkelhetik (tudtommal csak dinamikusan, statikusan nem) zart vagy mas licenszelesu programhoz.

btw, az infranview miota GPL ? :)))

btw 2, az xnview-be es az Xee-be is bele kene rakatni akkor mar...

A'rpi

Ja bocsi, az LGPL alatt Lesser GPL-re gondoltam, nem Library GPL-re. Szóval helyes.

Az Xnview-val már beszéltem, csak akkor még előkészületben volt egy alap működő, meg nem GPL és egy zárt kódú lib-et akartam biztosítani számára. Szóval egyetértek, jó lenne ha pl. benne is megjelenne, mert több platformra is megvan.

Az Irfanview meg nem GPL, viszont neki a szerzői jogomnál fogva bocsátom rendelkezésére.

Megnéztem az Xee-t. Jó kis proginak tűnik. Én a letisztult, egyszerű funkciókkal bíró progikat kedvelem (gondolom te is :) )

En elonyben reszesitem a sokat tudo, jol es stabilan mukodo progikat. Ha ezt ugy tudja, hogy letuisztult meg GPL az meg jobb, de nem kovetelmeny. Ja es legyen ingyenes, vagy legyen feltorve :)

Az Xee eddig a legkenyelmesebb kepnezo mac-re amit talaltam, sajnos az xnview mac-en nagyon fapad, mert X11 alatt megy az meg nincs eleg jol integralva meg :( raadasul evek ota nem adtak ki uj verziot az nview-bol se mac-re se linuxra, pedig a wines sokat fejlodott azota.

A'rpi

ps: LGPL = lesser gpl. olyan, hogy library gpl tudtommal nem letezik, csak sokan azt hiszik az lgpl azt roviditi. valoban arra (library-hoz) valo, de nem az a neve.

Szoftverfejlesztokent a kovetkezokeppen jarnek el ha valami funkcionalitasra szuksegem lenne egy gpl-es libbol:
1. Keresnek egy LGPL vagy BSD licensz alatti hasonlo funkcionalitast nyujto libet
2. Ha nem kovethetetlenul bonyolult, visszafejtenem a mukodest es megirnam ujra
3. Hagynam a francba az egeszet inkabb.

Teljesen egyetertek azzal hogy a fejleszto teljes kontrollt gyakoroljon a munkaja felett. Ha kijavitok valamit a munkajaban vagy kibovitem valamivel, jogos hogy visszakapja. (BTW miota biztositja is ezt a GPL? NEKED nem vagyok koteles visszaadni amit csinaltam, csak akinek a binarist odaadom) Viszont en is ragaszkodom hozza hogy teljes kontrollt gyakoroljak a sajat munkam felett, azaz olyan licensz alatt adjam ki amilyen alatt jol esik.

Ilyen megfontolasokbol nem fogok soha KDE vagy QT ala irni semmit (momentan nincs "kedvem" az 1000 euros qt licenszhez hogy ne csak GPL alatt adhassam ki amit csinalnek) es van alternativa: a Gnome/GTK nem koti meg ennyire a kezem.

Felreertes ne essek, szabadnak szant alkalmazasokra tokeletes megoldas a GPL, de libet GPL alatt terjeszteni nem tul jo otlet, mert a lehetseges felhasznalasok bizonyos szazaleka egyszeruen nem fogja hasznalni a licensz megkotesei miatt, ami tulajdonkeppen a fejlesztonek sem jo, mert hamarabb bedoglik a project. Raadasul gondolj bele, egy Nokia mondjuk meg fogja tenni hogy publikalja egy telefonja firmware-enek teljes forraskodjat csak amiatt hogy a libedet hasznalhassa? Raallit 3 embert es 3 honap alatt ujrairjak az egeszet. Na ekkor viszont tenyleg 0 "hasznod" lesz belole hogy megirtak, mert az esetlegesen felfedezett hibak, es a bovitesek soha nem jutnak vissza hozzad.

Érthető az érvelésed és elfogadom. Viszont ha a Nokia így is - úgy is eléri a célját (mint általában a nagy cégek), akkor ettől még nem jön meg a kedvem támogatni őket :)

A GPL azért jó szerintem, mert az OSS szféra felhasználóit és fejlesztőit támogatja, és ez szerintem jó. Még ha hamarabb be is döglik a projekt. A zárt kódba tulajdonképpen amúgy is azt vesznek át, amit akarnak. Kicsit átírhatja bárki, és máris ott az új kód.

A QT-t egyébként én sem értem, hogy miért így van. Ezt én is tudtam és én sem kezdenék el fejleszteni KDE alá. A GNOME-ot amúgy is jobban komázom ;)

Érthető az érvelésed és elfogadom. Viszont ha a Nokia így is - úgy is eléri a célját (mint általában a nagy cégek), akkor ettől még nem jön meg a kedvem támogatni őket :)

Meg fogsz lepodni. A legtobb normalis ceg nem fog licenszet serteni azert hogy neked ne legyen hasznod a bulibol. a peldakent felhozott nokia (de ez lehetne barmelyi embedded cuccot gyarto nagyobb ceg) szivesen visszaadja amit a libedben kijavitott vagy hozzatett, de a hozza linkelt alkalmazas forraskodjanak publikalasarol hallani sem akar. Ugyhogy normalisabb esetben nem fogja hasznalni a libedet ha GPL alatt adod ki csak, kevesbe normalis esetben hasznalni fogja, csak te nem fogsz tudni rola.
Nem a levegobe beszelek, dolgoztam ilyesmi cegnel es sokszor inkabb ujraimplementaltunk valami a licensz miatt.

A GPL azért jó szerintem, mert az OSS szféra felhasználóit és fejlesztőit támogatja, és ez szerintem jó. Még ha hamarabb be is döglik a projekt. A zárt kódba tulajdonképpen amúgy is azt vesznek át, amit akarnak. Kicsit átírhatja bárki, és máris ott az új kód.

Mint fejleszto, teged akkor tamogat, ha terjeszti neked a binarist. A forraskodot ugyanis csak ebben az esetben kell rendelkezesedre bocsajtania. Amugy meg nem fogja "atirni" a kododat, mert ez ingovanyos terulet (szarmaztatott munka) hanem a finkcionalitast fogja teljesen ujra implementalni, ami neked szerintem nagyon nem jo.
Masreszt gondolkozz el a kovetkezon: Valaki irni akar egy alkalmazast (akar megrendelesre is) amiben hasznalna a te libedet. Az alkalmazas funkcionalitasanak tegyuk fel nem tulnyomo resze az, amit a te libed csinal. Termeszetesen ezesetben az illeto inkabb belefeccol meg 15% melot a dologba hogy ujraimplementalja a cuccost mintsem hogy a sajat munkajat (ami tegyuk fel a teljes melo 85%-at teszi ki), csak es kizarolag GPL alatt adhassa ki.
Persze ez a Te szandekodtol fugg. Ha azt szeretned hogy a libed fejlodjon, minel tobben hasznaljak, esetleg bovitsek, akkor inkabb az LGPL-t javasolnam. Ha nem erdekel hogy GPL-es alkalmazasokon kivul a kutya se fogja hasznalni, akkor jo a GPL is. Mondjuk tudtommal ilyen esetben mar egy BSD licenszu cucc sem fordithato ossze vele, bar ebben nem vagyok biztos. Megegyszer hangsulyozom library-rol beszelek, egy alkalmazas eseten mar valoban elonyosebb a tiszta GPL szerintem is.

A QT-t egyébként én sem értem, hogy miért így van. Ezt én is tudtam és én sem kezdenék el fejleszteni KDE alá. A GNOME-ot amúgy is jobban komázom ;)

A dolog amugy nyilvanvalo: a TrollTech-nek nem keves emberevebe kerult a cumo kifejlesztese, es szeretne belole peznt is latni. Meg mindig ez a normalisabb megoldas mint a rolyalty, csak epp van versenytars amire olyan licsnszu progit adsz ki amilyen neked tetszik. Es ha fejlesztokent te sem fogsz emiatt QT ala fejleszteni, akkor miert lenne ezzel maskepp barmelyik fejleszto a te libed eseteben?

Végül is maga az alkalmazás rész a progimban nem más, mind a parancsori paraméterek feldolgozása. Tehát nem ez a lényeg és semmi extra nincsen benne. + használom a GPL-es JasPer library-t.

A színkorrekciós fejlesztésem, az tulajdonképpen egyetlen független kód az aargb.h -ban. Nem hívok meg semmilyen más függvényt ebben.

Ha ezt LGPL-essé tenném, az összefér a GPL-es aaPhoto-mmal szerinted? A külső fejlesztők szempontjából kérdezem.

A színkorrekciós fejlesztésem, az tulajdonképpen egyetlen független kód az aargb.h -ban. Nem hívok meg semmilyen más függvényt ebben.

Ezt nem igazan ertem. Vagy egy template classrol van szo ha a kod maga egy .h file-ban csucsul, vagy a headerbe irtad a kodot. mondd hogy nem az utobbi, leccileccilecci...

Ha ezt LGPL-essé tenném, az összefér a GPL-es aaPhoto-mmal szerinted? A külső fejlesztők szempontjából kérdezem.

Szerintem lgpl es gpl kod linkelheto. Legrosszabb esetben adnod kell az lgpl-es resz forrasat is az alkalmazas melle, de jelen esetben ez nem tunik korlatozo korulmenynek. Igazabol fejlesztoi szempontbol tisztabb lenne ha csinalnal egy valodi libet az aaphoto szinkorrekcios reszebol es az alkalmazasodat linkelned hozza. A "kulso" fejlesztok biztosan orulnenek neki, konnyebb igy hasznalni, es jobban szeparalt.

De, az utóbbi... tudom.. :)

Hat ezek szerint ket olyan object file ami olyan kodbol keszult ami include-olja h file-odat korrekt modon (esetleg sehogy - ezt linkere valogatja) nem linkelheto.

Ha valoban kiadod libkent, ajanlom afigyelmedbe a doxygent doksi gyartasra, csomo melot megsporol neked. Es nem art egy-ket trivialis peldaprogi sem hozza.

Köszi az infót. Sajnos ebben nem vagyok tökéletesen otthon, de át fogom gyúrni, mert nem olyan nagy munka.

És persze példa progira is gondoltam én is.

Először egyébként csak lib-nek kezdtem el gyártani az aaRGB-t és az egész oldal erre is épűlt (letölés doksival) plussz példákat is tettem ki letölthető C fájlokkal.

Úgy néz ki hogy most meg visszacsinálom akkor ezt a részét... :)

"csak annyi a kulonbseg a GPL-hez kepest hogy hozza linkelhetik (tudtommal csak dinamikusan, statikusan nem) zart vagy mas licenszelesu programhoz."

Tudtommal statikusan is, azt kell lehetővé tenned, hogy újralinkelhessék az lgpl lib (API változás nélküli) új verziójával. Ez gyakorlatilag az object fájlok közreadását jelenti.
Ilyet még nem láttam, de elvileg lehet ilyet csinálni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Viszont én nagyon hiszek a nyílt forráskódú szférában és nem találom jó ötletnek, ha engedi a licensz a kommercionális, zárt kódú szoftverekbe az implementációt."

Utólagos (remélem) engedelmeddel felvettem a programodat a GPLv3 licenccel rendelkező programok adatbázisába. Még nincs kinn, de szerintem az ellenőrzés után kiteszik. Lehet, hogy kapsz majd egy levelet róla, amiben jóvá kell hagyni (mármint ha akarod).

--
trey @ gépház

( arpi_esp v | 2007. 07. 08., v – 22:26 )

FYI: siman lefordult mac-en (ppc g5, osx 10.4) is. A libjasper forditasnal kicsit hackelni kellett mert nem akarta megtalalni az /sw/lib/libjpeg-et, de egy CC="gcc -L/sw/lib -I/sw/include" ./configure megoldotta. Ja es a -static opcio nem kell, ugy hianyol a gcc valami crt0.o-t.

Nem nagyon szoktam szeretni az ilyen kepjavito cuccokat, mert altalaban csak szetcseszik a meregdraga geppel keszult fotoimat is, de azert kiprobaltam, nehany kevesbe sikerult kepen, es egesz jo eredmenyt hozott, nem rontotta el oket (jobban), de valamennyit javitott mindegyiken, hol jobban hol kevesbe. Az egyetlen dolog ami az egyik kepnel kijott, hogy - valoszinu a gamma korrekcio okozza - nagyon durvan felerosodott a szinzaj: :(
http://thot.banki.hu/arpi/IMG_9877.JPG
http://thot.banki.hu/arpi/IMG_9877_new.JPG
Esetleg lehetne epiteni valamilyen szinzaj-szuro algoritmust is bele, az olcsobb gepek ugyis szet zajoznak mindent alapbol is :(

Majd meg tesztelgetem, van jopar kepem amire raferne egy kis tuning...

Ja meg 1 negativ eszrevetel: rohadt lassu, kb 15 sec mig egy 8mpixeles kepet feldolgoz, persze minden relativ, ha sokat kell szamolni es nincs Altivec-re optimalizalva akkor mar nem is olyan sok ez az ido...

A'rpi

meg 1 otlet: jo lenne tenni bele camera-raw formatumok tamogatasat, igy az eredeti, modosotitatlan 12 bites rgb adatokbol dolgozhatna.

es meg1, ez fontosabb: jo lenne az EXIF infot megtartani az eredeti kepbol... mivel pl. az elforgatas is abban van tarolva.

A'rpi

Nagyon köszönöm a hasznos információt.

Kérdésem: Nem használhatnám fel az OS X fordításodat publikálásra? Ugyanis még elég problematikus volt eddig megoldanom az OS X platformhoz a fordítást (darwin-nal akartam próbálkozni).

Az automatikus zajcsökkentésen már én is gondolkoztam. Az alapgondolatom, amit végigszeretnék vinni az az, hogy mindenképpen teljesen automatikus maradjon a művelet (a legjobb az ha tényleg nem kell gondolkodni meg ezer paramétert átnézni). Viszont előtérben szeretném tartani azt, hogy ha lehet rosszabb ne legyen a kimenet és nagyon ne legyen mesterségesen megváltoztatva a kép. Ugyanis pl. ha sok vízcsepp van, vagy egy vakolt ház oldala van lefényképezve stb., ahol ami zaj lenne, az maga a részletgazdagság, ott eleve csökkennének a részletek. Legalábbis szerintem, még így előre gondolva is anélkül hogy meglenne a funkció.

Szóval egyenlőre nem látok rá elméleti megoldást annak eldöntésére, hogy mi zaj és mi részlet a képen. De foglalkoztat a dolog.

Szerintem a tökéletes képbeállításhoz az alábbi 4 lépés kellene:
1) Színkorrekció (kontraszt, gamma, színegyensúly és színtelítettség) - ez "remélem" megoldva
2) zajcsökkentés
3) okos, vagy szelektív életlenítés
4) élesség állítás

Tehát ez lenne a távoli tervem.

A RAW formátum és az EXIF ötleted is nagyszerű. Feljegyeztem magamnak. Nagyon köszönöm.

Szóval mégegyszer, ha használhatnám a fordításodat OS X-re, örülnék.
Köszi.

A szinzaj szuresere igen komoly kutatasok es megoldasok vannak, nem egyszeru szakterulet az teny, de a szin/feny/gamma automatikus korrekcioja sem trivilais szal azert mondtam hatha... egyebkent a belinkelt kepemen a sotet kepen vilagos zold es piros pottyok vannak, azert ez nem jellemzo se a vizesesre se a vakolt falra :)
(hacsak nem festettek ilyen 3d-szemuveggel nezheto pottyos kepet egy fekete falra :))

Az OSX-es binarisomat hiaba adom oda (odaadom ha kell), mert mivel nem statikusan van linkelve (ugy nem fordult), nem nagyon mukodne idegen gepen, plane hogy nekem egy rakas devel cucc is fel van rakva /sw stb ala. Majd ha lesz idom, szorakozok meg vele hogy valahogy statikusra forditsam.

Amugymeg siman le tudja minden OSX user forditani maganak, nekem is csak a fenti gondom volt (libjoeg a /sw/lib-be volt installalva), de normal usernel az se jelentkezik valoszinu.

A'rpi

3d :) :)

Bárhogy is, a zajcsökkentés mindenképpen nagyon jó ötleted.

Ha meg sikerülne a statikus OS X fordítást összehozni, akkor én azért örülnék, mert azt felnyomhatnám a weboldalra. A kevesebb tudású felhasználóknak hátha segítség.

FreeBSD fordításnak is örülnék :)

Köszi.

Ja, még a lassúságra annyit, hogy logikai okok miatt igazából kétszer nyálazom végig a kép összes pixeljét.

Magán a kódon viszonlag sokat optimalizáltam a különböző programrészek lecserélésével, viszont szó ami szó, kétszer kell végigmennem a képpontokon, ráadásul vannak lebegőpontos függvények, amik kellenek.

Sajna valószínű sokkal gyorsabbra nem fogom tudni gyúrni.

( kupcsik v | 2007. 07. 08., v – 23:24 )

Egy kis kiegészítés a honlaphoz:
Angolul a "robust" nem ugyanaz mint a magyar robosztus. A magyar szó a méretre vonatkozik, az angol meg inkább olyasmit jelent, hogy erős, egészséges, vagy (szoftvernél) stabil, megbízható. Lásd itt. Szóval az angol verzióban inkább a "bloated" lenne a helyénvaló.

( bounty v | 2007. 07. 08., v – 23:55 )

kipróbáltam néhány régi bescannelt fényképfile-on, sokat javított a minőségükön, grat a programhoz

( hud | 2007. 07. 09., h – 01:01 )

Nem fűztem túl sokat a progihoz, de kellemesen csalódtam. Néhol kicsit változtatott a képen, és nem lett jobb, máshol pedig szinte csodát művelt. Tényleg gratula!

Az észrevételeim, hátha segítenek:

Van pár képem, amik jól sikerültek, de tartalmaznak egy nagy besült érszt. Ilyenkor az algoritmus után szürkévé válik az egész kép.
Ez nyílván máskor segít, és nincs tökéletes automatikus algoritmus. Detektálod külön, hogy besült-e egy pixel? Máshogy kezeled őket?

Szerintem nem olyan nagy baj, hogy előhozza a sötét képeknél a tömörítés/magas iso okozta hibát. Éjszaka félbehagyott sakkot fotóztam, és teljesen jól látható az állás, igaz mákosan, de ez szerintem nem baj. Egy zajszűrő összemos(hat)ná a bábukat a felismerhetetlenségig. Egy sötét képpel nem lehet csodát művelni, így legalább látszik a képen lévő információ.

Köszi a visszajelzést :)

Megkérdezhetném, hogy mit értesz "besült" pixelen? A túlexponált, nagyon világos részre gondolsz? És szürke lett? Nem tudnál esetleg a mintát dobni az eredeti képből? Megköszönném.

Egyébként egyetértek, szerintem sem lehet sok mindent kezdeni a sötét és zajos képekkel. A kép zajos, cak legjeljebb nem látszik annyira a zaj. Ha a középtónusokon világosítasz a gammával a jobb láthatóság érdekében, akkor persze jobban látszik majd a zaj is.

Köszi.

( hrgy84 | 2007. 07. 09., h – 01:38 )

Ha úgy érzed, küldj pü, megoldható lesz esetleg a csomag terjesztés Gentoo alá.

Kellenek majd függőségek, ilyesmik...

Ya, pü-ben vázold nagyjából miért keresel, iszonyú a nick-memóriám... :pirul:

( Nickname | 2007. 07. 09., h – 10:24 )

Tudom, hogy másnak nem kérdés, de nekem kellemes csalódás a gThumb 2.10.5 -ben a Ctrl+Shift+E -hez képest... :D

Leteszteltem a gThumb színállítás funkcióját (Image/Enhance). Véleményem szerint csak kontraszt és színegyensúly kompenzációt csinál és nincs gamma és színtelítettség állítás.

A digiKam színállítását is megnéztem (Fix/Colors/Auto-Correction). Ugyanúgy hiányzik a gamma és színegyensúly állítás.

Általánosságban az én eljárásom ezekhez képest jóval többször produkált jobb kimenetet (persze nem minden esetben). Számomra a cél a minnél több jó kimenet elérése.

Hogy teljessebbé tegyem a dolgot, meg kell hogy említsem az 'Athentech imaging' PERFECTLY CLEAR nevezetű szabadalmaztatott fejlesztését, ami az általam talált eljárások közül a legjobb eredményt produkálja. Valahol olvastam, hogy az Adobe meg is vette a jogot az eljárás implementálásához.

Összességében ezres nagyságrendben mérhető tesztelésen vagyok túl (ami önmagában nem is olyan sok, tudom). Ezekhez viszonyítva a Perfectly Clear több esetben produkál véleményem szerint jobb eredményt, mint az én programom. Viszont voltak a tesztek között "normál" esetek, ahol jobbnak kellett volna lenni a Perfectly Clearnek, viszont többször produkált az én eljárásom jobb kimenetet (a jobb kimeneten azt értem, hogy a fényereje, színtelítettsége, középtónusai stb. jobb volt a végeredménynek).

http://www.athentech.com/set_main.html
Viszont ez nem nyílt forráskódú.

Teljesen jogos a kérdésed szerintem, hogy vajon mi a jó kimenet? És ez mennyire szubjektív?

Ha például egy art fotós korrigálja a progimmal a direkt naplementekor készített fényképét, akkor nagyon nem fog tetszeni neki, mert a gamma korrekció miatt a sötét részek is felvilágosításra kerülnek.

Az én alapcélom arra írányúlt, hogy egy egyszerű megoldás legyen az otthon, amatőr módon és amatőr kamerákkal készűlt családi fényképek gyors színkorrekciójához. Másképpen szólva, hogy az anyukák és apukák egyszerűen tudják feljavítani azokat a képeiket, amelyek túl sötétek stb. lettek.

Vagyis az én szempontomból a jó kimenet részben a hisztogramm valamely matematikai meghatározásokkal való helyes beállítását jelenti, másrészről pedig az alábbit:

- a fekete pont jól van beállítva, vagyis a képen található legsötétebb részt tökéletes feketére húzzuk (persze ha eleve amúgy is feketének kellene lennie annak a résznek) és ugyanez a fehér pont esetében
Ez nem szubjektív, mert ha nem ér teljesen szét a görbe a hisztogrammon, akkor széthúzásra kerül

- a gammával addig világosítjuk a képet, amíg az legalább világosabb nem lesz egy előre meghatározott értéknél (ez itt szubjektív, hosszabb kísérletezéssel állítottam be egy konstansot az algoritmushoz)

- a színegyensúly beállításánál pedig figyelembe veszem, hogy az összegzett fekete pont színe (a legsötétebb részt értem ez alatt) milyen szín irányába van eltolódva a tökéletes feketéhez képest. Ugyanez milyen írányba megy a fehérnél. Ha az irányuk megegyezik, akkor valószínű a digitális gép okozta a színegyensúly eltolódását, mert ugye a rosszabb minőségű digi gépeknél az egész fotón található színek olyan szín irányába tolódnak el, amelyik szín a legtöbb illetve legjellemzőbb a képen. Egyszerűen fogalmazva egy focipályán lefotózott játékos sokkal zöldebb lesz, mint a valóságban a sok zöld fű miatt. Ezért a zöldből vissza kell húzni. Hogy mennyire, azt a két színirány szögének különbsége adja.

Stb. Itt szeretném megjegyezni (ami a weboldalam súgó részében is megtalálható http://log69.com/help.html), hogy a korrigálandó képnek alapjában olyannak kellene lennie, hogy tartalmaz sötét részt a fekete pont beállításához, és világos részt a fehér pont beállításához.

Egyszóval inkább "családi" képekre jó. Ha valakinek több és mélyenn funkció kell és manuálisan szeretné tuningolni a képet, erre nagyon sok professzionális program van már (GIMP a kedvencem :) )

Viszont én grafikus vagyok és nagyon sokat kell naponta színkorrigálnom képeket kiadványokhoz, és elmondhatom hogy az Adobe Photoshop eggyel régebbiről visszamenő verziói siralmas színkorrekciót csináltak. Ugyanígy a Corel PhotoPAINT esetében is elmondható, hogy nagyon használhatatlan a színkorrekciója, még a legújabb X3-as verziónak is. Maga a GIMP sokkal profibb képkorrekciókat tartalmaz (GIMP/Layer/Colors/Auto/...Equalize - White Balance - Color Balance - Normalize - Stretch Contrast - Stretch HSV)

Szóval szubjektív is meg nem is :)))

Ejszaka raengedtem tobb ezer kepre, es egy gyors atporgetes alatt talaltam nehany esetet ahol "tevedett" a programod. Vegulis az egyetlen dolog, amit zavaroan elrontott, az a narancssarga szin. Ha a kepen voltak narancssarga dolgok (pl. ilyen szinu polot viselo ember, vagy egy ilyen szinu kocsi) akkor az borzasztoan rikito szinu lett, mintha kukas-mellenyt viselne vagy foszforeszkalna.
Erdekes, hogy csak a narancs szinnel volt ilyen problema, mas szineknel nem (vagy legalabbis nem volt zavaro).
Kuldjek kepeket?

A'rpi

Megnézegettem közben a képeket.

Az az igazság, hogy a 4 dolog közül (kontraszt, gamma, színegyensúly, színtelítettség) a színtelítettségen dolgoztam legutoljára és még ez az egy nem teljesen kiforrott. És a képeid nagyon segítenek, azt hiszem tudom mi lesz a hiba és hamarosan meg is oldom.

A lényeg hogy kicsit túlhúzom a színtelítettséget. Lineárisan húzom felfelé. De ez azt is jelenti, hogy a sötétebb színek kevésbé, az élénk színek pedig nagyobb mértékben fognak erősődni. De majdnem biztos vagyok benne, hogy ezt az egyet kell kicsit átgyúrnom.

Asszem ráállok a dologra. Örülök hogy azért kibukott (meg nem is örülök, munka, sok tesztelés.. :) )
Köszi.

( asm v | 2007. 07. 09., h – 10:29 )

Nezted mar a digikam hasonlo feature-et? Ez nyujthat jobb eredmenyt?

Egyebkent en sose szoktam utolagosan modositgatni a kepeket. Hiszen a modern gepek mar fenykepezeskor korrigaljak a hibat.
Csak a sotet kepekkel vannak gondok, de arra ez sem nyujt megoldast...

Hát, hogy a modern gépek korrigálják a hibát, abba ne legyél biztos. Én a képek színkorrekciójához, meg a lencsék okozta hordó- és párnatorzítások kiküszöböléséhez, meg a vignettálás és a cromatikus abberáció megszüntetéséhez Bibble Pro-t használok elsősorban. A program (elsősorban a már fentebb emlegetett perfectly clear és a noise ninja eljárásnak köszönhetően) 10-15 másodpercet molyol egy képen AMD 3500+-as processzoron. Na most, a 350D-ből nem lóg ki egy hűtőborda, és másodpercenként képes ellőni 3-5 képet, és ebbe még a hátfal kiolvasása és jpeg-be konvertálása is belefér. Nem tudom elképzelni, hogy az implementált algoritmusok ne butított, gyors verziók legyenek, és a tapasztalat is azt mutatja, hogy a fényképezőgépbe implementált algoritmusok a PC-s szoftverekhez képest roppant gyengék. A legjobb, ha raw-ban fotózól, és a mindenfajta feldolgozás nélkül viszed át a cuccot PC-re, ahol megejted az utófeldolgozást.

( GegSite | 2007. 07. 09., h – 11:39 )

Szuper a progi nagyon hasznosnak találom, csak így tovább!

( nyasi | 2007. 07. 09., h – 16:08 )

Én abszolót nem értek a fényképezéshez csak nyomogatom az exponáló gombot a digiféyképezőgépemen.
Lehet ezzel vörösszem hibákat is javítani ? Ha nem akkor tud valaki erre egy hasonlóan egyszerű eszözt ?

Sajnos nem lehet a progimmal vörös szemet javítani. És hasonlóan egyszerűt sem tudok.

Én speciel a GIMP-et ajánlanám erre a célra. Ha még soha nem használtál hasonló grafikai programot, akkor lehet hogy kicsit körülményesebb elkezdeni, de ha már belejöttél, akkor gyorsan és profin lehet dolgozni vele.

Ha létezik másik, egyszerűbb módszer erre, akkor én is szívesen venném az ötletet.

http://www.gimp.org/tutorials/Red_Eye_Removal/

A vörös szem korrigálásra a leggyorsabb megoldást a Paint Shop Pro néven futott programmal találtam meg annó. Ebben úgy működött, hogy egy emberi szemet lehetet rárakni a vörös szemre. Állítani lehetett a színt, a pupillát, a fényt stb., de ha csak egyszerűen a szembogarat választottad, írisz nélkül, úgy volt a legegyszerűbb.

Ha valaki tud hasonló módszert Linux alatt, azt én is szívesen kipróbálnám.

( nigra | 2007. 07. 09., h – 20:14 )

Én mint egyszerű (de lelkes :-)) amatőrfotós igen hasznosnak találtam. Ráküldtem vagy 50 válogatás nélküli digitális fotómra és vagy 10 érezhetően szebb lett. Ezt én nagyszerű eredménynek tartom egy egyszerűen használható automatikus programtól.

Köszönet a fejlesztésért és további jó munkát kívánok!

( skynetpro | 2007. 07. 10., k – 10:35 )

kipróbáltam és érdekes eredményt produkált.
az olympus mittoménmilyen alsókategóriás géppel képszült képek minegyike sokkal jobb lett.
az én fuji s7000-es gépemmel készültek pedig rosszabbak. egyértelműen.
töltök fel majd, ide írom a linkjét
----------------------------------------------------------
Aki nem tud úszni, ne másszon fára, mert elüti a villamos!

( log69 | 2008. 01. 17., cs – 19:45 )

Frissítés:

Megvan az újabb verzióm v0.28 :) Javítottam a visszajelzett hibákat (végre):
- a kontrasztnál fellépő túlexponálás problémája javítva
- a színtelítettség állításnál túlságosan kiélénkülő színek problémája javítva
Több infó itt

A kontrasztnál végre megoldottam, hogy a fekete és fehér pontot nem a tökéletes fehérbe és feketébe húzom, hanem az azoknak megfelelő olyan legvilágosabb (és legsötétebb) színbe, amelyeknél az adott fényerőnél maximális a színtelítettség -figyelembe véve a szükséges színegyensúly kiegyenlítést.

Ezzel azt a logikai problémát oldottam meg, hogy ha a képen nem volt olyan sötét és világos terület, amelyeknek tökéletes feketének és fehérnek kellett volna lenniük (ehhez viszonyított volna az algoritmusom), akkor rossz kontraszt és színegyensúly állítás keletkezett. Most viszont az azoknak megfelelő legvilágosabb részbe húzza (nem pedig fehérbe).

Meg volt olyan probléma több képen is, hogy a narancs és piros színek kiélénkűltek. Ez is javítva (remélhetőleg).

Köszi a tesztelést és a képeket Árpi, Sánta Attila, Giczi Levente. Hasznosak voltak, főleg a kontraszt túlhúzás kijavításához.

( kupcsik v | 2008. 01. 16., sze – 20:21 )

Hali! Nagyon jó kis progi, sokat használom, és ahol tudom, terjesztem. Egy kérdés: Árpi már felvetette feljebb, hogy az EXIF infót békén lehetne hagyni (illetve átmásolni az új képre). Ez irányban van tervben valami változás? Elforgatás és dátum miatt lenne nekem fontos.

Köszi a visszajelzést. Képzeld, pont most készültem el vele. Úgyhogy kb. 2 héten belül (amint lesz időm kiadom) meglesz az újabb verzió.

Az EXIF dolgot már régóta ki akartam javítani, csak rossz irányba indúltam el. A 'libexif' modult akartam arra használni hogy leolvassam, meg visszategyem a meta adatokat. Közben meg kiderült hogy nagyon egyszerű a Jpeg formátumon belül. Úgyhogy már majdnem meg is van.

Amiatt csúszik még, mert több javítás is van. De kb 2 hét- :)

Meg az 'aaRGB' motorját is külön választom és fent lesz az oldalon külön libként.

Szia,

Megvan az újabb verzió: aaPhoto v0.29. :)

Változások:
- Mostantól szürke képek is használhatóak bemenetként
- változás: fájl név puffer megnövelve (mappa megadásához)
- Exif meta informáicó mostantól elmentésre és visszaállításra kerül JPEG képek esetében

Bővebb infó: http://log69.com

Remélem komoly hiba nem csúszott bele. Teszteltem, de ha bármilyen nemű hiba van, szívesen veszem a visszajelzést.

Egy ismert gondról tudok win32 környezetben, amikor is ha nem rendszergazda jogosúltsága van a felhasználónak, akkor nem működik jól a jpeg kitömörítés, vagyis nem tudja beolvasni a fájlt.
Azt már tudom hogy nem a progimban van a hiba, mert leteszteltem. BMP-vel ilyen feltételekkel is megy (ez saját rutin). A JasPer forsítási beállításainal lesz valahol a gond. Megpróbálom a következő verzióhoz kijavítani.

Üdv-

Ui.: UHU linux csomag is lesz Páder Rezsőnek köszönhetően, a debian csomagot meg megpróbálom én összedobni.