Mint mondtam ez eléggé bonyolult dolog és az ismereteimet én is azért szeretném szakirodalmakkal bővíteni, hogy még többet megtudhassak ebben a témában, elsősorban ezért írtam ebbe a topikba és nem azért, hogy magáról a kódról beszéljek, de ha már kérdezted nem titok, válaszolok:
A raw fájlok visszafejtéséért felelős algoritmusokat nem kell licencelni, ugyanis nincs rájuk szükség, ezeket az algoritmusokat (helyesebben metódusokat) már megírták mások helyettem, a kód pedig elérhető, szabadon felhasználható. Nem tudom, hogy több ilyen is van-e az interneten, én a legkézenfekvőbb megoldásnak erre a feladatra Dave Coffin dcraw szabadon felhasználható programját találtam (további infók).
Ha esetleg érdekel, hogy ő hogyan is volt képes megoldani a raw fájlok visszafejtését, elmondhatom, hogy nem egy ördögtől való dolog, de az valóban igaz, hogy mivel minden gyártó saját megoldást használ és ráadásul nem az összes készülékében ugyanazt, tehát készülékenként is lehetnek különböző eljárások ezen a téren, egyáltalán nem egyszerű a dolog.
Kezdetnek azért elég ismerni a RAW fájlok felépítését: többek között van benne egy header rész, ami alapból tartalmazza a bájtsorrendet, egy fájl azonosítót és még a fő adatrész kezdetét is. Itt már alapból be lehet azonosítani azt, hogy big vagy little endient használtak a tárolásra.
Átugorva az alacsony szintű architektúrális sajátosságokat ezek után már mondhatjuk azt, hogy "trükk" az, hogy a számításait egy merész feltételezésre alapozza (ami a legtöbb esetre igaz) és Bayer szűrő esetén ismert Bayer mintákat, CYGM szűrő esetén CYGM mintákat illeszt a képre, ezzel meghatározhatja a szűrő pontos felépítését és ez után alacsony szinten feldolgozza a fájlban tárolt információkat majd megjelenítésre alkalmas formában továbbítja a felhasználó fel azaz számodra a monitorra. Ez így nagyon pontatlan megfogalmazás, de dióhéjban ennyi.
Konklúzió: A RAW fájlok önmagukban nem kicsit bonyolultak, maga az egész téma nem egyszerű és ahogy ti is észrevettétek, igen mély ismeretek kellenek a megértésükhöz ha jelszinten akarunk róluk beszélni. Ezek után a kameragyártóknak szerintem nem céljuk további titkosítási eljárást alkalmazniuk a saját fájljaikra, miért is tennék? Ezzel csak tovább bonyolítanák a képek rögzítését-feldolgozását, ami még egyszer hangsúlyozom: így sem egyszerű. Magának a kamerának is komoly erőforrásokra van szüksége pláne ha belevesszük a kép készítésén kívüli egyéb funkciókat és a versenytársak megoldásait is plusz további titkosítással a költségek is igencsak megnőnének, mint a szoftverfejlesztés, mind a kamerában lévő hardver esetén is.
Úgy is mondhatnám, hogy eddig én még nem találtam (de annyira nem is kerestem) olyan raw formátumot amiben külön titkosítási eljárást használtak volna olyan célból, hogy elfedjék a tartalmát. Az olyan adat ami nincs titkosítva pedig a kellő ismeretek birtokában "könnyedén" feldolgozható. (pl itt egy szösszenet a canon .cr2 tartalmáról) Titkosítás helyett inkább különböző leképzési módszereket használnak, legalább is én így látom.
Ezzel nem azt állítom, hogy nincsenek olyan kamerák, formátumok, melyek nem használnak titkosítási eljárást a feldolgozás korlátozására, de a legtöbb ma használatos akár profi akár félprofi vagy amatőr gép tudtommal nem használ és az esetek 99%-ban most ezekről beszélünk.
Ez így nagyon pontatlan és pongyola megfogalmazás, de remélem félig-meddig választ adtam a kérdésedre.
Szerk: jah és még annyit hozzátennék, hogy én nem Amerikát akarom újra felfedezni, hanem inkább a webes azaz online feldolgozásba szeretnék kicsit belemenni. A fenti C programot könnyen át lehet ültetni javascriptbe, illetve nem olyan könnyen mert most épp ezzel szenvedek. Egyébként hasonló megoldás is van már (pics.io, de ők egy WebGL-t használnak), de az én elképzelésem kicsit másabb lenne bizonyos szempontokból.
[ Szerkesztve ]
- Szakmai kérdésekre privátban nem válaszolok, mivel másoknak is hasznos lehet. Erre való a szakmai fórum! -- YT: youtube.com/dyingsoulgaming -- FB: facebook.com/DyingsoulGaming/ Stream: http://twitch.tv/dyingsoul