A bit slow about hdr-plus HOT 16 CLOSED

Hi. I made it only compile and did not spend more time into it. For me it outputs a black and white img. Thats caused by the black whitelvl substraction. Whitelvl is in my case to high and must get calculated depending on the bit depth. Im also not sure if the demosaic part works correct with the hardcoded matrix. Im currently fighting with gradle to get it building with the android plugin. Gradle can be a beast

from hdr-plus.

do you find a way to speed up the code? @ghost

from hdr-plus.

the problem is that each time halide compile the hdrpipe.
once compiled as lib it can get reused and is fast.
here is sample how to compile it. you have to change some funcs to accept imageparam.

Big thanks @timothybrooks, FreeDcam love it ;D

from hdr-plus.

@KillerInk It looks like you took over maintenance of FreeDcam from the original author?

I'm definitely going to take a look at your HDR+ enhancement work in further detail when I get back from vacation. Using libraw appeared to be necessary for you to handle DNGs, but it's really beneficial for Sony E-mount users too because dcraw truncates ARW2s from 14 bits down to 12 on load. :(

I'd love to figure out a way to implement subpixel alignment. Also - I've found that for mirrorless cameras (probably doesn't apply to bursts on Android devices), there can be enough shift between frames that a 32 pixel block size with +/-8 pixel search works significantly better in many cases.

from hdr-plus.

yes i took it over.
I made no big changes to the algo itself. i just made it rdy for aot compile.
but its also lazy progress. halide use only one core for aot building -_-
currently im trying to move it into generator building.

i was not aware that dcraw scales down the bit depth. my problem with dcraw started earlier caused due wrong encoding.

there is not much difference between android rawdata and sonys.
android data is more noise and have smaller size.
but both are problematic if the rawdata is not vignette corrected.

i dont think the algo needs a subpixel alginment, the results are very impressive.
more important for me would be to apply a wiener filter to rawdata and correct vignette from opcode.

from hdr-plus.

dcraw scaling down the bit depth is specific to Sony ARW2 loading - it doesn't affect other cameras.

And yeah - this HDR+ algorithm is severely limited by the lack of distortion and vignetting correction, that's pretty important if you have a Sony 24-105G. I don't think there's a good way to fix this without reworking alignment and merging to occur after demosaicing.

Subpixel alignment or the ability to correct for camera rotation are definitely needed - the HDR+ results I've gotten are extremely poor compared to using Hugin's align_image_stack, at least for the global scene. HDR+ does better at eliminating ghosting from subject movement, but lack of subpixel alignment
or rotation correction (not sure which) leads to everything being slightly blurry. I'll post some comparisons when I get back from vacation. Lack of CA correction may also be a contributor, but individual frames are far sharper than the merged result.

from hdr-plus.

i also dont know how to algin merge after demosaic. also it makes not much sense because the align merge part remove alot noise.
the raw input can get treated as black and white image. due that its possible to remove vignette bevor align and merge.
with removing vignette after demosaic its already to late and burned into the rawdata and the provided opcode does nolonger match. also with increased opcode factors its not possible.
i noticed it with my 200mm lens and full zoom. on a singel frame the edges gets real dark but contains color. with stacking more frames the color gets removed and it turns to black.

about the sharpness of the aligned and merged images, i figured out thats i caused by the factor that get applied while merging.

30frames stacked (note: its only algined and merged by the algo. demosaic and tonemap did not get applied and its cropped 500x)

singel frame

from hdr-plus.

Hi @KillerInk, i have compiled static libs for Android app follow your repo, but the state RawToRgb seems to be not work, the rgb output data is null.
Do you have any solutions?

from hdr-plus.

Hi @KillerInk, i was make RawToRgb stage to work, but it have a problem.
Without tone_map apply in finish, result:
https://imgur.com/xvCx5x8

With tone_map was applied:
https://imgur.com/xvCx5x8

Do you have any solutions?

from hdr-plus.

@hiepgaf
Looks like links are the same.
but the image looks a bit purple. so its probably the whitebalance/tint.

what changes have you made?

from hdr-plus.

@KillerInk
Please check this Link

I was use libraw to read whiteblance, white point and blackpoint instead of use custom matrix.

from hdr-plus.

@hiepgaf would say that the compression is to high or the gain lvl to low.
that are the only two factors that affecting it.

from hdr-plus.

@KillerInk I have tried some modify with gain and compression values but nothing change.
When i run on PC with same gain and compression value, the result seem OK.
https://imgur.com/a/LeCjmAH

Reference image: https://photos.google.com/share/AF1QipPhjjwGoqPszXw6YwZSgqSfyz23d0KT-KuQrKkivhvKIkGeAn6jb8OjSB_dnGQD8g/photo/AF1QipNTlrHapAZR5TLFY2YXrkKsWX9rw4CSd04qYTiy?key=MFZnZUF6NnhlSXotNkxmdzNuX2hoS25vUTRnUzNR

I don't know how different when run on PC and AOT on Android.

from hdr-plus.

@hiepgaf normaly they should produce a simliar output.
i dont know how your pipeline looks like.
i think on pc you have one pipeline rawstack + rawtorgb. and on android you have it splittet.
if thats the case try it on android as one pipe.

from hdr-plus.

@KillerInk In PC my pipeline is only rawtorgb ;(

from hdr-plus.

Closing the issue as discussion seems to have veered from algorithm speed. Feel free to reopen specifically for runtime improvements.

from hdr-plus.