Format za skeniranje dokumentov: - PNG "ni primeren" - PNG je losless kompresija in zato dokument shrani z najvišjim možnim nivojem podrobnosti - to je zelo pomembno, če kasneje želimo dokument dati v OCR program (in nisem videl še enega, ki PNG ne bi sprejel) - JPEG "je malo boljše [kot PNG]" - edina razlika tukaj je, da JPEG izgubi več podrobnosti - slabše za branje in OCR (odvisno od nivoja kompresije je lahko največ ekvivalentno PNG, navadno pa precej slabše) - "PDF je bolj primeren, ker sta JPEG in PNG rastrska formata"... - skeniran PDF ni nič drugega kot dokument, ki ima na vsaki strani eno rastrsko sliko (navadno JPEG), z višino in širino 100%. Se strinjam, da je PDF boljši format za izmenjavo skeniranih dokumentov, a razlog za to ni v tem, da je vektorski, ampak v tem, da podpira npr. več strani in besedilni overlay (hibridni OCR dokumenti, kjer je ozadje skenirana slika, na vrhu pa neviden OCR tekst, ki se ga da izbirat, kopirat...) PDF, ki ste ga urejali v Acrobatu je zgledal dosti bolj kot "pravi" (vektorski) PDF dokument, ki ga je ustvaril računalnik, ne pa skeniran dokument, ki na katerem je Acrobat zagnal OCR. PREVISOK dpi pri skeniranju NE MORE BIT problematičen. Tudi, če v nastavitvah znižate ločljivost (npr. na polovico), bo scanner le ignoriral vsak drugi "pixel" senzorja. Čisto enak efekt lahko dosežemo, če skeniramo v polni ločljivosti in sliko zmanjšamo na enak način. Interpolacija v takem primeru ni potrebna, če izberemo ne-celoštevilski faktor resolucije (pri pomanjševanju ali pri zajemu!) pa se interpolacija tako ali tako izvede, le da se v enem primeru izvede v našem naprednem urejevalnem programu kjer imamo visok nivo nadzora na parametri, v drugem pa na počasnem vgrajenem mikroprocesorju skenerja, kjer je povdarek na hitrosti ne pa na kvaliteti [glej tudi line 27] "Joint Photographic Group" NE in NIKOLI NI obstajal. JPG ni format in ni na nikakoršen način "slabši" ali "predhodnik" JPEG. EDINI razlog, da končnica .jpg obstaja je, da DOS in zgodnje različice Windows OS niso dovolile več kot 3 znake v datotečni končnici. .JPG je torej le okrajšava za .JPEG, tako kot je .HTM za .HTML in .TIF za .TIFF (spet ista napaka - TIF ne obstaja, samo TIFF). Naj jo nekdo prosim prosi da vam da primer JPG pa JPEG fajla pa vam pokaže razliko! Al pa naj gre v Photoshop pa shrani ISTI projekt enkrat kot JPG enkrat pa kot JPEG pa naredi sha1sum al pa binary diff pa pokaže kje je ta supposed razlika. Poslan je bil mail na JPEG PR department s tem vprašanjem - ODGOVOR V ZATOTEKI jpeg.txt (TL;DR: imam prav) Že nekaj let je WebP podprt v vsakem sodobnem brskalniku [https://caniuse.com/webp] (also, Operi ni Googlov brskalnik...) Nedestruktivna manipulacija je lastnost programske opreme, ne formata rastrske slike (torej če program in njegov delavni format podpirata nedestruktivno urejanje, format same slike ni pomemben - lahko je JP(E!)G, PNG, BMP ali kateri koli RAW format). Prevelika resolucija (v vašem primeru PNG slik) nima nobene veze z barvno globino in kot posledica zmanjšanja le-te posterizacijo. Edina situacija, kjer prevelika resolucija vpliva na barve je, ko želimo datoteko z neko zgornjo mejo velikosti (bajtov na disku) in smo, da to dosežemo, primorani zmanjšati barvno ločljivost. V tem primeru pa še vedno ni problem v tem, da je resolucija prevelika, ampak v tem, da smo z namenom zmanjšanja datoteke zmanjšali barvno globino, resolucije pa ne. Enako logiko lahko prenesemo na vsak drug format: npr. lahko rečemo, da če želimo 60MP sliko stisniti na 600kB v JPEG formatu moramo tako sliko pretvoriti v monokromo, znižati število nivojev sivine na 8 in uporabiti najvišji kompresijski nivo - a to res demonstrira slabost JPEG formata, ali le našo nezmožnost razumevanja pomembnosti različnih parametrov slike, ki jih lahko kompresiramo? Omenim še, da res obstajajo slabosti pri zajemu slik v visoki resoluciji, a te so posledica tehnologije zajema in nimajo veze z formatom hrambe. Fotoaparat ali skener s senzorjem fiksne velikosti mora za večjo resolucijo imeti manjše "pixle", kar povroči več šuma in slabšo občutljivost na svetlobo. Tako je npr Sony A7S z 12MP v nizki svetlobi boljši od Sony A7R z 40MP senzorjem - a to, da mi v nastavitvah spremenimo resolucijo zajema pikslov ne čudežno pomanjša! Vektorska grafika "ne more upodabljat več kot 256 barv"?? Od kot pa ta ideja? Vektorska grafika, kot koncept, ni omejena v številu barv, saj to določa posamezen format. Če bi to želeli, bi lahko definirali format, ki podpira 64-bit-per-channel RGB barve - število tako veliko, da ga WolframAlpha odkar sem začel pisati ta odstavek do sedaj še vedno ni izpisal. Pa se raje držimo konkretnih formatov: SVG na primer podpira vsaj sRGB, CIE LAB ter poljubne ICC profile, enako tudi AI. [UPDATE 25 minute kasneje, WolframAlpha še vedno računa] SVG "zagotavlja majnše velikost kot JPEG ali GIF" - ponovno primerjava, ki ji niti izraz "apples and oranges" ne zadošča (pomaranča in jabolko sta vsaj oba okrogla). Najprej, ta primerjava velja za vse vektorske formate, ne le SVG, sicer pa taka primerjava tako ali tako ni veljavna - primerjava velikosti je čisto odvisna od vsebine datoteke. Linearni gradient dveh barv čez celoten zaslon bo seveda porabil ogromno več prostora v rastrski obliki, med tem ko bo fotografija, če jo poskusimo fotorealistično "prerisati" v vektorski format porabila dosti, dosti več kot npr. JPEG. SVG "izvorna koda" - ne obstaja. SVG je format, ne program, torej je odprta specifikacija, ne koda. Obstajajo mnoge odprto-kodne IMPLEMENTACIJE svg specifikacije, ampak enako velja tudi za PDF, EPS... Tudi referenčne implementacije za SVG ni! SVG grafiko podpirajo VSI obstoječi brskalniki in NE potrebujemo "vtičnikov" [https://caniuse.com/svg]. Celoten point W3C standardov je, da vtičnikov ne potrebujemo, saj jih implementirajo brskalniki sami. Tista projektna..infographic... A ni bilo rečeno da bo to natisnjeno? Zakaj je potem barvna shema podana v sRGB hex kodah? A ni pravilna uporaba formatov in barvnih sistemov, like, celi point tega predmeta?? Nizka globinska ostrina in "portrait mode" umetno megljenje predstavit kot način kompresije je....problematično. Le v kombinaciji s kompresijskim algoritmom, ki zna pomanjšano gostoto informacij v zamegljenih območjih izkoristiti, se velikost datoteke spremeni. Npr. čisto zamegljena RAW fotografija ne bo imela nobene razlike v velikosti datoteke. Zelo dvomim da študenti, ki se vam v trenutku ne javijo ko jih pokličete po imenu, sploh niso prisotni. Nimajo vsi vedno priklopljenega mikrofona, da lahko v nekaj sekundah odgovorijo; tudi mira in tišine okrog sebe marsikdo nima, ali pa ne more govorit, ker je nekdo drug v bližini tudi v klicu in bi jih s tem motil. Adaptivni interpolacijski algoritmi so SAMO v lastniških programih? You sure [0]? Still sure [1]? How about now [2]? I can do this all day [3] [0] https://github.com/idealo/image-super-resolution [1] https://github.com/nagadomi/waifu2x [2] https://github.com/IBM/MAX-Image-Resolution-Enhancer [3] https://www.collabora.com/news-and-blog/blog/2020/09/21/open-source-meets-super-resolution-part-1/ "Kakšno je" razmerje med reprodukcijsko in kočno ločljivostjo ni smiselno vprašanje. Že itak ni jasno, da sprašujete za upodobitveni faktor, ker "razmerje" lahko pomeni "relationship" ali "ratio". Tudi, ko vemo kaj v resnici sprašuejete, vprašanje nima odgovora. Sprejeli ste odgovor 2x, ki je očitno vaše zlato pravilo (ne pravim, da se ne strinjam), a to je le predlagano razmerje - ni inherentna lastnost. Hkrati manj kot minuto kasneje v drugem vprašanju pričakujete odgovor 4x - torej se pravilno zavedate, da je odgovor tesno odvisen od konteksta (formata tiska, načina prikaza, načina tiska in lastnosti same grafike). Kaj je torej pravilen odgovor na vaše vprašanje? "Ja, odvisno je..." ############################### # # # THE GOOD STUFF # # Da ne bom samo kritiziral # # # ############################### Poglavje o kompresiji zelo obširno in presenetljivo poglobljeno. Tudi moderni kodeki, kot so AV1 in HEVC, ter tehnike kot npr. progresivno kodiranje, so predstavljeni.