eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.rec.foto.cyfrowa › hdr a Jpg
Ilość wypowiedzi w tym wątku: 148

  • 61. Data: 2009-03-12 13:12:59
    Temat: Re: hdr a Jpg
    Od: "b...@n...pl" <b...@n...pl>

    Janko Muzykant napisał(a):
    > b...@n...pl pisze:
    >> Ale to zdjęcie wygląda strasznie sztucznie.
    >
    > Zasługa lamp sodowych. Wiem i dlatego w końcu przy okazji zrobiłem
    > ''niesztucznego'' hadeera - nic ciekawego treścią, nie do uzyskania w

    Swoją drogą lampy sodowe wymyślił ktoś, kto nie lubił fotografować w
    nocy. Miasta w nocy to straszliwy galimatias rodzajów świateł. Żarowe,
    sodowe, rtęciowe, neony. Często nie da się ustawić balansu bieli, bo
    mamy z 5 różnych świateł o różnych temperaturach barwowych, nieciągłych
    widmach.

    Osobiście uważam, że jednak trzeba zostawiać różową poświatę od lamp
    sodowych, w końcu to jest na tyle silna dominata, że w rzeczywistości
    pod taką latarnią biała kartka papieru jest różowa. Więc nie ma co tego
    za bardzo korygować.

    wer


  • 62. Data: 2009-03-12 13:13:11
    Temat: Re: hdr a Jpg
    Od: Mateusz Ludwin <n...@s...org>

    Janko Muzykant wrote:
    > Mateusz Ludwin pisze:
    >>> Ale to zdjęcie wygląda strasznie sztucznie.
    >>
    >> No a jak ma wyglądać prezentowane na monitorze o kilku EV? HDRI to nie
    >> jest technologia dla fotografów.
    >
    > Tylko dla marsjan :)
    > HDR to kompresja dynamiki właśnie po to, żeby dało się drukować i
    > wyświetlać.

    Kompresja to tonemapping.
    HDR to złączanie ekspozycji i przetwarzanie przed tonemappingiem.
    HDRI zawsze było technologią głównie dla grafików komputerowych, chyba nikt poza
    amatorami na forach nie używa tego w fotografii.
    --
    Mateusz Ludwin mateuszl [at] gmail [dot] com


  • 63. Data: 2009-03-12 13:20:30
    Temat: Re: hdr a Jpg
    Od: Janko Muzykant <j...@w...pl>

    Mateusz Ludwin pisze:
    >>> No a jak ma wyglądać prezentowane na monitorze o kilku EV? HDRI to
    >>> nie jest technologia dla fotografów.
    >>
    >> Tylko dla marsjan :)
    >> HDR to kompresja dynamiki właśnie po to, żeby dało się drukować i
    >> wyświetlać.
    >
    > Kompresja to tonemapping.
    > HDR to złączanie ekspozycji i przetwarzanie przed tonemappingiem.

    Niech i tak będzie, hdry wykonuje się w celu kompresji zakresu tonalnego
    (zwanego tonemappingiem, którego to określenia ja nie lubię).

    > HDRI zawsze było technologią głównie dla grafików komputerowych, chyba
    > nikt poza amatorami na forach nie używa tego w fotografii.

    Ależ skąd. Używa się tego zawodowo przy robieniu ujęć obiektów
    statycznych przekraczających użyteczną dynamikę matryc.

    --
    pozdrawia Adam
    różne takie tam: www.smialek.prv.pl
    /dzień dobry, nie piję, nie palę, nie ćpam - czy należy mi się renta?/


  • 64. Data: 2009-03-12 13:28:40
    Temat: Re: hdr a Jpg
    Od: Mateusz Ludwin <n...@s...org>

    Janko Muzykant wrote:

    > Ależ skąd. Używa się tego zawodowo przy robieniu ujęć obiektów
    > statycznych przekraczających użyteczną dynamikę matryc.

    Faktycznie w pracy zarobkowej ktoś używa HDRI zamiast odpowiedniego doświetlania
    lampami?
    --
    Mateusz Ludwin mateuszl [at] gmail [dot] com


  • 65. Data: 2009-03-12 13:31:33
    Temat: Re: hdr a Jpg
    Od: "Stefan Nawrocki" <o...@3...com.pl>


    Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
    news:gpaqfn$jnr$1@inews.gazeta.pl...
    > Stefan Nawrocki wrote:
    > > Wydaje mi się, że różne pojęcia, które w wątku się pojawiają nie do
    > > końca są dobrze interpretowane.
    > > Pierwsza sprawa - to liczba bitów przypadająca na składową koloru - czy
    > > to jest 8, czy 12 - co to tak naprawdę zmienia?
    > > Jeśli czerń odpowiada poziomowi 0, a biel poziomowi maksymalnemu
    >
    > W HDRI nie ma poziomu maksymalnego - to jest jedno z podstawowych założeń
    > tego typu obrazów. Dodatkowe bity idą i w rozdzielczość i w zakres, bo
    > odcienie opisuje się liczbami zmiennoprzecikowymi.

    Ten fragment nie byl o HDR, ale o tym, że niektórzy sądzą, że zmiana liczby
    bitów (jpg - 8, RAW - 12) zmienia w istotny sposób zakres tonalny. Tak nie
    jest.


    > > I druga sprawa - tak sklejona skala szarości podzielona przez odpowiedni
    > > współczynnik da się zobrazować na monitorze 8-bitowym, a straty będą
    > > polegały na utracie liczby dostępnych poziomów.
    > > Tak wygląda most na tym etapie:
    > > http://www.3n.com.pl/Nikon/most_1.jpg
    >
    > Nieprawda, to nie jest obraz powstały przez odrzucenie nadmiarowych
    > bitów HDRI. Te cienie są powyciągane przez tonemapping.

    No cóż - nie lubię jak zarzuca mi się kłamstwo, więc musze się bronić :-).
    Wiesz - ja od 20 lat _tworzę_ oprogramowanie graficzne (www.3n.com.pl) i
    wiem jakim algorytmem przetwarzam swoje obrazy. Zwłaszcza, kiedy robię to za
    pomocą programów swojego autorstwa :-).

    Niżej wklejam kod, który przetwarza trzy pliki:

    -------------------------------------------------

    #include <windows.h>
    inline long ScanBytes(int pixWidth, int bitsPixel) {
    return (((long)pixWidth*bitsPixel+31)>>5 /*/32*/)<<2;;
    }

    BYTE* LoadBitmap(char* filename){
    BITMAPFILEHEADER bfh;
    HANDLE h=CreateFile(filename, GENERIC_READ, 0, 0, OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL, 0);
    DWORD r;
    ReadFile(h, &bfh, sizeof(bfh), &r, 0);
    BYTE* data=new BYTE[bfh.bfSize];
    ReadFile(h, data, bfh.bfSize, &r, 0);
    CloseHandle(h);
    return data;
    }
    void SaveBitmap(BYTE* f, char* filename){
    BITMAPINFOHEADER* bih=(BITMAPINFOHEADER*)f;
    int w=bih->biWidth;
    int h=bih->biHeight;
    int bpl=ScanBytes(w, 24);
    BITMAPFILEHEADER bfh;
    bfh.bfType='BM';
    bfh.bfSize=sizeof(BITMAPINFOHEADER)+bpl;
    bfh.bfReserved1=0;
    bfh.bfReserved2=0;
    bfh.bfOffBits=sizeof(BITMAPINFOHEADER)+sizeof(BITMAP
    FILEHEADER);

    DWORD wr;
    HANDLE handle=CreateFile(filename, GENERIC_WRITE, 0, 0, OPEN_ALWAYS,
    FILE_ATTRIBUTE_NORMAL, 0);
    WriteFile(handle, &bfh, sizeof(bfh), &wr, 0);
    WriteFile(handle, f, bpl*h, &wr, 0);
    CloseHandle(handle);
    }
    void ShowBitmap(BYTE* d){
    BITMAPINFOHEADER* bih=(BITMAPINFOHEADER*)d;
    HDC hdc=GetDC(0);
    StretchDIBits(hdc, 0, 0, bih->biWidth, bih->biHeight,
    0, 0, bih->biWidth, bih->biHeight,
    (BITMAPINFOHEADER*)(d+sizeof(BITMAPINFOHEADER)),
    (BITMAPINFO*)bih, DIB_RGB_COLORS, SRCCOPY);
    ReleaseDC(0, hdc);
    }
    BYTE* suma(BYTE* f1, BYTE* f2, BYTE* f3){
    BYTE* d1=(BYTE*)(f1+sizeof(BITMAPINFOHEADER));
    BYTE* d2=(BYTE*)(f2+sizeof(BITMAPINFOHEADER));
    BYTE* d3=(BYTE*)(f3+sizeof(BITMAPINFOHEADER));
    BITMAPINFOHEADER* bih=(BITMAPINFOHEADER*)f1;
    int w=bih->biWidth;
    int h=bih->biHeight;
    int bpl=ScanBytes(w, 24);
    BYTE* su=new BYTE[bpl*h]+sizeof(BITMAPINFOHEADER);
    BYTE* s=su+sizeof(BITMAPINFOHEADER);
    MoveMemory(su, f2, sizeof(BITMAPINFOHEADER)+bpl*h);
    float l1=150;
    float l2=250;
    double c1=0.9; <---------- Tu jest współczynnik, o którym piszę niżej
    double c2=1-c1;
    for(int y=0; y<h; y++){
    for(int x=0; x<w; x++){
    float gray=(d2[x*3+bpl*y]+d2[x*3+bpl*y+1]+d2[x*3+bpl*y+2])
    /3.0;
    float r1, g1, b1;
    float r2, g2, b2;
    {
    double v2=(gray-l1)/l1;
    double v1=1-v2;
    r1=v1*d3[x*3+bpl*y+2]+v2*d2[x*3+bpl*y+2];
    g1=v1*d3[x*3+bpl*y+1]+v2*d2[x*3+bpl*y+1];
    b1=v1*d3[x*3+bpl*y]+v2*d2[x*3+bpl*y];
    }
    {
    double v2=(gray-l2)/l2;
    double v1=1-v2;
    r2=v1*d1[x*3+bpl*y+2]+v2*d2[x*3+bpl*y+2];
    g2=v1*d1[x*3+bpl*y+1]+v2*d2[x*3+bpl*y+1];
    b2=v1*d1[x*3+bpl*y]+v2*d2[x*3+bpl*y];
    }
    s[x*3+bpl*y]=max(0.0, min(255.0,c1*b1+c2*b2));
    s[x*3+bpl*y+1]=max(0.0, min(255.0,c1*g1+c2*g2));
    s[x*3+bpl*y+2]=max(0.0, min(255.0,c1*r1+c2*r2));
    }
    }
    return su;
    }
    int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int){
    BYTE* f1=LoadBitmap("D:\\testy\\1.bmp");
    BYTE* f2=LoadBitmap("D:\\testy\\2.bmp");
    BYTE* f3=LoadBitmap("D:\\testy\\3.bmp");
    // ShowBitmap(f1);
    // ShowBitmap(f2);
    // ShowBitmap(f3);
    MessageBox(0,"","",MB_OK);
    BYTE* s=suma(f1, f2, f3);
    ShowBitmap(s);
    SaveBitmap(s, "D:\\testy\\wynik.bmp");
    return 0;
    }
    -------------------------------

    Jeśli masz kompilator C - to sam zobacz jak to działa :-).
    Strzałką zaznaczyłem współczynnik "jasności". Dla wartości 0.9 - wynik jest
    taki:
    http://www.3n.com.pl/Nikon/wynik_09.jpg
    Jak widzisz (jeśli znasz język C, jeśli nie - to wierz mi na słowo) - w
    algorytmie nie ma żadnego mapowania tonów, tylko opercje na poziomach (sumy,
    średnie, itp.).


    Pozdrawiam
    Stefan Nawrocki






  • 66. Data: 2009-03-12 13:38:21
    Temat: Re: hdr a Jpg
    Od: Gotfryd Smolik news <s...@s...com.pl>

    On Thu, 12 Mar 2009, Janko Muzykant wrote:

    > Paweł W. pisze:
    >> abpc radzi sobie świetnie z D3 i pojedynczą ekspozycją pod Słońce.
    >
    > Bo ma hdra sprzętowego :)

    W D3? A jak on tam działa?
    (bo jak w S3 to wiem!)

    pzdr, Gotfryd


  • 67. Data: 2009-03-12 13:43:13
    Temat: Re: hdr a Jpg
    Od: "Jakub Jewuła" <b...@s...com.pl>

    >> Ależ skąd. Używa się tego zawodowo przy robieniu ujęć obiektów
    >> statycznych przekraczających użyteczną dynamikę matryc.
    >
    > Faktycznie w pracy zarobkowej ktoś używa HDRI zamiast odpowiedniego
    > doświetlania lampami?

    "Fotograficy cyfrowi" ;-)

    Oddac trzeba sprawiedzliwosc, nie zawsze dany
    obiekt da sie doswietlic jakakolwiek lampa.

    Inna sprawa, ze zazwyczaj da sie ten sam obiekt
    sfotografowac o innej porze dnia / w innych warunkach.
    No, ale teraz jest moda taka, zeby robic zdjecia kiedy
    sie ma czas a potem PhotoShopowac zamiast nauczyc
    sie robic zdjecia dobrze...

    q



  • 68. Data: 2009-03-12 13:44:47
    Temat: Re: hdr a Jpg
    Od: "Jakub Jewuła" <b...@s...com.pl>

    ...
    >> Nieprawda, to nie jest obraz powstały przez odrzucenie nadmiarowych
    >> bitów HDRI. Te cienie są powyciągane przez tonemapping.
    >
    > No cóż - nie lubię jak zarzuca mi się kłamstwo, więc musze się bronić
    > :-). Wiesz - ja od 20 lat _tworzę_ oprogramowanie graficzne
    > (www.3n.com.pl) i wiem jakim algorytmem przetwarzam swoje obrazy.
    > Zwłaszcza, kiedy robię to za pomocą programów swojego autorstwa :-).
    >
    > Niżej wklejam kod, który przetwarza trzy pliki:
    >
    > -------------------------------------------------
    >
    > #include <windows.h>
    > inline long ScanBytes(int pixWidth, int bitsPixel) {
    > return (((long)pixWidth*bitsPixel+31)>>5 /*/32*/)<<2;;
    > }
    >
    > BYTE* LoadBitmap(char* filename){
    > BITMAPFILEHEADER bfh;
    > HANDLE h=CreateFile(filename, GENERIC_READ, 0, 0, OPEN_EXISTING,
    > FILE_ATTRIBUTE_NORMAL, 0);
    > DWORD r;
    > ReadFile(h, &bfh, sizeof(bfh), &r, 0);
    > BYTE* data=new BYTE[bfh.bfSize];
    > ReadFile(h, data, bfh.bfSize, &r, 0);
    > CloseHandle(h);
    > return data;
    > }
    > void SaveBitmap(BYTE* f, char* filename){
    > BITMAPINFOHEADER* bih=(BITMAPINFOHEADER*)f;
    > int w=bih->biWidth;
    > int h=bih->biHeight;
    > int bpl=ScanBytes(w, 24);
    > BITMAPFILEHEADER bfh;
    > bfh.bfType='BM';
    > bfh.bfSize=sizeof(BITMAPINFOHEADER)+bpl;
    > bfh.bfReserved1=0;
    > bfh.bfReserved2=0;
    > bfh.bfOffBits=sizeof(BITMAPINFOHEADER)+sizeof(BITMAP
    FILEHEADER);
    >
    > DWORD wr;
    > HANDLE handle=CreateFile(filename, GENERIC_WRITE, 0, 0, OPEN_ALWAYS,
    > FILE_ATTRIBUTE_NORMAL, 0);
    > WriteFile(handle, &bfh, sizeof(bfh), &wr, 0);
    > WriteFile(handle, f, bpl*h, &wr, 0);
    > CloseHandle(handle);
    > }
    > void ShowBitmap(BYTE* d){
    > BITMAPINFOHEADER* bih=(BITMAPINFOHEADER*)d;
    > HDC hdc=GetDC(0);
    > StretchDIBits(hdc, 0, 0, bih->biWidth, bih->biHeight,
    > 0, 0, bih->biWidth, bih->biHeight,
    > (BITMAPINFOHEADER*)(d+sizeof(BITMAPINFOHEADER)),
    > (BITMAPINFO*)bih, DIB_RGB_COLORS, SRCCOPY);
    > ReleaseDC(0, hdc);
    > }
    > BYTE* suma(BYTE* f1, BYTE* f2, BYTE* f3){
    > BYTE* d1=(BYTE*)(f1+sizeof(BITMAPINFOHEADER));
    > BYTE* d2=(BYTE*)(f2+sizeof(BITMAPINFOHEADER));
    > BYTE* d3=(BYTE*)(f3+sizeof(BITMAPINFOHEADER));
    > BITMAPINFOHEADER* bih=(BITMAPINFOHEADER*)f1;
    > int w=bih->biWidth;
    > int h=bih->biHeight;
    > int bpl=ScanBytes(w, 24);
    > BYTE* su=new BYTE[bpl*h]+sizeof(BITMAPINFOHEADER);
    > BYTE* s=su+sizeof(BITMAPINFOHEADER);
    > MoveMemory(su, f2, sizeof(BITMAPINFOHEADER)+bpl*h);
    > float l1=150;
    > float l2=250;
    > double c1=0.9; <---------- Tu jest współczynnik, o którym piszę niżej
    > double c2=1-c1;
    > for(int y=0; y<h; y++){
    > for(int x=0; x<w; x++){
    > float gray=(d2[x*3+bpl*y]+d2[x*3+bpl*y+1]+d2[x*3+bpl*y+2])
    /3.0;
    > float r1, g1, b1;
    > float r2, g2, b2;
    > {
    > double v2=(gray-l1)/l1;
    > double v1=1-v2;
    > r1=v1*d3[x*3+bpl*y+2]+v2*d2[x*3+bpl*y+2];
    > g1=v1*d3[x*3+bpl*y+1]+v2*d2[x*3+bpl*y+1];
    > b1=v1*d3[x*3+bpl*y]+v2*d2[x*3+bpl*y];
    > }
    > {
    > double v2=(gray-l2)/l2;
    > double v1=1-v2;
    > r2=v1*d1[x*3+bpl*y+2]+v2*d2[x*3+bpl*y+2];
    > g2=v1*d1[x*3+bpl*y+1]+v2*d2[x*3+bpl*y+1];
    > b2=v1*d1[x*3+bpl*y]+v2*d2[x*3+bpl*y];
    > }
    > s[x*3+bpl*y]=max(0.0, min(255.0,c1*b1+c2*b2));
    > s[x*3+bpl*y+1]=max(0.0, min(255.0,c1*g1+c2*g2));
    > s[x*3+bpl*y+2]=max(0.0, min(255.0,c1*r1+c2*r2));
    > }
    > }
    > return su;
    > }
    > int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int){
    > BYTE* f1=LoadBitmap("D:\\testy\\1.bmp");
    > BYTE* f2=LoadBitmap("D:\\testy\\2.bmp");
    > BYTE* f3=LoadBitmap("D:\\testy\\3.bmp");
    > // ShowBitmap(f1);
    > // ShowBitmap(f2);
    > // ShowBitmap(f3);
    > MessageBox(0,"","",MB_OK);
    > BYTE* s=suma(f1, f2, f3);
    > ShowBitmap(s);
    > SaveBitmap(s, "D:\\testy\\wynik.bmp");
    > return 0;
    > }
    > -------------------------------

    Mateuszu, czekamy na blyskotliwa ropiste ;))))))

    q



  • 69. Data: 2009-03-12 13:46:29
    Temat: Re: hdr a Jpg
    Od: Janko Muzykant <j...@w...pl>

    Mateusz Ludwin pisze:
    >> Ależ skąd. Używa się tego zawodowo przy robieniu ujęć obiektów
    >> statycznych przekraczających użyteczną dynamikę matryc.
    >
    > Faktycznie w pracy zarobkowej ktoś używa HDRI zamiast odpowiedniego
    > doświetlania lampami?

    I co, świecisz lampami w hali w której produkuje się np. koparki? :)
    Mnie się nie zdarzyło używać hdr, ale tylko dlatego, że klient nie chce
    płacić więcej godząc się na przepały w blikach i szum w cieniach.
    W studio sprawa wygląda zupełnie inaczej, tam można sobie świecić taką
    dynamikę na jaką ma się ochotę.

    --
    pozdrawia Adam
    różne takie tam: www.smialek.prv.pl
    /drogie omo, wyprałem i jest czyste, i białe, i wzruszyłem się to piszę/


  • 70. Data: 2009-03-12 13:49:22
    Temat: Re: hdr a Jpg
    Od: Janko Muzykant <j...@w...pl>

    Jakub Jewuła pisze:
    > Mateuszu, czekamy na blyskotliwa ropiste ;))))))

    Będzie riposta w asemblerze i zrobimy wszyscy karpia :)

    --
    pozdrawia Adam
    różne takie tam: www.smialek.prv.pl
    /zamiast telewizora oglądam pralkę - program ten sam, a jeszcze pierze/

strony : 1 ... 6 . [ 7 ] . 8 ... 15


Szukaj w grupach

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: