Hva er denne måten å representere farge i dette ukjente bildeformatet

patr0805

2014-03-30 17:00:12 UTC

view on stackexchange narkive permalink

Greit, jeg har et PS3-bilde komprimert med en variant av LZ-algoritmen (magiske byte 43 5A 32 00 ) (jeg har dekomprimert den med hell) og det jeg får fra dekomprimert skjemaet er et sett med ARGB-farger / piksler (Antall byte i den komprimerte filen er 4 * bredde * høyde , så jeg vet at den dekomprimerte filen sannsynligvis bare inneholder de rå ARGB-dataene).

Her er et bilde som illustrerer resultatet av å gjengi ARGB-dataene (gjennomsiktighet utelatt for å gjøre ting lettere å lage).

Dekomprimert bilde: enter image description here

Skjermbilde av PS3-utgave:

enter image description here

Skjermbilde av PSP-utgave:

enter image description here

Det jeg vil vite er om noen av dere vet hva slags logikk denne fargestrukturen bruker? For meg ser det ut som den ser på den siste fargen når det gjelder y-aksen. Der nullverdien bare får verdien av den siste fargen på y-aksen. Det ser ut som om jeg må dif / summe farger sammen.

Jeg har prøvd varierer metoder. For eksempel, her prøver jeg å lagre en fargesammensetning med null farge og for hver linje, summere den usignerte heltallrepresentasjonen av ARGB av x-posisjonen i matrisen med den nye fargen usignert heltall -> A + B = C kode>.

enter image description here

AB = C, gir bare rosa giberish ..

Her er noen eksempler på ARGB-verdier som jeg bruker for å prøve å finn en løsning:

  x: 0, y: 24-27R G B137 195 255240 254 000014 000 255001001 001

Dette skal gi en blåaktig farge (sammenligner med skjermbilde) som: 145, 184, 219 .

* Vær oppmerksom på at bildet mitt til sammenligning ikke er eksakt. Det vil si at jeg fikk det fra det samme spillet på en annen plattform der et annet format brukes. Siden bildestørrelsen er forskjellig. Jeg kan si at fargene ikke er 100% de samme som den nye.

  x: 4, y: 22-28R G B137 195 255118 168 201255 204 161

Også dette skal gi en mørk blå farge som: 020, 068, 096 .

* Vær oppmerksom på at den sammenlignede fargen i spillet ikke er nøyaktig, bildet har gjennomsiktighet, så spillet har sannsynligvis rotet seg med skjermbildets fargeverdier.

Så hvis noen har opplevd ting som dette før og kunne gi meg et tips av noe slag ville jeg være veldig glad. :)

Har du prøvd å redigere byteverdiene systemisk? Gir 0 0 0 0, 0 0 0 255 og / eller 255 0 0 0 deg svart? Gir 255255255 0, 0255255255 og / eller 255255255255 deg hvit? Har du prøvd å sette resten 3 byte til nuller (eller alfa kan muligens være 255) og innstillingen bare en byte samtidig til 127 og deretter til 255? Gjør deretter det samme for alle byte, og hold andre bytes verdier nuller. På denne måten bør du være i stand til å bekrefte rekkefølgen på de røde, grønne, blå og alfakanalbytene og se om verdiene deres har blitt vendt for eksempel.

De horisontale linjene i det som skal være ensfarget, og mangelen på vertikale linjer, antyder at hver "nye" linje lagres som forskjellen fra forrige linje. (Vent, du prøvde det). Du ser at du har noe bedre. Behandler du overløp riktig?

Overflyt, jeg har prøvd å si at hvis tallet går under null, så skal det gjøre at resultatet tilsvarer det absolutte tallet .. det vil si at -35 ville bli 35. Jeg har også prøvd å si at det skulle resultere i 255-35, men til ingen nytte. nrz har gitt meg en ide som jeg for øyeblikket prøver ut. Jeg kommer tilbake med funnene

I normal heltall matematikk blir overløp ganske enkelt * ignorert *. Når du teller med byte, er -35 = 256-35 = 221.

Bare en idé: kunne de 4 bytene deles i 2 byte for "dårlig" maskinvare, og 2 byte for "god" maskinvare? Så en hex 12345678 vil bety (alfa 1, rød 2, grønn 3, blå 4) på en skjerm som ikke støtter full 8-biters RGB, og (alpha 15, rød 26, grønn 37, blå 48) på en full farge en? Denne typen koding kan gjøre det mulig for langsom maskinvare å ikke lese "høyoppløsningsbiter" i det hele tatt, noe som sparer CPU-tid sammenlignet med å kaste disse bitene individuelt for hver piksel.

Takk for informasjonen Jongware, jeg visste ikke det. -Guntram Blohm, jeg tror ikke det er slik at antall byte er lik bredde * høyde * 4 (ARGB) og jeg tror ikke det ville være en grunn til å gjøre noe sånt for bakgrunnsbilder på en PS3. Akkurat nå lager jeg små testbilder der jeg kan observere hvordan spillet styrer dem. Jeg kommer tilbake når nyheter kommer.

Dette var en vill gjetning, men ettersom avkodingsrutinen din ser ut til å være riktig (den generelle utformingen er den samme i bildet ditt og PSP-bildet), og fargene ser ut til å ikke ha noe å gjøre med de faktiske fargene, tenkte jeg kanskje halvbyte må tolkes annerledes. AARRGGBB og ARGBARGB har begge 4 byte per piksel.

Også å dømme ut fra det "grønne" bildet ditt, vil jeg gjette at byte for den "venstre" delen av bildet og de for den "høyre" delen påvirker hverandre, med tanke på den blå vertikale linjen som er i din venstre del, men ikke i originalen; det samme med den gule linjen i høyre del, men ikke i den originale, som ser ut til å utvide den blå.

Det kan være en av [PNG-filteralgoritmene] (http://www.w3.org/TR/PNG-Filters.html). Det kan være lurt å prøve dem.