Peter, I just ask you for the ISO submission number and date.
Not links to comments on blogs, posts on usenet, obscure bulletin boards or suggestion to use Google. I want to see a trace of it on http://www.iso.org, something OFFICIAL.
As far as I can tell, DNG was never submitted for standardization.
The post you mention is just from a single individual, and it does not say anything about DNG being submitted for standardization. TIFF/EP being revised with input from DNG ("[having] Adobe's permission to incorporate modifications and developments made for DNG") does not say the Adobe DNG 1.3 specification will become an ISO standard. In fact the post in question was a call for input from anyone, saying the group in charge of TIFF/EP was open to suggestions (which is hardly surprizing).
There is a fine line between incorporating elements of DNG into an existing standard, and making DNG a standard in itself even if DNG was indeed derived from the TIFF/EP. Unofficial Adobe voices (like yours) are riding that line and interpreting it in a way that makes people believe that DNG is a standard, or close to become one.
In fact, unlike TIFF and TIFF/EP, DNG is proprietary and I'm under the impression that Adobe never really had any real intention to standardize it. Proof is the recent additions of the undocumented lossy and fast-load options that creates "DNG" files that only Adobe can read back safely.
DNG just became a closed, opaque format as those additions (some of them turned on by default in recent Adobe software e.g. Lightroom 4.0 and 4.1) are breaking and the lack of documentation makes it very difficult at best for anyone else to read those files.
How do you correlate this recent behavior with a standard, documented and stable format? I call it bait-and-switch from a company working on securing its future more than anything else.
Axel,
A quick use of the Google shows that Dietmar Wueller, a member of TC42 WG18, claimed to receive the offer from Adobe in March of 2007. I was not at the Archiving conference this year where I would have probably talked to Herr Wueller in person. Here is the email referenced on the DNG Wikipedia page.
Perhaps you could write to him or to the secretariat of the working group to find out what the current thinking of the group is. Here is the Secretariat's info from the ISO website.
Secretariat direct:
The ISO keeps track on everything, submitted, rejected, retired, accepted, and lists the status of everything. I keep hearing from unofficial voices, bloggers, Adobe evangelists etc that DNG was submitted to the ISO, yet I could not find ANY trace of it at www.iso.org, which has a comprehensive search engine. In fact the ISO is a champion of traceability and exactly the opposite of a black hole. So, Peter, where is the DNG submission? Please be thorough and post the submission number and date.
Linking CXX executable luminance-hdr.exe
c:/progra~2/codebl~1/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
Hi, Im trying to build Luminance HDR using CodeBlocks. I've obtained libraw using this makefile but I'm getting some errors related to references in libraw.
Any idea how to solve it or the origin of this problem?
Thanks in advance!
Raissel
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2299): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x231b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x23e8): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x243b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2625): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2aab): more undefined references to `_Unwind_Resume' follow
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD1Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame+0x427): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream4getsEPci+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream9scanf_oneEPKcPv+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD0Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream16tempbuffer_closeEv+0x13): more undefined references to `__gxx_personality_v0' follow
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x7722): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x79aa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x98fa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa02e): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa636): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xbe07): more undefined references to `__chkstk_ms' follow
collect2: ld returned 1 exit status
mingw32-make.exe[2]: *** [luminance-hdr.exe] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/luminance-hdr.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
Info: resolving half::_eLut by linking to __imp___ZN4half5_eLutE (auto-import)
1) Just ignore this for now.
2) The first warning will be eliminated in next release. This is generally an error, but it just prevent IO exception to occur on broken files.
3) The second warning is not an error. The code increments is_raw if get4() returns non-zero (and get4()-returned value is stored in i variable).
Hi Alex,
I'm facing the same problem. I get the bayers pattern from an industrial camera. Is there some methods to create the cam_xyz matrix ?
Another question.
Does LibRaw/dcraw need the cam_xyz matrix because it performs the post processing in XYZ color space ? If so, is it possible/easy to disable this transformation, so that one can do the post processing directly in RBG color space if an image is captured from e.g from Canon camera in CR2 format
The argument of which produces the better quality is pointless. You can produce the same quality with integers as you can with floating points as long as you use a sufficient amount of bits for your maths. One can use integers to implement floating points and it is a common practise on hardware that has no float point operations.
If you do not know how to use integers efficiently then you will need to use float points, of course. It is what floating points were designed for as these take care of precision issues through a non-fixed, floating representation so that you do not have to.
The argument between integer versus floating points, however, is still about speed. Integer operations are often faster, because they can use less bits and they allow you to trade quality for speed in addition.
I suggest that you use floating points. The speed difference between integers and floating points is often not huge, especially when instruction sets like SSE can be used and most compilers will try to use these automatically. Writing, debugging and maintaining precise integer code on the other hand is more difficult and as a result are integers mostly used when quality is not an issue.
I saw omp > used my brain. I removed openmp option while configuring and the program compiles and runs perfectly.
I just wanted to know if this is indeed the right way to compile a libraw program.
Thanks and Regards.
Sorry, but the method you are trying to use is wrong. Please have a look at how it is accomplished in, say, Fuji S5. You need to replace noisy and blown pixels altogether. There is no point in mixing good with bad.
If you are smart, do it on per channel basis.
Finally, you may want to check if you understand white balance well enough. Raw without white balance application looks green, search for UniWB.
Well, looks like the greens that appear are those of the raw nature of the files, I mean:
If I catch any raw file, and modify the values of all cells ('or pixels') such as multiplying by a value less than 1, it appears greenish around the resulting raw file. All this before demosaicing.
I have a suspicion it's because in a raw, there are 2 green cells for each cell red and blue.
Anyone can confirm me this?
Can you lower the brightness of a raw without the appearance of these greens, or what is the same I can multiply by something less than 1 without getting this effect?
Peter, I just ask you for the ISO submission number and date.
Not links to comments on blogs, posts on usenet, obscure bulletin boards or suggestion to use Google. I want to see a trace of it on http://www.iso.org, something OFFICIAL.
As far as I can tell, DNG was never submitted for standardization.
The post you mention is just from a single individual, and it does not say anything about DNG being submitted for standardization. TIFF/EP being revised with input from DNG ("[having] Adobe's permission to incorporate modifications and developments made for DNG") does not say the Adobe DNG 1.3 specification will become an ISO standard. In fact the post in question was a call for input from anyone, saying the group in charge of TIFF/EP was open to suggestions (which is hardly surprizing).
There is a fine line between incorporating elements of DNG into an existing standard, and making DNG a standard in itself even if DNG was indeed derived from the TIFF/EP. Unofficial Adobe voices (like yours) are riding that line and interpreting it in a way that makes people believe that DNG is a standard, or close to become one.
In fact, unlike TIFF and TIFF/EP, DNG is proprietary and I'm under the impression that Adobe never really had any real intention to standardize it. Proof is the recent additions of the undocumented lossy and fast-load options that creates "DNG" files that only Adobe can read back safely.
DNG just became a closed, opaque format as those additions (some of them turned on by default in recent Adobe software e.g. Lightroom 4.0 and 4.1) are breaking and the lack of documentation makes it very difficult at best for anyone else to read those files.
How do you correlate this recent behavior with a standard, documented and stable format? I call it bait-and-switch from a company working on securing its future more than anything else.
Axel,
A quick use of the Google shows that Dietmar Wueller, a member of TC42 WG18, claimed to receive the offer from Adobe in March of 2007. I was not at the Archiving conference this year where I would have probably talked to Herr Wueller in person. Here is the email referenced on the DNG Wikipedia page.
http://mail.kde.org/pipermail/digikam-devel/2007-April/012129.html
Perhaps you could write to him or to the secretariat of the working group to find out what the current thinking of the group is. Here is the Secretariat's info from the ISO website.
Secretariat direct:
Tel: +1 646-460-7897
Fax: +1 212 398 00 23
E-mail: jknopes@ansi.org
Peter
The ISO keeps track on everything, submitted, rejected, retired, accepted, and lists the status of everything. I keep hearing from unofficial voices, bloggers, Adobe evangelists etc that DNG was submitted to the ISO, yet I could not find ANY trace of it at www.iso.org, which has a comprehensive search engine. In fact the ISO is a champion of traceability and exactly the opposite of a black hole. So, Peter, where is the DNG submission? Please be thorough and post the submission number and date.
Unwind_resume is part of gcc's exception handler (according to goole :).
You need to enable exceptions library (e.g. via linking by g++, not gcc) on link stage.
Linking CXX executable luminance-hdr.exe
c:/progra~2/codebl~1/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
Hi, Im trying to build Luminance HDR using CodeBlocks. I've obtained libraw using this makefile but I'm getting some errors related to references in libraw.
Any idea how to solve it or the origin of this problem?
Thanks in advance!
Raissel
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2299): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x231b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x23e8): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x243b): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2625): undefined reference to `_Unwind_Resume'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.text+0x2aab): more undefined references to `_Unwind_Resume' follow
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD1Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame+0x427): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream4getsEPci+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream9scanf_oneEPKcPv+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastreamD0Ev+0x13): undefined reference to `__gxx_personality_v0'
../DEPs/lib/libraw/libraw_r.a(libraw_cxx.o):libraw_cxx.cpp:(.eh_frame$_ZN22LibRaw_file_datastream16tempbuffer_closeEv+0x13): more undefined references to `__gxx_personality_v0' follow
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x7722): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x79aa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0x98fa): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa02e): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xa636): undefined reference to `__chkstk_ms'
../DEPs/lib/libraw/libraw_r.a(dcraw_common.o):dcraw_common.cpp:(.text+0xbe07): more undefined references to `__chkstk_ms' follow
collect2: ld returned 1 exit status
mingw32-make.exe[2]: *** [luminance-hdr.exe] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/luminance-hdr.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
Info: resolving half::_eLut by linking to __imp___ZN4half5_eLutE (auto-import)
You may use LibRaw Visual Studio project files (in LibRaw/buildfiles catalog).
It works for me.
1) Just ignore this for now.
2) The first warning will be eliminated in next release. This is generally an error, but it just prevent IO exception to occur on broken files.
3) The second warning is not an error. The code increments is_raw if get4() returns non-zero (and get4()-returned value is stored in i variable).
Thanks a lot for your quick reply. I will have a try
Libraw calculates output transform (in RGB) based on output space matrix and xyz-matrix оf camera (see cam_xyz_coeff code).
If you don't have you camera color matrix, you may set output_parameter to 0 and you'll get non-converted (raw) colors from your camera.
Hi Alex,
I'm facing the same problem. I get the bayers pattern from an industrial camera. Is there some methods to create the cam_xyz matrix ?
Another question.
Does LibRaw/dcraw need the cam_xyz matrix because it performs the post processing in XYZ color space ? If so, is it possible/easy to disable this transformation, so that one can do the post processing directly in RBG color space if an image is captured from e.g from Canon camera in CR2 format
The argument of which produces the better quality is pointless. You can produce the same quality with integers as you can with floating points as long as you use a sufficient amount of bits for your maths. One can use integers to implement floating points and it is a common practise on hardware that has no float point operations.
If you do not know how to use integers efficiently then you will need to use float points, of course. It is what floating points were designed for as these take care of precision issues through a non-fixed, floating representation so that you do not have to.
The argument between integer versus floating points, however, is still about speed. Integer operations are often faster, because they can use less bits and they allow you to trade quality for speed in addition.
I suggest that you use floating points. The speed difference between integers and floating points is often not huge, especially when instruction sets like SSE can be used and most compilers will try to use these automatically. Writing, debugging and maintaining precise integer code on the other hand is more difficult and as a result are integers mostly used when quality is not an issue.
peterdk, do you can show(or upload) you config.sub and configure? thanks!
What camera do you use?
You may set output_color field of processing parameters structure to 0 to get raw color
I saw omp > used my brain. I removed openmp option while configuring and the program compiles and runs perfectly.
I just wanted to know if this is indeed the right way to compile a libraw program.
Thanks and Regards.
To get linear and balanced (not green) data, you need to
1) subtract black level from raw data
2) apply white balance
Ummm, let's me think about that...
RFC[] are calculate using: (for 3 images, sorted by exposition, lower exposition first, and so ... )
RFC[0]= 1.0 always
RFC[1]= SUM_A / SUM_B * RFC[0]
RFC[2]= SUM_B / SUM_C * RFC[1]
SUM_A is R,G1 and B from image 0
SUM_B is the same from image 1
SUM_C is the same from image 2
Then this must be refact so RFC[0] + RFC[1] + RFC[0] = 1.0 ?
Sorry, but the method you are trying to use is wrong. Please have a look at how it is accomplished in, say, Fuji S5. You need to replace noisy and blown pixels altogether. There is no point in mixing good with bad.
If you are smart, do it on per channel basis.
Finally, you may want to check if you understand white balance well enough. Raw without white balance application looks green, search for UniWB.
1) You do your calculations before white balance procedure, or after that?
2) What WB method is used
Yes, m1 = 1 - m2. But drFC1*m1 + drFC2*m2 will generally not being equal to 1.0
Thanks, lexa.
I do this when is it a mixed pixel.
// It's a mix pixel from various images gray16_pixel1 = *vct_gray16ViewSrc_iterator[i-1]; gray16_pixel2 = *vct_gray16ViewSrc_iterator[i]; drFC1 = vectorRFC[i-1]; drFC2 = vectorRFC[i]; m2 = static_cast<double>(*dbl_vct_it) - static_cast<double>( i ); m1 = static_cast<double>(1) - m2; mul1 = drFC1 * m1; mul2 = drFC2 * m2; gray16_pixel1 = gray16_pixel_t(round( static_cast<double>(gray16_pixel1) * mul1 + static_cast<double>(gray16_pixel2) * mul2 ) );If you look m1 and m2 they are weight compensed to 1 in a cell. see m1= 1 - m2
Sorry, when you talk about 'pixel' ... it is a cell, like 'R' or is it about four cell like the group(R,G1,B,G2) ?
NOTE: I use gray16_pixel_t because are simple values, from 0 to 65535 and dont have components (like red,green,blue)
Well, looks like the greens that appear are those of the raw nature of the files, I mean:
If I catch any raw file, and modify the values of all cells ('or pixels') such as multiplying by a value less than 1, it appears greenish around the resulting raw file. All this before demosaicing.
I have a suspicion it's because in a raw, there are 2 green cells for each cell red and blue.
Anyone can confirm me this?
Can you lower the brightness of a raw without the appearance of these greens, or what is the same I can multiply by something less than 1 without getting this effect?
Thank you.
I guess, for correct output you need to have sum of weight factors equal to 1.0 in each pixel
thanks
Pages