eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.rec.foto.cyfrowaProblem z ostrością › Re: Problem z ostrością
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!news.nask.pl!news.nask.org.pl!not-for-mail
    From: Krzysztof Halasa <k...@p...waw.pl>
    Newsgroups: pl.rec.foto.cyfrowa
    Subject: Re: Problem z ostrością
    Date: Thu, 06 Mar 2014 22:44:38 +0100
    Organization: NASK - www.nask.pl
    Lines: 33
    Message-ID: <m...@i...localdomain>
    References: <le5m9m$h7r$1@news.task.gda.pl> <k8lqgzapoau2$.dlg@habeck.pl>
    <le62aj$321$1@news.task.gda.pl> <o7gmqdtb21gq$.dlg@habeck.pl>
    <leflce$bvs$1@news.task.gda.pl> <leqann$peq$1@node2.news.atman.pl>
    <e...@g...com>
    <leque3$5ri$1@node1.news.atman.pl>
    <a...@g...com>
    <lest80$5eo$1@node1.news.atman.pl>
    <c...@g...com>
    <lf7977$27t8$1@news2.ipartners.pl> <lf7scu$4bf$1@node2.news.atman.pl>
    <3...@g...com>
    <lf9fn2$59t$1@node1.news.atman.pl>
    <5318566c$0$2244$65785112@news.neostrada.pl>
    <lfac9j$5gv$1@node1.news.atman.pl>
    <0...@g...com>
    NNTP-Posting-Host: ni.piap.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=utf-8
    Content-Transfer-Encoding: 8bit
    X-Trace: pippin.nask.net.pl 1394142282 18606 195.187.100.4 (6 Mar 2014 21:44:42 GMT)
    X-Complaints-To: abuse ATSIGN nask.pl
    NNTP-Posting-Date: Thu, 6 Mar 2014 21:44:42 +0000 (UTC)
    Cancel-Lock: sha1:MXwBvc3haCMIVVxl0yPh689hhJ4=
    Xref: news-archive.icm.edu.pl pl.rec.foto.cyfrowa:901960
    [ ukryj nagłówki ]

    XX YY <f...@g...com> writes:

    > u mnie fluktuacje wielkosci siegaja 10 MB - od ok 21 do 31 MB.

    Typowe dla bezstratnej kompresji.

    > kiedys sporo czytalem na ten temat i nie chce mi sie wracac do tematu.
    > Raw to nie sa rzeczywiscie surowe dane z matrycy. Te surowe dane sa
    > dalece prztetworzone.

    A coś na poparcie tych teorii?

    > Gdyby to byly surowe dane , w zasadzie szybkie
    > procesory obrazowe nie bylyby potrzebne.

    Logika nieprawidłowa. Gdyby to były surowe dane (jakimi są,
    z dokładnością do znanych rzeczy, które robi sama matryca - w sensie
    scalaka), to właśnie te szybkie procesory byłyby (i są) potrzebne, by te
    surowe dane skorygować o np. balans bieli, o np. dane o martwych
    pikselach, przenieść do 8-bitowej przestrzeni RGB (albo innej
    np. Adobe), skompresować je JPEGiem itd. W przypadku filmów, trzeba
    zamiast JPEGa zrobić MJPEGa lub H.264 (zwykle) oraz zakodować jeszcze
    dźwięk.

    Gdyby te dane były już "dalece przetworzone", to właśnie wtedy tak szybkie
    procesory nie byłyby potrzebne (chyba że w matrycy, tak zresztą może
    być), bo po prostu pracy byłoby dla nich mniej.

    Są takie matryce, np. mogą od razu wystawiać obrazek 8-bitowy po
    odszumieniu, korekcji np. winietowania i błędów matrycy, AGC,
    przeskalowaniu, kompresji itp.
    --
    Krzysztof Hałasa

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: