15/16bit RGB-> 24bit RGB muunnos

Kirjoittaja Viesti   JPQ Lauantaina, 3. heinäkuuta, 2004 - klo 21.51:    eli jos kuvatiedosto kuten vaikkapa TARGA kuva sisältää 15/16bit RGB tietoa. Niin mikähän olisi nopein tapa muuntaa se 24bittiseksi ? käyttäen C kieltä.(en vielä ole valmis C++ koodailuun) ehkä bittejä pyörittäen bitit jotka halutaan mihinkin kohde 8bit arvoon mutta millä leikkaan "ne ylimääräiset" pois ? ja huolehdin siitä että vaikka punaisen tasosta 31 (5bit asteikolla) tulee 255 (8bit asteikolla) eikä 248 (8bit asteikolla) kuten eräällä tavalla uskoisin pääsisi käymään. Tosin en tiedä miten tärkeää mutta minulle tärkeää mahdollisimman laajaformaatti tuki ideassani eli siksi myös 16bit TARGA niiden listalla jota haluaisin tukea. PS. tämä ei ole kylläkään MorphOS spefinen juttu mutta koska sillä alustalla nyt koodailen tätä tämä on tällä "puolella". PPS. toki jätkän asian selvitystä myös itse.   Tukkijätkä Lauantaina, 3. heinäkuuta, 2004 - klo 22.29:    Jätkä on ihan rauhassa vaan.   itix Lauantaina, 3. heinäkuuta, 2004 - klo 22.32:    Ei se ole niin vaikeata... AND-operaattorilla voit nollata tarpeettomat bitit. Homma vaatii myös hiukan bittien pyörittelyä. Kannattanee hahmotella RGB16 ja RGB24 pikselien esitysmuoto paperille ja lähteä siitä... Helpoin vaihtoehto voisi olla tehdä kuvadatasta bitmap ja käyttää ReadPixelArray() -funktiota (CGX).   allu Lauantaina, 3. heinäkuuta, 2004 - klo 22.59:    JPQ: Ei kannata skaalata sitä 5-bittistä arvoa siten että saadaan arvot 0-255, koska siinä ei kuitenkaan ole sen enempää dynamiikkaa(arvelenpa jopa kuvan laadun kärsivän). Kertolasku ja shiftaus plus muut asiaan kuuluvat maskaukset joka pikselille => pirun hidasta. Pelkkä shiftaus ja maskaus riittää. Nopein vois olla 32768/65536 alkion long taulukko.   JPQ Lauantaina, 3. heinäkuuta, 2004 - klo 23.05:    itix: AND operaattorilla miten sillä saan 8bit luvusta vaikkapa kolme ylintä bittiä varmasti nollaksi ? kun andinhan totuus taulu lienee A B X ------------- 0 0 1 0 1 0 1 0 0 1 1 1 vai muistanko ihan metsään ? ja tuo sun bittimappi ideasi voisi olla tutkimisen arvoinen. allu: jaa ei edes kuvankäsittely softassa just joo eli tästä lienemme täysin eri mieltä... kumpaa mieltä muut on ? nopeus ei minusta ole tärkeintä vaan laatu. Ja onko tuo muka hidasta vielä pegasoksellakin ? (tosin oma koneeni on G3/600mhz mutta siltikin) ja ymmärtääkseni oikea kirkkain 5bit punainen on sama kuin kirkkain 8bit rgb punainen. kaikki: kumpaa mieltä muut on siihen saa vastata ne ihmiset jotka käsittelee kuvia tai tekee niitä ?   allu Lauantaina, 3. heinäkuuta, 2004 - klo 23.10:    JPQ: jos sulla on 5-bittiä tavaraa, niin sä et siihen saa lisää informaatiota vaikka kertoisit sen miljoonalla. piste.   JPQ Lauantaina, 3. heinäkuuta, 2004 - klo 23.30:    allu: mutta en jaksa kirjoittaa ja veisi tilaakin kamalasti jokaiselle värimäärälle erikseen kuvankäsittely efektejä ja toiseksi on kiva kuitenkin käsitellä kuvaa 8bit per kanava bufferissa ja heittää halutulla syyvyydellä takaisin talteen. eli jos sulla vaikkapa 16bit TARGANA omenan kuva jonka blurraat ja haluat talettaa sen jälkeen JPEGginä niin saat kaikki syntyneet värit talteen (huomioiden tietysti JPEG pakkauksen vaikutuksen...) . ISO PISTE. PS. tiedän etten saa uutta tietoa luotoa harvinaisen hyvin. Enkä tarkoita että pitäisit tyhmänä mutta en tosiaankaan ole tyhmä (vaikka kirjoitus virheitä esimerkiksi tulee joskus?). TOINEN ISO PISTE. PPS. ja käsitteletkö itse kuvia tai teetkö niitä jos et niin mielipteesi ei ole niin tärkeä kuin niiden jotka niitä tekee...(vain ohjelmien mahdollisella käyttäjä ryhmällä on väliä).   allu Lauantaina, 3. heinäkuuta, 2004 - klo 23.49:    JPQ: "eli jos sulla vaikkapa 16bit TARGANA omenan kuva jonka blurraat ja haluat talettaa sen jälkeen JPEGginä niin saat kaikki syntyneet värit talteen (huomioiden tietysti JPEG pakkauksen vaikutuksen...) . ISO PISTE. " Tottakai ohjelma voi sisäisesti käyttää yhtä ja samaa formaattia, kuten 24-bittistä. Iso ja hyvä piste. Mutta en siitä mitään sanonutkaan vaan skaalauksesta. "Enkä tarkoita että pitäisit tyhmänä mutta en tosiaankaan ole tyhmä (vaikka kirjoitus virheitä esimerkiksi tulee joskus?). " En yleensä pidä ihmisiä oletuksena tyhminä. Enkä ole ikinä kirjoitusvirheisiisi puuttunut. Jokainen taaplaa tavallaan. "PPS. ja käsitteletkö itse kuvia tai teetkö niitä jos et niin mielipteesi ei ole niin tärkeä kuin niiden jotka niitä tekee..." En. En varsinaisesti "käsittele kuvia", mutta uskallan väittää tietäväni jotain tietokonegrafiikasta ja ohjelmoinnista. Usko mua kun sanon että kuvanlaatu huononee.   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 0.19:    allu: on se jännä juttu mutta minusta minun muunnos tyyppinen on yleisempi siinä mielessä pätenee paremmin että 248 ja 255 arvojen välillä melkoinen ero kun 5bit käyttää kokoalueensa minusta siitä tehdyn 8bit muunnoksenkin on syytä kattaa. Odotetaan mitä muut sanoo. Voisihan tuosta tehdö option mutta mitkä optioiden nimiksi ?....   itix Sunnuntaina, 4. heinäkuuta, 2004 - klo 4.27:    Ei se haittaa jos värikomponentin arvoksi tuleekin 248 eikä 255. Ota huomioon että RGB15-formaatissa on jo menetetty osa tarkkuudesta koska 8bit -> 5bit muunnos tuhosi 3 alinta bittiä. Käytännössä ero on merkityksetön.   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 5.13:    itix: jaa a nyt menee kohta siihen että teen option mutta optioiden nimeäminen on paha. PS. Otan huomioon...   Joanna Sunnuntaina, 4. heinäkuuta, 2004 - klo 10.28:    itix: kyllä tuo ero vaikuttaa esim kun kuvaa tulostetaan... Jos valkoinen ei ole valkoinen, niin se näkyy. Itse tekisin 5->8 bit muunnosen seuraavanlaisesti.. Esitys yksinkertaistettu, vain yksi värikomponentti nnäkyvillä. ABCDE -> ABCDEABC Eli täyttäisin alimmat 3 bittiä ylimmilla kolmella.. Samaten jos on 6->8 (16-bit modessa vihreätä on 6) ABCDEF -> ABCDEFAB Suurin ongelma näissä muutoksissa on se ettei niitä ole helppo esittää tehokkaasti C:llä vaan siinä joutuu nakertelemaan kohtuulisen sekavia shiftauksia ja And/Or maskauksia että saa koko 16->24 muunnoksen tehtyä. Logiikalla tuon tekemisessä ei paljon tuhraannu aikaa eikä piitä. Asiaan liittyen... Koska tämä on Genesi(=MorphOS) alue niin esitänkin kysymyksen.. Miten hyvin PPC:n assembleri soveltuu tuollaiseen bittimaskaukseen? Ymmärtääkseni AltiVec ei ehkä kykenisi tuollaiseen???   antime Sunnuntaina, 4. heinäkuuta, 2004 - klo 13.59:    vupkhpx/vupklpx-käskyillä voidaan kerralla purkaa neljän 15bpp-pikselin komponentit 8-bittisiksi ja vslb-käskyllä voi vektorin jokaista tavua shiftata vasemmalle. 16bpp vaatinee manuaalisen purun.   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 14.29:    Joanna: hienoa että vihdoin joku ymmärtää että asia on vakavampi kuin voisi luulla. Tosin pääätynen optioon jolla tuon voi valita (nähtävästi tulee jopa kolme eri tapaa....) ja aika usein näkee että alimmat bitit täytetään käytettävien bittien alimmalla bitillä.(Tuo malli minusta yleisin jollen sekoile) Voin yrittää jos koodistani tulee jotain laittaa valinnan millä metodilla homma tehdään. Tosin täytyy ensiksi tuo 24bit TARGA loaderi/saveri saada kuntoon.   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 14.30:    antime: harmi kun just noin päin kun 15bit kuva formaatteja vähän varsinkin siinä listassa joiden tukea olettavasti yritän...   Joanna Sunnuntaina, 4. heinäkuuta, 2004 - klo 15.40:    antime: Kiitos, tarkistin mitä nuo teke Applen webbidokumenteista ja näyttää mukavan tehokkaalta tuohon tarkoitukseen... http://developer.apple.com/hardware/ve/index.html jpq: yleensä kuvien purkaminen nykykoneilla ei ole ongelma jos vaan kone on muuten kunnossa. Että jos sieltä ei erillistä käskyä löydy niin on se silti riittävän nopeaa..   antime Sunnuntaina, 4. heinäkuuta, 2004 - klo 15.42:    Nuissa 16bpp-formaateissa on se ongelma että pitäisi tehdä kolme variaatiota riippuen siitä mikä komponentti vie kuusi bittiä. Kyllä sen voi silti tehdä maskaamalla kukin komponentti erikseen ja purkamalla kokonaislukuina (vupkhsh/vupklsh). Hieman enemmän työtä muttei mitenkään mahdotonta.   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 20.47:    Joanna: varsinkin kun erikois kuva muotoja kuten oliko 16bit vai onko se sittenkin 15bit Targoja harvoin kävelee vastaan. Kaikki: Katsonkin miten photogenics5.0 lataa TVPaint targan joka on 15/16bit siis miten menee värit. antime: ei tarvitse tehdä kun se on aina näissä tuntemissani vihreä. PS. Noissa muissa kuvaformaateissa onkin isompi työ. PPS. Miksikö Targa tuki ensiksikin siihen on parhaat dokumentit minulle pahimmat dokut menee ylikaalin ja se on selkein formaatti jotenkin ja toiseksi TVPaint,ja ilmeisesti myös Photogenics jota käyttelen jatkona osaa ladata/tallentaa niitä. ja jos eräs kirja osoittautuu hyväksi niin XBM,BMP,PNG,JPEG,GIF tuki ainakin tulee lisäksi ehkä 256 värinen PCX ja IFF myös toki myös BMP,TIFF. PPPS. ja jo targa loaderin ja saverin kanssa ihmiset voivat "algorytmejäni" testata. siksi sitaatit kun eräät voi olla poimittu eräästä teoksesta jonka koodia saa lainata vapaasti kait tosin vielä tarkistan. Sen siitä kirjasta. ja mitä esimerkiksi hetki sitten silmiin osunut filsa tekee kuvalle. PPPPS: täytyy tutkia libpngeen mos porttia jos ymmärtäisin sen jotenkin miten sillä saan kuvan auki. PPPPPS. pitänee pummia aminetista esimerkiksi IFF loaderia Planar->Chunky muunnin jonka jälkeen data pitäisi vielä prosessoida 24bittiseksi truecoloriksi. Tuo planar->chunky muunnos lienee tosi hikinen ja tuo aminetin C koodi on kuulemma hidaskin.   antime Sunnuntaina, 4. heinäkuuta, 2004 - klo 21.24:    Olet kyllä oikeassa siinä että vihreä on se kuusibittinen komponentti, mutta niiden järjestys saattaa vaihdella (RGB/GBR).   Joanna Sunnuntaina, 4. heinäkuuta, 2004 - klo 21.39:    JPQ: Itse en vaivaisi päätäni millään erisoisemmilla kuvaformaateilla kuten Targalla vaan ennemmin keskittyisin ohjelmaan itseensä. Siis jos kuva on jotain harvemmin tarvittua vanhaa formaattia niin kannatta katsoa esim PBM:ää jos se osaisi tehdä muutokset helpolla scriptillä johonkin parempaan formaattiin. http://netpbm.sourceforge.net/ Tuosta pitäisi kai olla Amigaporttauskin.. En tiedä PPC natiivista/MorphOS versiosta, tosin ei sen nopeuden pitäisi olla ongelma kun on JIT.   Tapani Sunnuntaina, 4. heinäkuuta, 2004 - klo 21.43:    JPQ: PPPPPPPPP. Mitä ihmettä. Pitäisikö tuosta vielä selvääkin saada? Moderaattorit hohoi?   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 21.51:    Tarkoitatko P rivejä no PS on jälkikirjoitus noi on jälkikirjoituksen jälkikirjoituksia. Jos tekstissä muuta sekavaa ilmoita jos saisin sen sanottua selkeämmin. Joanna: jaa tuollainen hidastaa ja inhoan softia jotka vaatii sen ja sen lisäpalan. Tosin NetPBM:ää vilkaisen. Jos se on opensource kääntöäkin mosille voisin kokeilla. PS. mahd. laaja ja laadukas tuki on minusta tärkeää.   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 21.55:    Joanna: ikävän monet muut kuvaformaatit on konstikkaita ladata. ja olikos täytyy tutkia tuo NETPBM sellainen vaikkapa muuntaa JPEGin -> PBM kuvaksi ? jos niin täytyy PBM:än dokuja tutkia löytyynee www.wotsit.orgista...   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 22.43:    Joanna: kiitos vinkistä (tähän asti tuntuu hyvältä) jos vielä joku neuvoo miten tuosta sen luomasta fileestä noi asciina ilmoitetut kokotiedot saan ihan kahdeksi vaikka long? (se 16bit/32 C muuttuja tyyppi) tyypin muuttujaksi niin pääsen piankin hommiin. Tosin mietin sitä myös itse. ja löysin myös kivan PNGWriter softan jota tutkin myös. Joskus riittää kuvien kirjoituskin näet. Kaikki: haittaako jos ohjelma käyttää aluksi vaikkapa multiview tai tms. softaa kuvien näyttöön käsittelyn yhteydessä kun siinä omat syynsä miksi tekisin sen niin ja voisin tehdä niin että ihmiset voi asettaa itse vieverin kunhan se on sellainen että kuvan nimi riittää sen käyttöön. Pitäisi tosin kuvat muuttaa tuohon hommaan aina tilapäisesti vaikkapa IFF24 muotoon tosin pähkään tapaan jolla tuokin voitasiin välttää ainoa vaan sillä tavalla paha näyttää vaikkapa 2048x1536 pikselin kuvia siis tuolla minun tavallani. (Siis sillä joka ei käytä vaikka multiviewiä) Nythän ei onneksi periaateessa tarvi tukea 8bit/HAM/EHB Tiloja siis näytön suhteen...   JPQ Sunnuntaina, 4. heinäkuuta, 2004 - klo 23.46:    Löysin nähtävästi valmiin funktion tarpeeseeni mutta toisin päin en vielä mutta saattaa olla jo idea jolla saisin tehtyä homman toisin päin eli mulla vaikkapa luku 0-65535 luku välillä jonka haluan kirjoittaa asciina tiedostoon. Kyllähän printf:älläkin se sujunee mutta lienee hieman sekavaa??? tosin toisen ideani toimivuutta en tiedä laittanen pegan taasen piuhoihin kohta kiinni ja kokeilen voisihan sitä muuten classic amigallakin mutta koodissa olisi siirtäminen...   Marq Maanantaina, 5. heinäkuuta, 2004 - klo 20.03:    fprintf() ja fscanf() on tarkoitettu tiedostoihin ASCII-muodossa kirjoittamiseen sekä lukuun. C-kielen perusteita.