[elektro] Régi ferritgyűrűk Al értékei-> tömörítés

[Steve]

https://en.wikipedia.org/wiki/DjVu


    Compression

DjVu divides a single image into many different images, then compresses 
them separately. To create a DjVu file, the initial image is first 
separated into three images: a background image, a foreground image, and 
a mask image. The background and foreground images are typically 
lower-resolution color images (e.g., 100 dpi); the mask image is a 
high-resolution bilevel image (e.g., 300 dpi) and is typically where the 
text is stored. The background and foreground images are then compressed 
using a wavelet-based compression 
<https://en.wikipedia.org/wiki/Wavelet_compression#Wavelet_compression> 
algorithm named IW44.^[5] 
<https://en.wikipedia.org/wiki/DjVu#cite_note-djvupaper-5> The mask 
image is compressed using a method called JB2 (similar to JBIG2 
<https://en.wikipedia.org/wiki/JBIG2>). The JB2 encoding method 
identifies nearly identical shapes on the page, such as multiple 
occurrences of a particular character in a given font, style, and size. 
It compresses the bitmap of each unique shape separately, and then 
encodes the locations where each shape appears on the page. Thus, 
instead of compressing a letter "e" in a given font multiple times, it 
compresses the letter "e" once (as a compressed bit image) and then 
records every place on the page it occurs.

Optionally, these shapes may be mapped to UTF-8 
<https://en.wikipedia.org/wiki/UTF-8> codes (either by hand or 
potentially by a text recognition system 
<https://en.wikipedia.org/wiki/Text_recognition>), and stored in the 
DjVu file. If this mapping exists, it is possible to select and copy text.

Since JBIG2 was based on JB2, both compression methods have the same 
problems when performing lossy compression. Numbers may be substituted 
with similar looking numbers (such as replacing 6 with 8) if the text 
was scanned at a low DPI prior to lossy compression.



2015-11-08 16:55 keltezéssel, hobilobi at gmail.com írta:
> Az utolsó két mondatod tökéletesen igaz, de ez nem magyarázat arra, hogy
> egy A4-es oldalnyi szöveg
> képként tárolva, hogy lehet csak kicsit több mint 2-szerese az ASCII
> kódolásúnak.
> Való igaz, hogy a szöveg közötti soremelések nagyon röviden kódolhatók,
> de a karakteres részek már nem.
> Ráadásul a djvu fájlban az oldalnak háttere is van, vagyis a sorok
> közötti részek nem totál fehérek, és a betűk sem
> totál feketék.
> Itt ugyan van egy olyan gyanúm, hogy ez a háttér valamiféle "átlag"
> háttér mintán alapul, de nem tisztán az, mert
> egyes papírhibák okozta maszat is ott szokott lenni, ahol az valójában
> is van.
> Szóval nem tekinthető az oldal nyers (nem tömörített) képe tisztán 1-ek
> és 0-ák olyan sorozatának, ahol a 0 fehéret, az 1 pedig feketét jelent.
> Én raktam szines könyvet is djvu-ba, és meglehetősen jó minőségű lett,
> és rövid.
> Most direkt visszakerestem, A4-es méretű, az oldal területének fele,
> szines vagy FF kép. A könyv 835 oldal, és a fájl
> 238MB. Azaz oldalanként átlag 285 kB. A képernyőn a valós (A4) méret
> 3-szorosára (élhosszban) nagyítva, nem látszanak
> még pixelességek, a kép melletti apró betűs, forrást megjelölő szöveg
> tökéletesen szép.
> Összehasonlítottam a CHIP egy oldalának beszkennelt képével, ennek
> alapján a djvu oldal kb. 300 dpi felbontású lehet.
> Viszont a CHIP oldal ilyen felbontással 1.5MB, tehát 6.3-szer nagyobb a
> djvu oldalnál.
>
> Megnéztem egy pdf formátumú, 1/4 A4 méretű könyvet aminek minden második
> oldala szines kép. Ez 64 oldalas, és a mérete
> 17.5 MB. Ezt A4 méretre és 835 oldalra átszámolva 913 MB lenne. Majdnem
> 4-szer nagyobb a djvu-nál.
> Ezt a könyvet az eredeti méretének 3-szorosára nagyítva, a betűk már jól
> láthatóan pixelesek, tehát a felbontása messze
> nem éri el a djvu könyv felbontását.
>
> Ezek miatt számomra már a misztikummal határos a djvu tömörítése.
> Eddig még nem találtam semmi leírást a tömörítési módszeréről. Igaz nem
> kerestem napokig.
>
> István
>
>
> 2015.11.06. 11:45 keltezéssel, Karoly Kovacs írta:
>> Na de itt nem egy betűről van szó!
>> Csaknem az összes tömörítési eljárásnak az az alapja (legalábbis egy
>> lépése), hogy nagy mintákat keres. Ha megnézed ezt a pár sort, amit
>> írok, és képként próbálod nézni, azt láthatod, hogy a teljes képfelület
>> minimum 90%-a fehér, s csak kevés nem fehér felület van, s ráadásul
>> szöveg estén ez a nem fehér felület szinte bizonyosan fekete. Azaz a
>> statisztikai alapon történő tömörítás igen jó eredményeket ad.
>> Ki is lehetne próbálni, ha az ember egy ilyen fekete-fehér szöveget
>> eltesz színes(!) BMP fáljként, majd ugyanezt úgy módosítja, hogy a
>> szőveg betűi ne feketék legyenek, hanem mindegyik más-más színű, majd a
>> két fájlt utána (bárhogyan) tömöríti, akkor a fekete-fehér szöveget
>> tartalmazó fájl lesz a kisebb méretű. Legalábbis remélem. :)
>>
>> Károly
>>
>> Imre Kormos wrote:
>>> 2015. nov. 6. de. 12:17 ezt írta ("Karoly Kovacs" <koka55 at gmx.at>):
>>>> . Így nézve a szöveg képformátumban való tárolása (és
>>>> persze tömörítése) sokkal gazdaságosabb, mint egy szokásos, mezei ASCII
>>>> textfájl.
>>> Azért ne essünk túlzásokba. Egy A betű 1 byte ASCIIban, ezt nem lehet
>>> kisebb helyre bepaszírozni képként.. :)
>>> Ki
>>> -----------------------------------------
>>>              elektro[-flame|-etc]
>>>
>> -----------------------------------------
>>             elektro[-flame|-etc]
> -----------------------------------------
>            elektro[-flame|-etc]