BuildHdr doesn't work for stack images other than those present in the ~/demos/stack folder about hdr_toolbox HOT 6 CLOSED

Thank you for using the HDR Toolbox.

The reason why you are getting this error is because the sequence that you are using does not have EXIF files. ReadLDRStackInfo is meant for JPEG images, which have exif information.
If you unzip the original memorial church sequence you will find a "readme.txt" file and "memorial.hdr_image_list.txt" file. The latter file has for each image the exposure value that you need to feed to BuildHDR.m in order to build an HDR image.

I hope this helps.

PS: If you want to use RAW, there is another function that needs to be used "ReadRAWStackInfo.m"

PPS: I updated the HDR Toolbox with improvements for BuildHDR. I advice you to use the "devel" branch for fresh updates.

from hdr_toolbox.

Perfect thanks @banterle !!!

Though, I forgot to mention that in my original post, I had converted the .png files to .jpg files, but i guess the morgify command doesn't add the exif information while making this conversion.

Hence I tried using the exposure times from the .txt file as suggested by you, but there seems problem with the CRF function generated particularly for the red channel : https://1drv.ms/i/s!AirqHCcUuZaErVu3gGPGJF3gtYBv.
Here is the tone mapped hdr image : https://1drv.ms/i/s!AirqHCcUuZaErVzptOgD_84FGyeB.

PS: These results are from the master branch.

Rgds,

Praveer

from hdr_toolbox.

You are welcome.

I forgot to add the default sub-sampler for the stack (Grossberg+Nayar), which is quite robust. Please update the toolbox and let me know how it is.

NOTE1: When you tested it, DebevecCRF used spatial subsampling that requires many samples to obtain high quality results.

NOTE2: The input stack that you are using is not ideal. In fact, it has many blue blocks (due to alignment, my guess), which bias the final result. In theory, you should crop the stack to remove those blue areas.

from hdr_toolbox.

Hey @banterle,

Firstly thanks for your comments and sorry about my delayed response.

I am a bit confused with how and when do you update your master and develop branch. What do you mean by "fresh updates" ; if the updates are compatible enough, why don't you straight away merge them to the master branch ?

Regarding NOTE 1, you mean DebevecCRF in the master branch no longer uses spatial sub-sampling now and uses the Grossberg sampling that is CDF based right ?

For NOTE2: You are right, it might actually be due to alignment that we have blue blocks in certain exposure images. I guess simply cropping won't help, I might also need to align them afterwards.

Basically I want to implement virtual photographs generation for some HDR images (with unknown LDR stack), and I felt it would be a good idea to use a standard and quite popular Debevic dataset for CRF computation which can then be used for virtual photograph generation. I presumed that CRF derived from larger number of exposure stack would be effectively more easily generalized and can model larger variants of HDR images. However looking from the stack, it doesn't seem ideal enough for my task. Do you think using your available input stack of 7 LDR images to compute CRF can solve my problem at hand ?

Rgds,

Praveer

from hdr_toolbox.

Firstly thanks for your comments and sorry about my delayed response.

you are welcome.

I am a bit confused with how and when do you update your master and develop branch. What do you mean by "fresh updates" ; if the updates are compatible enough, why don't you straight away merge them to the master branch ?

I understand your confusion, this was an important fix so I decided to push it asap. From now on, I will try to have only two stable releases per year.

Regarding NOTE 1, you mean DebevecCRF in the master branch no longer uses spatial sub-sampling now and uses the Grossberg sampling that is CDF based right ?

Correct.

For NOTE2: You are right, it might actually be due to alignment that we have blue blocks in certain exposure images. I guess simply cropping won't help, I might also need to align them afterwards.

This is valid only for computing the CRF, the stack is fine for merging.

Basically I want to implement virtual photographs generation for some HDR images (with unknown LDR stack), and I felt it would be a good idea to use a standard and quite popular Debevic dataset for CRF computation which can then be used for virtual photograph generation. I presumed that CRF derived from larger number of exposure stack would be effectively more easily generalized and can model larger variants of HDR images. However looking from the stack, it doesn't seem ideal enough for my task. Do you think using your available input stack of 7 LDR images to compute CRF can solve my problem at hand

Remember that a CRF depends on the camera that shot a stack of photographs, every camera has a different one. Furthermore, you can find slightly different CRFs amongst cameras of the same model.

from hdr_toolbox.

This is valid only for computing the CRF, the stack is fine for merging.

You mean what I proposed, i.e. to also align them ? (So far I am only interested in computing CRF's, no exposure fusion).

Remember that a CRF depends on the camera that shot a stack of photographs, every camera has a different one. Furthermore, you can find slightly different CRFs amongst cameras of the same model.

Totally agreed. But if I lack both the CRF and the stack of LDR's for each of my HDR, I don't see any other way of deriving the CRF for the HDR's in order to compute their virtual photographs. Moreover if I am not wrong, CRF's to generate virtual photographs need not be the same as used to construct the original HDR's.

from hdr_toolbox.