39
  • Surranó
    #39
    Ha valaki még jár errefele... (heveny 3 hetes szabadságszerű távollét után vagyok)

    wilddog: majd meglátom, megtalálom-e :) bizonyára valamelyik cd-men lesz ;)

    TSL16b: PNG-8? konkrétan a 8-bites PNG-t akkor (az esélyegyenlőség kapcsán) említetted először, előtted se senki. De lehet, h átugrottam, rámutathatsz. Örülök azért, h megértjük egymást :)

    CAD: igen, tudom, hogy mikor jó a GIF és a PNG. Hozzáteszem azért, hogy nagyon gyenge kontrasztnál (fekete alapon nagyon sötét (kék) szöveg) a JPEG eljárásai egyszerűen használhatatlanok, mert úgyis összemossa. A GIF is kiesik esetemben, mert festményszerű ez a konkrét kép, így marad a PNG -- de ezt kirívó esetnek nevezném.
  • TSL16b
    #37
    COMMING SOON? Hamarosan kommunikálunk?

    Teljesen igazad van. Más szemszögbõl vizsgáltuk a dolgot. 8 bites átlátszósági csatornát nem csak a PNG tud tárolni, de ha ezt browserben akarod megjeleníteni, akkor csak az marad. Ha sikerül. Mozillával sikerült.
  • CAD
    #36
    Surrano: sok szinbol all (vagyis akkor keves szin, sok arnyalatabol, ahogy tetszik) - megjelnites szempontjabol sok... a gif es png akkor hatekony ha keves szinbol, ill. annak arnyalatabol all a kep.

    TSL 16b: www.half-life2.hu

    Ha adott egy mintas hatter, melynek szekvenciaja nem adott, es ra szeretnel tenni egy kepet, ugy hoyg beleolvadjon, ez megoldhato transparens giffel... de a minosege igen gyatra... jpg-vel kivitelezhetetlen, mert a hatter valtozo, a eloter kepenek koordinatai meg nem adottak... ezt egy alfa csatornas png vel kivaloan kivitelezheto.
  • [Dragon] Ati
    #35
    A JPEG tömörítés a képet RGB-ből YCC-be konvertálja, mert ebben a formában jobb tömörítés érhető el kisebb képi veszteség mellett. A kép két komponense 8x8as, míg a harmadik 16x16os négyzetekre van felosztva, ez utóbbit szintén 8x8ra kicsinyítik ezután (így az egyik komponens tömörítési aránya négyszerese lesz mint a másik kettőé, viszont erre a komponensre kevésbé érzékeny az emberi szem, tehát a veszteség is kevésbé látszik). A felosztást követően a blokkokon kétdimenziós diszkrét koszinusz transzformációt végeznek, mely a képrészletet frekvenciaösszetevőkre bontja (szintén 8x8as blokkok lesznek). Az eredményt egy kicsit átrendezve a 8x8as mátrixból egy nagyjából csökkenő számsorozatot kapunk, ezt könnyebb kvantálni, mint az eredeti dct mátrixot. A kvantálás után a kapott számsorozatot vagy Huffman, vagy aritmetikai kódolással tárolják.

    Matematikailag a JPEG tömörítésben egyedül a kvantálás az, ami a veszteséget okozza a tömörítésben, az összes többi lépés (eredetileg, mindent lebegőpontos műveletekkel végrehajtva) veszteségmentes.

    Ez a JPEG tömörítés talán legáltalánosabb formája (asszem ez a 4:1:1-es, színtranszformációval), azonban sokféle változat található, amelyek esetleg elhagyják a színátváltást, nem csak egy komponensnyi blokkot kicsinyítenek a negyedére, hanem többet és más arányokkal (pl.: 4:2:2, 4:2:1 vagy bármilyen más 4,2,1-esekkel leírható kombináció), ráadásul nem kötelező a három színcsatorna sem, asszem 1-4-ig bármennyi lehet (elvileg, bár gyakorlatban 1 vagy 3 szokott lenni /szürkeárnyalat vagy színes/).
  • RelakSfromhome
    #34
    Érdekes, nálam a kockásodás 8x8-as területen jön létre.
  • TSL16b
    #33
    Na, kiderült, hogy nem értek a szakmámhoz.

    Surranó: Tényleg, 24 bites? A PNG-8? Vagy az esélyegyenlõség érdekében a legfeljebb 8 bites GIF-et a PNG-24-gyel hasonlítsuk össze (aminél azért csak kisebb lesz a GIF, ha elég a max. 256 szín)?

    cad: Mi az a számos dolog, ami kivitelezhetetlen PNG kép nélkül? (Eltekintve talán egy PNG-képnézõ kipróbálásától.)
  • Surranó
    #31
    enen, TSL16b:
    a GIF max addig veszteségmentes, amíg beleférsz a 256 színű palettába. Ezért van az, hogy a veszteséges JPG _bármilyen_ (pl kontrasztos kocka) fényképre kisebb minőségromlást ad, mint a 256 színű GIF.

    A PNG viszont valóban 24 bites, kedves TSL16b.
  • Surranó
    #30
    qaz, cad:
    a szóban forgó levlap a szokásos fehér alapon piros nyomat volt, jobbára kék tintával teleírva. Kis fekete, meg egy helyen lila sorkiemelő. Meg amit a scanner még rákavar árnyék stb címén.
    Namost ez ugye három szín, de annak kábé 240ezer árnyalata. Ez most kevés színnek (5) vagy sok színnek (százezrek) számít?

    Másik, a gépi szöveg: van egy hatalmas képem, ami nem fehér alapon fekete, hanem pergamen alapon barna, de igen vsz gépi gyártmány. Mivel kellően elmebeteg vagyok, kb négyszeres (nyolcszoros?) nagyításban pásztáztam végig a pár ezerszer pár ezer pixelt, hogy látok-e különbséget a 24 bites veszteségmentes (hehe) BMP-hez képest... aztán a BMP-t ledúrtam.

    Ja, és a pontosság kedvéért: megnéztem, nem is 1 levlap, hanem kettő, szóval egy A5-ös oldal.

  • Surranó
    #29
    Wilddog:
    valaha írtam belőle referátumot... A JPEG (ez egy társaság neve) módszere vajmi kevéssé kötődik Huffman bácsihoz. Helyette: fogják a 16x16-os kockát, az értékeket veszik mint 256-odik szintű polinom értékeit, interpolálják, oszt a túlkis együtthatókat eldobják. Persze valahogy okosan. Ettől van a kockásodás pölö, de asszem a ring (csipke) is. Mindezt tán csatornánként (r,g,b; alfa sajna nincs gyárilag)
  • CAD
    #28
    Gif nem kisebb, ez hulyeseg, a PNG vagy ugyan akkora, vagy kisebb, semmikeppen sem nagyon (persze ha a png-be meg beleteszel alfa csatornat es egyeb extrakat, akkor megeshet hogy tenyleg nagyobb, de szamos dolog van ami nem kivitelezheto png nelkul!)ú

    PNG teljesen tamogatva van, csak utanna kellet picit nezni, teljeskoru tamogatast elvez, bar a crossbrowseres resze kicsit gyenge, elterjedsege is megfelelo, vagyis nem kell hogy elterjedt legyen, csak tamogatott, tamogatottsag adott, innentol kezdve rendben van a dolog.
  • TSL16b
    #26
    Kevés színre a PNG jó, de a GIF kisebb, és elterjedtebb. Fotóra a JPG sokkal kisebb, és nem sokkal rosszabb. Miben is jobb a PNG? Ha igaz, hogy szabadon felhasználható lesz a GIF, akkor az igazán el nem terjedt és teljesen nem implementált PNG-t kellene hanyagolni.
  • RelakSfromhome
    #24
    Dönöjű...
  • CAD
    #23
    Surrano: azert esszel kell hasznalni ezt is. A PNG akkor lehet jo, ha ekves szinbol all, ekkor viszont tobb ezer szer ezres kep is par kbyte lesz! - Sok szinre jpg a jobb...

    Relaks: a dolg ugy nez ki, hogy lennie kellene bal fent egy pirosbol attetszobe atmeno png-nek. Azert csak a gifet latod, mert a png CSS-bol van megadva egy div-be... a style.css-ben van definialva - hogy igy miert nem mozzillabol, hat azert mert egy (remelem) activ-x filter segitsegevel mukodik az attetszoseg csak... igy viszont csak ie-alatt megy.
  • RelakS
    #20
    Franc, ez a gif, de mentéskor a környéken nem láttam png-t
  • RelakS
    #19
    T / 4 5 6 - G C 4 3

    Ezt kéne csak látni, meg ferde vonalakat fehér alapon? A mozilla hozza.
  • Surranó
    #18
    ... háttértárról...
  • Surranó
    #17
    Nana. Egy kísérlet:
    1. scannelj be egy teleírt levlapot (szövegre a veszteség ugye tán jobban látszik, mert kontúros) 600 dpi-vel. Én egy 3500x5500-as képet kaptam.
    2. Mentsd el veszteségmentes truecolor PNG-ként és 95%-os jpegként (asszem, ACDSee-t használtam a konverthez). Nekem 34MB vs 6MB lett.
    3. Szép és jó monitoron tedd egymás mellé a kettőt, akár dupla nagyításban, és kérd meg a levlap íróját, hogy ugyan mondja már meg, melyik a veszteséges.

    Akivel csináltam, rosszul tippelt. Összeadva a méretkülönbséggel, meg hogy 34 mega puszta betöltése is másodpercekbe telik egy nemcsúcsmodern háttértáron...
  • nenad
    #14
    szerintem is a PNG a legmenobb, lehet benne alfa csatornat taroni, szeles skalan lehet tormoritni (vesztesegmentesen is), stb.

    Ami a fotok tarolasat illeti nem jobb (szerintem) a jpg. Csak elterjedtebb.
  • b
    #13
    szerintem a gif ugyanúgy halálra van itélve, mint az mp3. meg különben is, ma már nem illik jogvédett, csak egy céghez köthető formátumot használni!
  • CH4R1ie
    #12
    A PNG-nek egy kis hátránya, hogy több erőforrást használ fel a tömörítéshez és a nézegetéshez. Mellesleg szerintem ez a formátum a legalkalmasabb "Line Art"-ban szkennelt képek tárolására.
  • CAD
    #11
    Nah itt van egy IE alatt is mukodo, szep kis png cuccos :)

    http://www.force-x.hu/cad/png/

    Igy viszont valoszinuleg nem megy a tobbi bongeszovel :(.
  • CAD
    #10
    http://www.w3.org/Graphics/PNG/inline-alpha.html - Itt van a dolog, csak a lejebb emlitett filter nincs benne...
  • CAD
    #9
    Kozbe utannaneztem a dolgoknak, mozzilla, konq stb. tamogatja... ie-is, csak kell hozza " http://msdn.microsoft.com/library/default.asp?url=/workshop/author/filter/reference/filters/alphaimageloader.asp " - ez ;>
  • CAD
    #7
    Az alfa csatoran eleg sokretu dolog, a legismertebb tulajdonsaga az attetszosegbol a nem atetszosegbe vezeto atmenet szerkesztesenek lehetosege.
  • Cat #6
    mit tud az az alfa csatorna?
  • CAD
    #4
    Kerdesedre valaszolva, a PNG maga nem tud animaciot, ha gyorsan le szeretnem zarni a temat, hogy de attol meg nagyon is jo mert a flash az tud, es nem is kell gif, akkor hulyeseget mondanek.

    Viszont a PNG nek van egy extensionje, az MNG ami viszont mar tud animaciot is.

    A szornyu a dologban, hogy szinte osszes bongeszo es stb ismeri a png-t, de ha alfa csatornas pngvel talalkozik akkor a legujabbak is megadjak magukat, ami nem tul oromteli :(

    MNG tamogatottsaga is adott, csak gondolom azzal az alfa csatornas betegseggel mint a pngnel, marpedig ez nagyon nagyon gaz am.
  • gyraph
    #3
    A gif formátum palettás szín, és 256 színt tartalmazhat...A png ezzel ellentétben 24bit színmélységű is lehet, ráadásul a Macromedia Fireworks szoftverének "szinte" saját formátumává vált. A munkafolyamatot pedig épp úgy képes tárolni, mint a Photoshopnál a psd.
    Nem tudom mi köze van a kettőnek egymáshoz.
  • CAD
    #2
    A PNG olyat tud amelyet gif jelnleg nem, nevezetesen alfa csatornat, kulonbozo gamma ertek tarolasat, es 24 bites szinmelyseget - ha a bongeszok vegre szabvanyosan tamogatnak, akkor a gif letjogosultsaga lenne megkerdojelezheto, ugyanis png az esetek nagy reszebe kisebb, vagy ugyanakkora, a fent emlitett tecnikai tulajdonsagai meg mindenek fele emeli :)