-
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/