Ask Your Question
0

HDR Merge process called without the the response arg

asked 2019-01-14 01:21:40 -0500

dgalland gravatar image

updated 2019-01-17 11:56:02 -0500

I try in Python the example of the "memorial". There are two possibilities to call the merge: 1. Calibrate the response on images and times and use to use it for the merge 2. Do the merge directly on images and times I do not get the same result. The image created by 2 is correct and the image created by 2 bad Do I make some mistake ? Regards

calibrate = cv.createCalibrateDebevec()
response = calibrate.process(images, times)
merge_debevec = cv.createMergeDebevec()
#hdr = merge_debevec.process(images, times, response) #Bad
hdr = merge_debevec.process(images, times) #Good
tonemap = cv.createTonemapReinhard()
ldr = tonemap.process(hdr)
cv.imwrite('ldr.png', ldr * 255)
cv.imwrite('hdr.hdr', hdr)
edit retag flag offensive close merge delete

Comments

There is something missing parameter. I had same code as your dating back in 2017.

calibrate = cv.createCalibrateDebevec()
response = calibrate.process(images, times)
merge_debevec = cv.createMergeDebevec()
hdr = merge_debevec.process(images, times, response) 
tonemap = cv.createTonemapReinhard(1.5, 0,0,0)
ldr = tonemap.process(hdr)
cv.imwrite('ldr.png', ldr * 255)
cv.imwrite('hdr.hdr', hdr)
supra56 gravatar imagesupra56 ( 2019-01-15 07:30:42 -0500 )edit
1

Thanks for answering.and your code

merge_debevec = cv.createMergeDebevec()
hdr = merge_debevec.process(images, times, response) 
tonemap = cv.createTonemapReinhard(1.5, 0,0,0)

works but the default value for the third parameter 1 (light_adapt) gives a very bad result. This explains my result, With 0 as in your code the result is good.

In some examples that I have found people call directly merge without the precalculated response. What this does and what we get is not very clear, In my case the result is better ! Very strange.

dgalland gravatar imagedgalland ( 2019-01-16 05:57:43 -0500 )edit
1

I am really confused with MergeDebevec ! In my case calling process without the third arg response gives me a better result. This method is referenced in the doc and many use it. But impossible to know what is actually done in this case.

dgalland gravatar imagedgalland ( 2019-01-17 11:23:46 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
1

answered 2019-01-17 11:55:07 -0500

dgalland gravatar image

updated 2019-01-18 03:08:32 -0500

After looking at the code it appears that the function MergeDebevec :: process called without the third argument response uses a linear response function. I was able to reproduce this by creating a linear answer as the third argument, the result is the same. I think the documentation should make it clear. What is strange is that in my case the result is better than calibrating the response of the camera!

    c=np.arange(256).astype(np.float32)
    linear=np.zeros((256,1,3)).astype(np.float32)
    linear[:,0,0] = c
    linear[:,0,1] = c
    linear[:,0,2] = c
    linear[0,:,:] = linear[1,:,:]
    merge_debevec = cv.createMergeDebevec()
    hdr_1 = merge_debevec.process(images, times, linear)

Gives the same result as:

hdr_2 = merge_debevec.process(images, times)
edit flag offensive delete link more

Comments

Does is working right now?

supra56 gravatar imagesupra56 ( 2019-01-17 20:07:50 -0500 )edit

Thank you for following my reflection. More or less ! I understood what the process call does without the response argument: use a linear response (this should be mentioned in the documentation!). However normally a merge HDR must take into account the actual response of the camera. What I do not understand is why with my images the linear answer gives a better result. I suspect that the gamma of the JPEG images that I receive from the camera have been corrected (without knowing the value) and therefore that does not reflect the response of the camera ??

dgalland gravatar imagedgalland ( 2019-01-18 03:07:46 -0500 )edit
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2019-01-14 01:21:40 -0500

Seen: 41 times

Last updated: Jan 18