From oguzakyuz at gmail.com Tue Sep 1 19:47:52 2009 From: oguzakyuz at gmail.com (Oguz Akyuz) Date: Tue Sep 1 21:29:28 2009 Subject: [HDRI] bracket 1.0.0 (beta): cross platform HDRI application is out! Message-ID: <2e19d480909011947m4c035096q20eaa6b0eb768659@mail.gmail.com> Hello, I just wanted to share with everyone in this mailing list that the cross-platform HDRI application that I've been working on for quite some time now is finally out. You can freely download it from: http://www.coolhall.com/homepage/bracket/bracket.html There is a possibility that the application might not be working on Snow Leopard -- since I don't have a new enough mac to install that beauty I could not try it myself. I've personally verified it to be working on XP/Vista/Win7 for Windows, Tiger and Leopard for Mac, and Ubuntu 9.04 and Suse 11.0 for Linux. I'm eager to hear your comments. Please contact me for any bug reports, feature requests, or any thoughts and ideas. Best, Oguz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://radiance-online.org/pipermail/hdri/attachments/20090901/c917bf96/attachment.htm From Blochi at EdenFX.com Tue Sep 1 23:21:58 2009 From: Blochi at EdenFX.com (Christian Bloch) Date: Tue Sep 1 23:22:05 2009 Subject: [HDRI] bracket 1.0.0 (beta): cross platform HDRI application is out! In-Reply-To: <2e19d480909011947m4c035096q20eaa6b0eb768659@mail.gmail.com> References: <2e19d480909011947m4c035096q20eaa6b0eb768659@mail.gmail.com> Message-ID: <485F34A5-9288-4F78-B83E-0BDE7BA46488@EdenFX.com> Hi, Sounds very exciting. Thank you so much. Just tried it under Snow Leopard (with Rosetta installed), and it crashes right on launch. Even before any interface comes up. Here is the report: ---------------------------------------------------- Process: bracket [4459] Path: /Applications/_HDR/bracket.app/Contents/MacOS/bracket Identifier: bracket Version: ??? (???) Code Type: PPC (Translated) Parent Process: launchd [115] Date/Time: 2009-09-01 23:18:10.646 -0700 OS Version: Mac OS X 10.6 (10A432) Report Version: 6 Interval Since Last Report: 59031 sec Crashes Since Last Report: 4 Per-App Crashes Since Last Report: 3 Anonymous UUID: F31BE627-7228-4D61-9B44-087F0626EF5F Exception Type: EXC_CRASH (SIGTRAP) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x801bc82a __pthread_kill + 10 1 libSystem.B.dylib 0x801bc0d7 pthread_kill + 95 2 bracket 0xb80bfcb4 0xb8000000 + 785588 3 bracket 0xb80c01bb 0xb8000000 + 786875 4 bracket 0xb80dda6c 0xb8000000 + 907884 5 bracket 0xb814551b spin_lock_wrapper + 1791 6 bracket 0xb801d03b 0xb8000000 + 118843 Thread 1: 0 libSystem.B.dylib 0x800c58fa mach_msg_trap + 10 1 libSystem.B.dylib 0x800c6067 mach_msg + 68 2 bracket 0xb819448f CallPPCFunctionAtAddressInt + 206155 3 libSystem.B.dylib 0x800f2fe1 _pthread_start + 345 4 libSystem.B.dylib 0x800f2e66 thread_start + 34 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x8027c500 ecx: 0xb7fff9ac edx: 0x801bc82a edi: 0xb8211620 esi: 0x00000005 ebp: 0xb7fff9d8 esp: 0xb7fff9ac ss: 0x0000001f efl: 0x00000286 eip: 0x801bc82a cs: 0x00000007 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x8011f466 Binary Images: 0x80000000 - 0x8006afe7 libstdc++.6.dylib ??? (???) <411D87F4- B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib 0x800c5000 - 0x80269feb libSystem.B.dylib ??? (???) <068CC3F2-F867- A231-A16C-CC01C29A9816> /usr/lib/libSystem.B.dylib 0x802e9000 - 0x802ecfe7 libmathCommon.A.dylib ??? (???) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/ libmathCommon.A.dylib 0x8fe00000 - 0x8fe4162b dyld 132.1 (???) <211AF0DD-42D9-79C8- BB6A-1F4BEEF4B4AB> /usr/lib/dyld 0xb8000000 - 0xb81defff +bracket 1.1 (59) <3E4E06B8-E1FC- B232-1371-643DC0FBE8C9> /Applications/_HDR/bracket.app/Contents/MacOS/ bracket 0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???) <068CC3F2-F867- A231-A16C-CC01C29A9816> /usr/lib/libSystem.B.dylib Translated Code Information: NO CRASH REPORT Model: MacBookPro3,1, BootROM MBP31.0070.B07, 2 processors, Intel Core 2 Duo, 2.4 GHz, 4 GB, SMC 1.16f11 Graphics: NVIDIA GeForce 8600M GT, GeForce 8600M GT, PCIe, 256 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x87), Atheros 5416: 2.0.19.4 Bluetooth: Version 2.2.0f18, 2 service, 1 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Network Service: Parallels Shared Networking Adapter, Ethernet, en2 Network Service: Parallels Host-Only Networking Adapter, Ethernet, en3 PCI Card: pci168c,24, sppci_othernetwork, PCI Slot 5 Serial ATA Device: FUJITSU MHW2160BHPL, 149.05 GB Parallel ATA Device: MATSHITADVD-R UJ-857E, 3.6 GB USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8502, 0xfd400000 USB Device: USB Reader, 0x05e3 (Genesys Logic, Inc.), 0x0710, 0xfa300000 USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x021a, 0x5d200000 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0x5d100000 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8205, 0x1a100000 FireWire Device: Passport III, WD, Up to 800 Mb/sec --------------------------------------------------------------- Will try tomorrow on a different system. Best, Christian Boch On Sep 1, 2009, at 7:47 PM, Oguz Akyuz wrote: > Hello, > > I just wanted to share with everyone in this mailing list that the > cross-platform HDRI application that I've been working on for quite > some time now is finally out. You can freely download it from: > > http://www.coolhall.com/homepage/bracket/bracket.html > > There is a possibility that the application might not be working on > Snow Leopard -- since I don't have a new enough mac to install that > beauty I could not try it myself. I've personally verified it to be > working on XP/Vista/Win7 for Windows, Tiger and Leopard for Mac, and > Ubuntu 9.04 and Suse 11.0 for Linux. > > I'm eager to hear your comments. Please contact me for any bug > reports, feature requests, or any thoughts and ideas. > > Best, > Oguz > > > _______________________________________________ > HDRI mailing list > HDRI@radiance-online.org > http://www.radiance-online.org/mailman/listinfo/hdri -------------- next part -------------- An HTML attachment was scrubbed... URL: http://radiance-online.org/pipermail/hdri/attachments/20090901/261082c7/attachment.html From oguzakyuz at gmail.com Wed Sep 2 07:14:05 2009 From: oguzakyuz at gmail.com (Oguz Akyuz) Date: Wed Sep 2 07:14:12 2009 Subject: [HDRI] bracket 1.0.0 (beta): cross platform HDRI application is out! Message-ID: <2e19d480909020714u62a5821dq57e96a70c6d2322b@mail.gmail.com> Hi Christian, Thanks for testing it on Snow Leopard. The crash dump seems to suggest that there could be a binary incompatibility between the dynamic libraries that comes with the system and the application itself. I'll try to get my hands on a snow leopard to get a better understanding of the problem. Best, Oguz Hi, Sounds very exciting. Thank you so much. Just tried it under Snow Leopard (with Rosetta installed), and it crashes right on launch. Even before any interface comes up. Here is the report: ---------------------------------------------------- Process: bracket [4459] Path: /Applications/_HDR/bracket.app/Contents/MacOS/bracket Identifier: bracket Version: ??? (???) Code Type: PPC (Translated) Parent Process: launchd [115] Date/Time: 2009-09-01 23:18:10.646 -0700 OS Version: Mac OS X 10.6 (10A432) Report Version: 6 Interval Since Last Report: 59031 sec Crashes Since Last Report: 4 Per-App Crashes Since Last Report: 3 Anonymous UUID: F31BE627-7228-4D61-9B44-087F0626EF5F Exception Type: EXC_CRASH (SIGTRAP) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x801bc82a __pthread_kill + 10 1 libSystem.B.dylib 0x801bc0d7 pthread_kill + 95 2 bracket 0xb80bfcb4 0xb8000000 + 785588 3 bracket 0xb80c01bb 0xb8000000 + 786875 4 bracket 0xb80dda6c 0xb8000000 + 907884 5 bracket 0xb814551b spin_lock_wrapper + 1791 6 bracket 0xb801d03b 0xb8000000 + 118843 Thread 1: 0 libSystem.B.dylib 0x800c58fa mach_msg_trap + 10 1 libSystem.B.dylib 0x800c6067 mach_msg + 68 2 bracket 0xb819448f CallPPCFunctionAtAddressInt + 206155 3 libSystem.B.dylib 0x800f2fe1 _pthread_start + 345 4 libSystem.B.dylib 0x800f2e66 thread_start + 34 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x8027c500 ecx: 0xb7fff9ac edx: 0x801bc82a edi: 0xb8211620 esi: 0x00000005 ebp: 0xb7fff9d8 esp: 0xb7fff9ac ss: 0x0000001f efl: 0x00000286 eip: 0x801bc82a cs: 0x00000007 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x8011f466 Binary Images: 0x80000000 - 0x8006afe7 libstdc++.6.dylib ??? (???) <411D87F4- B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib 0x800c5000 - 0x80269feb libSystem.B.dylib ??? (???) <068CC3F2-F867- A231-A16C-CC01C29A9816> /usr/lib/libSystem.B.dylib 0x802e9000 - 0x802ecfe7 libmathCommon.A.dylib ??? (???) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/ libmathCommon.A.dylib 0x8fe00000 - 0x8fe4162b dyld 132.1 (???) <211AF0DD-42D9-79C8- BB6A-1F4BEEF4B4AB> /usr/lib/dyld 0xb8000000 - 0xb81defff +bracket 1.1 (59) <3E4E06B8-E1FC- B232-1371-643DC0FBE8C9> /Applications/_HDR/bracket.app/Contents/MacOS/ bracket 0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???) <068CC3F2-F867- A231-A16C-CC01C29A9816> /usr/lib/libSystem.B.dylib Translated Code Information: NO CRASH REPORT Model: MacBookPro3,1, BootROM MBP31.0070.B07, 2 processors, Intel Core 2 Duo, 2.4 GHz, 4 GB, SMC 1.16f11 Graphics: NVIDIA GeForce 8600M GT, GeForce 8600M GT, PCIe, 256 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x87), Atheros 5416: 2.0.19.4 Bluetooth: Version 2.2.0f18, 2 service, 1 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Network Service: Parallels Shared Networking Adapter, Ethernet, en2 Network Service: Parallels Host-Only Networking Adapter, Ethernet, en3 PCI Card: pci168c,24, sppci_othernetwork, PCI Slot 5 Serial ATA Device: FUJITSU MHW2160BHPL, 149.05 GB Parallel ATA Device: MATSHITADVD-R UJ-857E, 3.6 GB USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8502, 0xfd400000 USB Device: USB Reader, 0x05e3 (Genesys Logic, Inc.), 0x0710, 0xfa300000 USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x021a, 0x5d200000 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0x5d100000 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8205, 0x1a100000 FireWire Device: Passport III, WD, Up to 800 Mb/sec --------------------------------------------------------------- Will try tomorrow on a different system. Best, Christian Boch On Sep 1, 2009, at 7:47 PM, Oguz Akyuz wrote: >* Hello, *>* *>* I just wanted to share with everyone in this mailing list that the *>* cross-platform HDRI application that I've been working on for quite *>* some time now is finally out. You can freely download it from: *>* *>* http://www.coolhall.com/homepage/bracket/bracket.html *>* *>* There is a possibility that the application might not be working on *>* Snow Leopard -- since I don't have a new enough mac to install that *>* beauty I could not try it myself. I've personally verified it to be *>* working on XP/Vista/Win7 for Windows, Tiger and Leopard for Mac, and *>* Ubuntu 9.04 and Suse 11.0 for Linux. *>* *>* I'm eager to hear your comments. Please contact me for any bug *>* reports, feature requests, or any thoughts and ideas. *>* *>* Best, *>* Oguz *>* *>* *>* _______________________________________________ *>* HDRI mailing list *>* HDRI at radiance-online.org *>* http://www.radiance-online.org/mailman/listinfo/hdri * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://radiance-online.org/pipermail/hdri/attachments/20090902/450b489a/attachment-0001.htm From vangelis54 at gmail.com Sat Sep 5 07:40:02 2009 From: vangelis54 at gmail.com (Evangelos Christakou) Date: Sat Sep 5 07:40:14 2009 Subject: [HDRI] bracket 1.0.0 (beta): cross platform HDRI application is out! In-Reply-To: <2e19d480909011947m4c035096q20eaa6b0eb768659@mail.gmail.com> References: <2e19d480909011947m4c035096q20eaa6b0eb768659@mail.gmail.com> Message-ID: Hi Orguz, A very exciting and interesting HDR application. Just tried it underUbuntu 9.04 and was a piece of cake! Thank you so much. vangelis On Tue, Sep 1, 2009 at 11:47 PM, Oguz Akyuz wrote: > Hello, > > I just wanted to share with everyone in this mailing list that the > cross-platform HDRI application that I've been working on for quite some > time now is finally out. You can freely download it from: > > http://www.coolhall.com/homepage/bracket/bracket.html > > There is a possibility that the application might not be working on Snow > Leopard -- since I don't have a new enough mac to install that beauty I > could not try it myself. I've personally verified it to be working on > XP/Vista/Win7 for Windows, Tiger and Leopard for Mac, and Ubuntu 9.04 and > Suse 11.0 for Linux. > > I'm eager to hear your comments. Please contact me for any bug reports, > feature requests, or any thoughts and ideas. > > Best, > Oguz > > > > _______________________________________________ > HDRI mailing list > HDRI@radiance-online.org > http://www.radiance-online.org/mailman/listinfo/hdri > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://radiance-online.org/pipermail/hdri/attachments/20090905/b2b409a4/attachment.html From oguzakyuz at gmail.com Sat Sep 5 14:30:01 2009 From: oguzakyuz at gmail.com (Oguz Akyuz) Date: Sat Sep 5 14:36:48 2009 Subject: [HDRI] bracket 1.0.0 (beta): cross platform HDRI application is out! In-Reply-To: References: <2e19d480909011947m4c035096q20eaa6b0eb768659@mail.gmail.com> Message-ID: <2e19d480909051430p26f36946gf5142ac3c08bd6c@mail.gmail.com> Hi Vangelis, Thanks for giving it a try. I'm glad that you find it easy to use. Please let me know if you have any comments including any bugs, things that you don't like and missing features. Best, Oguz On Sat, Sep 5, 2009 at 10:40 AM, Evangelos Christakou wrote: > Hi Orguz, > > A very exciting and interesting HDR application. > > Just tried it underUbuntu 9.04 and was a piece of cake! > > Thank you so much. > > vangelis > > > On Tue, Sep 1, 2009 at 11:47 PM, Oguz Akyuz wrote: > >> Hello, >> >> I just wanted to share with everyone in this mailing list that the >> cross-platform HDRI application that I've been working on for quite some >> time now is finally out. You can freely download it from: >> >> http://www.coolhall.com/homepage/bracket/bracket.html >> >> There is a possibility that the application might not be working on Snow >> Leopard -- since I don't have a new enough mac to install that beauty I >> could not try it myself. I've personally verified it to be working on >> XP/Vista/Win7 for Windows, Tiger and Leopard for Mac, and Ubuntu 9.04 and >> Suse 11.0 for Linux. >> >> I'm eager to hear your comments. Please contact me for any bug reports, >> feature requests, or any thoughts and ideas. >> >> Best, >> Oguz >> >> >> >> _______________________________________________ >> HDRI mailing list >> HDRI@radiance-online.org >> http://www.radiance-online.org/mailman/listinfo/hdri >> >> > > _______________________________________________ > HDRI mailing list > HDRI@radiance-online.org > http://www.radiance-online.org/mailman/listinfo/hdri > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://radiance-online.org/pipermail/hdri/attachments/20090905/091b52f5/attachment.html From alexkent at mac.com Tue Sep 8 12:45:39 2009 From: alexkent at mac.com (Alex Kent) Date: Tue Sep 8 13:35:36 2009 Subject: [Hdri] HDRI capture program for Canon EOS cameras under Mac OS X Message-ID: <3CCD5816-9CE0-45D9-A6EE-46425FDD1C94@mac.com> hi, i found this email address on a very old mailinglist relating to CanonHDRcap. are you still doing any work with the Canon EOS Sdk on Mac ? i'm working with it myself and as canon don't give support for it, i'm trying to locate other developers who are using it. regards, alex kent. ----------------------- +44 (0) 7866 718074 alexkent@mac.com http://www.alexkent.net From rviula at fosterandpartners.com Wed Sep 9 05:57:19 2009 From: rviula at fosterandpartners.com (Raquel Viula) Date: Wed Sep 9 05:57:26 2009 Subject: [HDRI] RGB values out of range Message-ID: <6DDAFE169F56CC40BA4030F500BFBAF7033880F0@corp3005.CORPORATE.FOSTER.NETWORK> Dear all, I was reading though webHDR's calibration page and it is mentioned that images should not have RGB values above 200 or below 20. I took a range of photographs of a series of daylit spaces and it looks like that for some series there isn't a single image without values either below or above those limits. In fact, quite often the same image has values both above and below There's indeed considerable contrast in my scenes, in some cases composed of dark corridors and rooflights. Some of them also have direct sunlight getting into the spaces. However, I'm surprised for not being able to get a single image within those limits from a range of 15 exposures. I used a Cannon EOS 20D and my White Balance was set to Daylight. Does anyone have the same experience of trying to make HDR images of (shall I call it) "extremely" daylit spaces and coming to the same problem? Is there a range of luminances that would deliver Does this mean that these images are not good to be converted to HDR? Also, would like to know if the above mentioned limits are general thresholds or just applicable to HDR images generated using hdrgen? Thanks in advance, Raquel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://radiance-online.org/pipermail/hdri/attachments/20090909/07c84d4e/attachment.htm From grobe at gmx.net Wed Sep 9 06:53:56 2009 From: grobe at gmx.net (Lars O. Grobe) Date: Wed Sep 9 06:54:18 2009 Subject: [HDRI] RGB values out of range In-Reply-To: <6DDAFE169F56CC40BA4030F500BFBAF7033880F0@corp3005.CORPORATE.FOSTER.NETWORK> References: <6DDAFE169F56CC40BA4030F500BFBAF7033880F0@corp3005.CORPORATE.FOSTER.NETWORK> Message-ID: <4AA7B374.3050904@gmx.net> Hi, I think there is a misunderstanding here. I am sure that the documentation you refer to is related to the source images. These are 8-bit coded, and allow values from 0-255. This means that below 20 and over 200 you get into the edges of this range. As the jpg's you get from a digital camera are not linear mappings from luminance to pixel values, and a slight change in these edge pixel values is related to a huge change in the luminance of the recorded scene, it gets impossible to reconstruct luminance values from such values. Have a look at the s-shaped response curve of your camera, it should explain this problem. So hdr tools can use only this "middle" range, and this means that you must make sure that the ranges of your overlap have a sufficient overlap. Also, of course, the darkest (shortest exposure time) image should not contain any very bright pixels, and the brightest one (longest exposure time) no very dark ones. So if e.g. your brightest image was taken with 1/2sec and has significant pixel values below 20, take one more with 1sec time. Cheers, Lars. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3740 bytes Desc: S/MIME Cryptographic Signature Url : http://radiance-online.org/pipermail/hdri/attachments/20090909/742bf68a/smime.bin From oguzakyuz at gmail.com Wed Sep 9 07:05:01 2009 From: oguzakyuz at gmail.com (Oguz Akyuz) Date: Wed Sep 9 07:05:27 2009 Subject: [HDRI] RGB values out of range In-Reply-To: <4AA7B374.3050904@gmx.net> References: <6DDAFE169F56CC40BA4030F500BFBAF7033880F0@corp3005.CORPORATE.FOSTER.NETWORK> <4AA7B374.3050904@gmx.net> Message-ID: <2e19d480909090705y4953f179x497416806cc59a86@mail.gmail.com> Hi Raquel, Generally agreeing with Lars, I would like to add that it should not be impossible to create a useful HDR image if the input exposures have RGB values greater than 200 or smaller than 20. Actually, as you pointed out it should be very difficult to capture bracketed sequences where any exposure fits into these limits. The HDR creation algorithms generally employ a weighting scheme to underplay the influence of over- and under-exposed pixels. This is usually a smooth function giving higher weights to midtones and lower weights to extreme darks and lights. I think any tool that employs such a weighting scheme should be able to cope with input images that have pixel values close to the edges of the RGB range. Cheers, Oguz On Wed, Sep 9, 2009 at 9:53 AM, Lars O. Grobe wrote: > Hi, > > I think there is a misunderstanding here. I am sure that the > documentation you refer to is related to the source images. These are > 8-bit coded, and allow values from 0-255. This means that below 20 and > over 200 you get into the edges of this range. As the jpg's you get from > a digital camera are not linear mappings from luminance to pixel values, > and a slight change in these edge pixel values is related to a huge > change in the luminance of the recorded scene, it gets impossible to > reconstruct luminance values from such values. Have a look at the > s-shaped response curve of your camera, it should explain this problem. > > So hdr tools can use only this "middle" range, and this means that you > must make sure that the ranges of your overlap have a sufficient > overlap. Also, of course, the darkest (shortest exposure time) image > should not contain any very bright pixels, and the brightest one > (longest exposure time) no very dark ones. So if e.g. your brightest > image was taken with 1/2sec and has significant pixel values below 20, > take one more with 1sec time. > > Cheers, Lars. > > _______________________________________________ > HDRI mailing list > HDRI@radiance-online.org > http://www.radiance-online.org/mailman/listinfo/hdri > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://radiance-online.org/pipermail/hdri/attachments/20090909/7ea0c56e/attachment.htm From jacobs.axel at gmail.com Wed Sep 9 14:31:40 2009 From: jacobs.axel at gmail.com (Axel Jacobs) Date: Wed Sep 9 14:27:26 2009 Subject: [HDRI] Re: RGB values out of range In-Reply-To: <4aa7fb68.8113f30a.6578.30aaSMTPIN_ADDED@mx.google.com> References: <4aa7fb68.8113f30a.6578.30aaSMTPIN_ADDED@mx.google.com> Message-ID: <4AA81EBC.8040704@gmail.com> Hi Raquel, >> I think there is a misunderstanding here. I am sure that the >> documentation you refer to is related to the source images. These are >> 8-bit coded, and allow values from 0-255. This means that below 20 and >> over 200 you get into the edges of this range. As the jpg's you get from >> a digital camera are not linear mappings from luminance to pixel values, >> and a slight change in these edge pixel values is related to a huge >> change in the luminance of the recorded scene, it gets impossible to >> reconstruct luminance values from such values. Have a look at the >> s-shaped response curve of your camera, it should explain this problem. >> >> So hdr tools can use only this "middle" range, and this means that you >> must make sure that the ranges of your overlap have a sufficient >> overlap. Also, of course, the darkest (shortest exposure time) image >> should not contain any very bright pixels, and the brightest one >> (longest exposure time) no very dark ones. So if e.g. your brightest >> image was taken with 1/2sec and has significant pixel values below 20, >> take one more with 1sec time. Lars is absolutely correct in what he is saying. WebHDR is mostly concerned with using HDR for (reasonably) reliable luminance measurements, so it's important that the entire dynamic range of the scene is captured in the photos. When you tone-map a scene with very bright lights (electric lighting fittings), then in theory you should be able to see details of those light sources: filaments in tungsten lamps, the uneven luminance of diffusers, mirror images of the lamps on the reflector etc. If, however, on the darkest image (shortest exposure), some or all parts of the bright sources are either over-exposed (they have a value of 255 in the JPEG), or even if they are above 200, then the HDR engine can't reliably work out the true luminance and will simply cut it off. In reality, the HDR stitcher will even produce an HDR image from JPEGs that have only slightly different exposures. It'll work, but will be useless for our particular application. If you use HDR for anything other than luminance measurement, and find that the results are visually pleasing, you may simply ignore this 20/200 rule. For a while, WebHDR did actually display the dynamic range of the HDR image (the more the better: I was even thinking about implementing an all-time highscore list!), but then decided to remove it. The lowest luminance values in an image (below desks, in dark corners) are too much affected by camera noise, so it didn't really say a lot about the quality of the HDR. So in a sense, the 200-rule is more important than the 20-rule, but depending on your application, feel free to ignore both. I actually don't remember where I got this 20/200 from, maybe Greg hinted at it in a message on this list, or I might have read it in the HDR book. I didn't make it up, though. Honestly! Regards Axel From rviula at fosterandpartners.com Thu Sep 10 05:10:29 2009 From: rviula at fosterandpartners.com (Raquel Viula) Date: Thu Sep 10 05:10:37 2009 Subject: [HDRI] Re: RGB values out of range References: <4aa7fb68.8113f30a.6578.30aaSMTPIN_ADDED@mx.google.com> <4AA81EBC.8040704@gmail.com> Message-ID: <6DDAFE169F56CC40BA4030F500BFBAF7033880F5@corp3005.CORPORATE.FOSTER.NETWORK> Hi Lars, Oguz,, Axel, Thanks for your emails. Yes, I intend to obtain luminance values from my HDRs, that the reason for asking and making sure I'm using the right range. It's all clear to me now. Thanks, Raquel -----Original Message----- From: hdri-bounces@radiance-online.org [mailto:hdri-bounces@radiance-online.org] On Behalf Of Axel Jacobs Sent: 09 September 2009 22:32 To: hdri@radiance-online.org Subject: [HDRI] Re: RGB values out of range Hi Raquel, >> I think there is a misunderstanding here. I am sure that the >> documentation you refer to is related to the source images. These are >> 8-bit coded, and allow values from 0-255. This means that below 20 and >> over 200 you get into the edges of this range. As the jpg's you get from >> a digital camera are not linear mappings from luminance to pixel values, >> and a slight change in these edge pixel values is related to a huge >> change in the luminance of the recorded scene, it gets impossible to >> reconstruct luminance values from such values. Have a look at the >> s-shaped response curve of your camera, it should explain this problem. >> >> So hdr tools can use only this "middle" range, and this means that you >> must make sure that the ranges of your overlap have a sufficient >> overlap. Also, of course, the darkest (shortest exposure time) image >> should not contain any very bright pixels, and the brightest one >> (longest exposure time) no very dark ones. So if e.g. your brightest >> image was taken with 1/2sec and has significant pixel values below 20, >> take one more with 1sec time. Lars is absolutely correct in what he is saying. WebHDR is mostly concerned with using HDR for (reasonably) reliable luminance measurements, so it's important that the entire dynamic range of the scene is captured in the photos. When you tone-map a scene with very bright lights (electric lighting fittings), then in theory you should be able to see details of those light sources: filaments in tungsten lamps, the uneven luminance of diffusers, mirror images of the lamps on the reflector etc. If, however, on the darkest image (shortest exposure), some or all parts of the bright sources are either over-exposed (they have a value of 255 in the JPEG), or even if they are above 200, then the HDR engine can't reliably work out the true luminance and will simply cut it off. In reality, the HDR stitcher will even produce an HDR image from JPEGs that have only slightly different exposures. It'll work, but will be useless for our particular application. If you use HDR for anything other than luminance measurement, and find that the results are visually pleasing, you may simply ignore this 20/200 rule. For a while, WebHDR did actually display the dynamic range of the HDR image (the more the better: I was even thinking about implementing an all-time highscore list!), but then decided to remove it. The lowest luminance values in an image (below desks, in dark corners) are too much affected by camera noise, so it didn't really say a lot about the quality of the HDR. So in a sense, the 200-rule is more important than the 20-rule, but depending on your application, feel free to ignore both. I actually don't remember where I got this 20/200 from, maybe Greg hinted at it in a message on this list, or I might have read it in the HDR book. I didn't make it up, though. Honestly! Regards Axel _______________________________________________ HDRI mailing list HDRI@radiance-online.org http://www.radiance-online.org/mailman/listinfo/hdri