Arutelu:JPEG

Juba avalausegi vajab ümber kirjutamist, sest JPEG on kasutatav ka kadudeta pakkimiseks.  • • • Kasutaja:Ahsoous • arutelu • 4. mai 2016, kell 14:10 (EEST)

Kadudeta pakitud JPEG-d võib pidada eraldi failivorminguks. Täpsustamata peetakse JPEG all harilikult silmas ikkagi kadudega pakitud vormingut. Nii et vähemasti selles suhtes avalause minu meelest sobib. Kadudeta pakkimise võimalust on artiklis praegu tagapool mainitud. 90.190.58.90 4. mai 2016, kell 17:54 (EEST)

Esitus peaks olema selgem. Jutt peab olema arusaadav ka mitteasjatundjale. Andres (arutelu) 4. mai 2016, kell 18:06 (EEST)

Kui tundub väga jabur, kustutaga ära. Tõlkisin ingliskeelset wikit ja mulle tundus see ka jabur. Üritan teksti loetavamaks teha 1 nädala jooksul. Tänan lugemast.

Ei ole mingit vajadust inglise viki artikli sisu siia üle kanda. Võib ju kasutada teisi allikaid. Andres (arutelu) 6. mai 2016, kell 11:55 (EEST)

Mis puutub kadudega/kadudeta pakkimisse, siis JPEG enkooder kasutab kadudega pakkimiseks kadudega ja kadudeta pakkimise algoritme. Lisaks on eraldiseisvalt kadudeta pakkimine. Mis tähendab, et jutt on mitmetähenduslik nii või naa, mis tähendab, et kõik on õige.

Kuidas nii? Tuleb leida viis mitmetähenduslikkuse vältimiseks.

Alguses on praegu öeldud:

meetod digitaalsete piltide kadudega/kadudeta pakkimiseks

Minu meelest on sellest võimatu aru saada. Andres (arutelu) 8. mai 2016, kell 08:39 (EEST)

JPEG on standard, kus on kirjeldatud kadudega ja kadudeta pakkimist. JPEG rakendused aga ei pruugi kogu standardit realiseerida. Kuna see on esimene lause, siis ei käi see ei standardi ega rakenduste kohta, ja peaks olema lihtsustatud. Edasisest tekstist peaks arusaadav olema, mis on mis. Eesti keeles kasutatakse kaldkriipsu eri võimaluste vahel. JPEG kadudeta pakkimiseks tehti hiljem eri standard, sest kadudeta pakkimine oli väga kehv JPEG standardis, kuigi see on seal olemas, see uus standard on JPEG-LS ja on JPEG-st eraldi, kuid seletab miks rakendused ei taha JPEG kadudeta pakkimist kasutada. Kuna vikis juba on pakkimise kohta artikkel, siis saab sealt lugada ka kadudega ja kadudeta pakkimise kohta. Mis arusaamatuks jääb?

Ma leian, et esimene lause peaks olema üheselt mõistetav. Ja miks ta peaks olema lihtsustatud? Kaldkriipsu kasutamine teeb asja segaseks. Kuidas seda lauset kõva häälega lugeda tuleks? Nii tulebki kirjutada, nagu räägitakse.

Miks üldse peaks esimeses lauses kadusid mainima, kui see on universaalne standard? Sissejuhatuses võib edaspidi mainida, et JPEG-d kasutatakse põhiliselt kadudega pakkimiseks jne.

"Meetod" on lihtsalt ebamäärasem, artikkel räägib ju ikkagi standardist, rakendused on alateema.

Pakun, et esimeses lauses võiks öelda "standard digitaalsete piltide pakkimiseks". Andres (arutelu) 8. mai 2016, kell 10:41 (EEST)

1982 aastal otsustas Rahvusvaheline Standardiorganisatsioon kokku panna komisjoni "Photographic Experts Group" (PEG), mille ülesandeks sai uurida meetodeid kuidas edastada videot, pilte ning teksti üle ISDN ühenduse. PEG'i eesmärgiks sai välja töötada tööstus standardid graafilise ja pildi info edastamiseks üle digitaalsete ülekande võrkude. Komisjoni sai omale tähise ISO TC97 W68. 1986 aastal alustas CCITT (tänane ITU-T) alam grupp CCITT SGVIII uurima meetodeid värvi ning hall toonides info pakkimiseks faksi sides. Pakke meetodid värvi faksi side jaoks olid aga väga sarnased nendele mida ka PEG uuris. Seetõttu otsustati, et kaks gruppi peaks oma jõud ühendama, et saaks välja töödatud üks ühine stardard. Uue gruppi nimeks saigi "Joint Photographic Experts Group". Grupi uueks tähiseks sai ISO JTC1.

Lood uue alajaotuse ==Ajalugu== ning lisad selle vahepealkirja alla tõlke vms, lisades ka viited allikale jne. suwa 22. juuli 2018, kell 18:57 (EEST)

Ehk ei keskenduks pakkimisele?

Tava-kasutajat ei huvita, kas JPEG pakib või kuidas või kui palju. See on failivorming, fotode või muude kujutiste talletamise viis. Ma redigeeriks kogu artikli sellest lähtepunktist vaadates üle?

Artikli lõpp (kodeerimise algoritm koos kodeerimise koefitsientide ja muuga) tundub liiga tehniline olevat. Kui ta on kord juba tõlgitud, siis las tema olla, aga kas keegi kasutab seda infot siit artiklist? Kurinurm (arutelu) 21. jaanuar 2022, kell 01:35 (EET)