Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Joachim Buambeki

#51
Quote from: dmilligan on September 22, 2013, 11:33:50 PMIMO after effects needs a way to keyframe ACR settings, that would be freakin awesome (also very useful for RAW video)
Quote from: dmilligan on September 23, 2013, 03:32:28 PM... I might be able to write a script for AE that makes ramping ACR settings easier. I know that the script API for AE has some pretty good integration with the native AE GUI, but I'm not that familiar with the AE scripting..
Did you find time to look into this? Beeing able to do everything within After Effects would be revolutionary!
#52
Just discovered this. Great work (again) David.

A few questions:

- Can you ramp values based on keyframes (frames that are marked with 1 star)? For a sunset one would pick 6 frames for example, adjust WB, exposure, shadows, highlights, colours, etc. and let your script ramp ALL sliders you can access within ACR including the curves? That would be MUCH easier than the current dialogue because you could use ACR dialog itself and see what you are actually doing.

- If that is possible, could you also animate/ramp the graduated and radial filter? They are useful for sunsets and/or when you have a dolly shot or want to track a subject like the milky way.

- Could you add a small dialogue to create those keyframes where you enter how many of them you want and they are evenly distributed evenly over the sequence then?

- Can you detect sudden changes in shutter speed with the script? Since you can't bulb ramp with Nikon cameras you have to adjust the shutter speed in steps of x EV (depending on how fine you want the steps to be) from day to night and then smooth those transitions, could you automate that? Those frames could be marked with 2 stars for the first and 3 stars the second of each pair.

- If the keyframing is possible, can you take care that those keyframes aren't changed by the deflickering algorithm? Meaning the exposure of those stays untouched and the surrounding frames are adjusted accordingly.

- If the keyframing is possible, what happens if I change the keyframes after the deflickering? Do I have to run those multiple passes again or could the offset for each frame be stored and be adjusted to those .xmp values of the keyframes?

- How robust is the deflickering? What if there are headlights from a car in a single frame, will the exposure of this frame be lowered because of its higher overall brightness? If it works that way and since you can access the small bridge preview image, could you add threshold that discards sudden local changes in brightness as flickering? Black birds in the sky or a fly one the lens would be another example where the deflickering algorithm might be thrown off.

- Could you implement a dialogue to raise/lower exposure of the sequence of after it has been colour corrected and deflickered? I often find the overall sequence a tad to dark/bright after reviewing the whole sequence and want to raise/lower the overal exposure.


Keep up the good work, it is really appreciated. :-)
#53
Isn't EXR native? I know there is the ProEXR plugin, but you only need that if have files with alpha, depth, whatever masks in it if I am not mistaken.

Thanks for the lossless option, unfortunatelly the savings aren't huge (~20%), maybe you could have a look a look at the other compression options aswell. 24bit Logluv and the the 16bit option (however that works) should be fine for HDRIs derived from photos without a visible loss in quality. For EXR I strongly recommend to implement lossy compression, you can save quite a good amount of space without visibly degrading the image.
I can send you more info on compression and file types if you need it, that stuff is just too much above my head to explain it properly.

Regarding the UI:
I would suggest to have different dropdowns:
File type: TIFF, EXR, JPEG, PSD
Compression: JPEG Q1-12 (you might reduce that to 6-11 to keep the dropdown compact, who uses the other values anyway?), NONE, LZW, ZIP, 24bit logluv, 16bit half, ZLIB, WAVELET, RLE, PXR24, (options not available for the chosen file format should be greyed out if possible)
Bit depth: 8, 16, 32 (options not available for the chosen file format should be greyed out if possible)

If you can/want implement the lowres proxies with user defined resolution, I would split the JPEG part from the rest and make that separate paragraph in the UI add checkboxes for both paragraphs to enable/disable them.
Since you can use Camera Raw as a filter even for 32bit Images since PS CC, you could also use that to tonemap the images instead of the HDRmerge Pro toning Options (which I personally don't like) and use the XMLs you talked about earlier. When using it as a filter, generating a second image as Proxy should be easy within the scripting laguage if I am not mistaken.
#54
I just updated my post above while you replied. Please have another look at it again
#55
The latest version works fine for me aswell. Maybe the layout could be optimised further, but that can be done later.
Hiding the toning part is fine with me if it can't be made collapsible.

I wasn't aware about the fact that you *can* get linear data out of ACR - cool finding. I am sure this will be useful somewhere else.

I am not sure if Blochi is wrong, I suppose what he does with those specific settings is that he creates TIFFs with LR/ACR and heads over to another application to merge them to an HDRI file - if that is the case using those settings is very likely better than using the defaults - he probably isn't aware of the fact that you can get linear images out of ACR.
I invited him to comment on this and opened new a thread about this script over at his small community  - maybe people over there have more ideas to improve/extend it even further.

Could you please have a look at the compression settings? Those TIFFs are terribly huge, I guess the script saves them without any compression, right? Maybe adding another dialogue in your script to set up different compression parameters might be a good idea.

Also, adding EXR to the output options might be another good idea, since that is the defacto standard for HDRIs AFAIK.


PS: While browsing around I found this - not sure if you are aware of it or if it is of any use (I can't use it in my version of CC, but maybe you have a look at the code) you, but I thought I might drop the link in here.

PPS: Why didn't you copy the more the detailed instructions you posted on the Adobe forums to the opening post here aswell? Just curious...
#56
Thanks for the updated script, everything works now as it should!

Regarding the nonlinear corrections:
It is a problem that occurs if you use use more than the exposure slider and curves, see this thread and what one of the Adobe developer says:

Quote from: MadManChan2000Some (many) controls in the Basic panel in PV 2012 are now image-adaptive.  They use the image content itself to determine the range and behavior of the controls.  Highlights, Shadows, and Clarity are among the controls that respond most strongly to the image content.  These were not designed with temporal coherence in mind.  This is why you can expect to see temporal artifacts if you are to try to apply these controls to individual still frames.

For basic tone effects, I would suggest instead using the Parametric and/or Point curves to minimize temporal issues.

So depending on image content you get flicker - beeing severe or not (maybe even invisible).


Regarding the UI of the script:
- I would suggest to move the "Deghosting" up and next to the "Alligning" checkbox because it has nothing to do with the toning part.
- Would it be possible to add an automatic filtering for image files, so one doesn't have to type in *.CR2/NEF or whatever the file format is that you want to process? Knowing me, I would forget that filter in 1 of 5 cases... :-/
- Could the toning part be made collapsible?
- Can I set new defaults? If not, where can I change the defaults to TIFF/32bit output in the script?

Did you look into reading the metadata to get lens correction right before the merging process? I would also avoid sharpening before the merging because AFAIK that also can cause artifacts (Blochi also recommends to turn it off).
What do you think about creating 8bit AND 32 output at the same time? Or is that not possible within the architecture of the merger? It would be nice to have a tonemapped lowres (maybe 1920*1280) file ready after the merging to render out a preview quickly - rendering the fullres 32bit TIFFs in After Effects with ACR takes veeery long as you surely know.

The reason why I am interested to have direct DNG output is the following:
LRtimelapse (which I use extensively) is reading the embedded Jpegs in a RAW or DNG file to do the deflicker, so, to get it to work you need a Jpeg file.
This would save me the another manual step by having to go through Bridge or the DNG converter.
Anyway, it is your script and I am really happy you wrote it!
#57
Quote from: Steven Griffith on October 14, 2013, 10:30:04 PMI've only just heard about the flickering issues with ACR (not a videographer). Does anyone know what causes it?
AFAIK that is a problem that occurs if you use use more than the exposure slider and curves, see this thread and what one of the Adobe developer says:

Quote from: MadManChan2000Some (many) controls in the Basic panel in PV 2012 are now image-adaptive.  They use the image content itself to determine the range and behavior of the controls.  Highlights, Shadows, and Clarity are among the controls that respond most strongly to the image content.  These were not designed with temporal coherence in mind.  This is why you can expect to see temporal artifacts if you are to try to apply these controls to individual still frames.

For basic tone effects, I would suggest instead using the Parametric and/or Point curves to minimize temporal issues.

So depending on image content you get flicker - beeing severe or not (maybe even invisible).
#58
Quote from: Muf on October 14, 2013, 06:46:31 PMCorrect me if I'm wrong, but isn't that exactly what jossef is describing? ML just can't do it because you can't prevent the physical shutter from triggering.
If I am not mistaken he is talking about reading out the sensor while it is still collecting photons, I would be surprised if you can do that with the existing hardware (if it is possible at all?!).
#59
I am still learning to work with log, but shouldn't you alter the output before heading over to something like Resolve?
If I understood it correctly, log is a curve that is applied to the linear data, if that is the case the grading suite expects that kind of input to make the grading tools work in an optimal way I suppose. If you alter that you kinda screw up the worklflow, don't you?

Could you elaborate on that Steve? I would really appreciate that.

PS: I just bought the M31 LUT to support your work and as an appreciation for giving away the log profile for free. I encourage everyone else that appreciate this profile to do the same.
Looking forward to see more Nikon cameras added. :-)
#60
Great work guys!

How to use it exaclty, is it best to leave everything at default? When moving any of the tonality control sliders the output isn't true log anymore, right? So I guess apart from white balance one should touch anything except the detail and lens correction tab I suppose.

Thanks for making it free!
#61
Quote from: Muf on October 14, 2013, 01:09:21 PM
It sounds like you're describing HDRx. So, it's definitely possible, but unlikely in the context of ML given the software limitations of Canons.
HDRx takes two exposures like every other camera, with its electronical shutter it is just possible to take them with no time inbetween at all - which makes joining the two exposures much easier (optical flow interpolation to match parts of the image that moved do the rest).
#62
Yes, the goal is to use ACR to process the endresult. I know that there is way to call the Adobe DNG converter from another programm, because that is what LRtimelapse does. The option to create those those DNGs directly would be just a big timesaver, also have can get a preview of the tonemapped file embedded into the DNG, which is not only nice for browsing those files in Bridge or another programm but also good for processing the files in LRtimelapse (it does only work on Jpeg instead of linear data, so having those JPEGs would actually help to improve the final output).

About LR vs ACR:
Sometimes people don't know what they are talking about. ;-)

As I said, with the settings shown above applied you get (something pretty close to) linear output, to goal is definitely to send files to the merger that have as little nonlinear processing applied as possible. I haven't made any conclusive tests, but I guess that introduces some sort of local flickering, because if you only have three nonlinear files to merge, there is a certain amount of guessing while reconstructing the linear files - which is totally fine for a single image - but it might result in flicker in certain tonal ranges (as Audionut pointed out) that are hard to impossible to remove for a deflicker tool since they only work best if the flicker is global.
There is also a similar phenomenon that I discussed with John Hable a while back: In the shots with the fastest shutter speed you get flicker because the shutter isn't 100% precise at speeds faster than 33ms (on Canon), though that problem seems to be less severe on Nikon than Canon. If you're interested in this google for "shutter flicker".

The reason why I don't want to use something else than ACR to create the intermediate files is the overall quality of the output, there is very little artifacting, jagged edges and other stuff compared to other converters. Apart from that, creating intermediate TIFF files with another programm would be a huge pain the butt.

PS: If I understood you correctly you weren't aware that you could tone your HDRIs in ACR, maybe you want to have a look at this, instead of using the HDR toning of HDRmerge Pro  (which is not that great IMO) you could call ACR for the 8/16bit files created with your script. If you do that it would be nice to have an option to render both 32bit and 8/16bit to be able to create a fast preview clip directly after the TIFF/DNG creation is finished.
#63
Thanks for your fast reply David!

Quote from: dmilligan on October 13, 2013, 08:59:09 PM
1. You should be able to select 32bit tiff, you have to select tiff first then the bit depth should become enabled (it's disabled for jpeg b/c jpeg only supports 8bit).   If you select 32 bit, the tone mapping will not be applied, the images will simply be merged into 32bit float.
After selecting TIFF as output both compression and bit depth are greyed out (the first one makes sense of course)

Quote2. No, not possible
You mean DNG is not possible, right? AFAIK you can call the DNG converter from Adobe so I thought it should be possible to feed it with those (intermediate) 32bit TIFF files. If that works, proxy creation should also be doable if I am not mistaken.

Quote3. Also not possible, photoshop cannot operate on CFA (raw undebayered) data directly, and there's no way and no reason to try to undebayer it once you've processed it. (This is why you get the ACR dialog when you try to open a RAW image, it has to be debayered into 3 channel RGB before photoshop can work with it).
I am not sure what you mean by that, but if you probably understood me wrong:
The DNGs created from 32 bit TIFF files are not CFA data, they are just an 32bit float file in a convenient DNG container (meaning the data has been debayered before the merging).

Quote4. I'll see what I can do, you can always just preprocess them with bridge first into 16 bit tiff. BTW, that article is about Lr, afaik Lr and ACR are not the same and operate differently, so IDK if the stuff in the article is applicable to this situation. I've never had an issue with losing highlight detail in HDRs, that article doesn't make much sense to me either. "mushed" is not exactly a very mathematical explanation. You can always assign more DR to the highlights with a curve if you feel they are too compressed.
Though "mushed" is indeed not a very mathematical term, that guy one of THE authorities for HDRI, I am surprised you haven't heard of him.
LR and ACR use the same RAW conversion engine so their output is identical - meaning what the writes is also applicable to ACR. Though I am a technical layman it makes perfect sense to me what he says:
When using the default ACR settings you basically apply an s-curve to the image (it not that simple actually, because contrast affects the midtones more than the highlights/shadows of the image, see also here), so apart from the camera curve itself (sensors aren't perfectly linear as you know) the HDR merger has figure out how to reverse that midtone contrast that is applied. In PV2010 you could linearise an image by setting everything to zero, when you convert those values to PV2012 you get the following:
-1 EV
-33 Contrast
+25 Blacks
a slight reverse s-curve

Which is pretty similar to what he is suggesting (I am also not sure not accurate that conversion from PV2010 to PV2012 by ACR is, because a few test I did myself brought me to the conclusion it might be not).
Converting the sequence to TIFF with lens corrections applied first and then using your script is certainly doable, but that another manual step I would love to avoid. ;-)

Since I can't test the TIFF option:
Are the TIFF files compressed in any (lossless/lossy) way to save space? If no, would you consider implementing it?
#64
Great work David.
I would love to see this developed further - not beeing able to batch HDRI creation with Bridge and PS creation also annoyed the hell out of me...

A few questions:
- How to output 32bit TIFF files? I can choose .tiff as output, but the option to choose bitdepth is stuck at 8 bit and greyed out. I am using PS CC on Win8.
- Would it be possible to get 32bit DNG files by sending the TIFF files internally to the Adobe DNG converter? If yes, the option the create lossy, lower res proxies would be great
- When processing RAW files the .xmp sidecard files seem to be ignored, could your script take them into account?
I am asking because the default settings are not optimal for HDR image creation (see here), also I would like to remove CAs and lens distortion in that step aswell.


Thanks again for your effort!
JB
#65
Quote from: Kabuto1138 on August 16, 2013, 07:34:15 AM
Darn, it looks like a great profile, but I get flicker with this profile.

AFAIK that is a problem that is inherent to any profile that uses more than exposure and curves, see this thread and what one of the Adobe developer says:

Quote from: MadManChan2000Some (many) controls in the Basic panel in PV 2012 are now image-adaptive.  They use the image content itself to determine the range and behavior of the controls.  Highlights, Shadows, and Clarity are among the controls that respond most strongly to the image content.  These were not designed with temporal coherence in mind.  This is why you can expect to see temporal artifacts if you are to try to apply these controls to individual still frames.

For basic tone effects, I would suggest instead using the Parametric and/or Point curves to minimize temporal issues.
So depending on image content you get flicker - beeing severe or not (maybe even invisible).
#66
Raw Video / Re: Turn your RAW footage into LOG
July 17, 2013, 11:38:14 PM
Hey guys, thanks for the input so far. I am still looking for a way to get "real" log footage out ACR - it can't be that hard.
If I understand it correctly log is just a gamma curve, so with the the other developments settings set to linear (see my other post in this thread) one should have log footage with the appropriate curve in ACR, right?
With my timelapse footage I am getting terrible results with those presets posted, If I use the linear preset and the Cineon "linear to log" converter it's much better though not as good as I would like to have it.

Cheers!
#67
Quotespecifies from which sensor row/col the video frame was copied (8x2 blocks)
Does that mean this data can be used later to apply *correct* lens correction in any RAW converter that supports it (ACR, Dxo, P1, etc)?
It would be tremendously useful to have that info stored in the .mlv file to use lens profiles for any sensor crop, even though it might needs to be padded with white/black image data to use regular lens profiles (which won't cost any extra bits if lossless compression is used with a DNG converter, right?).
Looking forward to that. :-)
#68
Raw Video / Re: Turn your RAW footage into LOG
July 07, 2013, 07:29:50 PM
Thanks for the reply tihon.
Is there a reason why you have a medium instead of a linear curve in the preset?
From what I was able to gather "Contrast" works more on the midtones so you you're maybe better off by using the linear curve and raise "Contrast" again a bit?
#69
Raw Video / Re: Turn your RAW footage into LOG
July 07, 2013, 03:46:50 PM
Thanks for posting. You can open this with ACR7/8 aswell, and then keep it in PV2010 or convert it into PV2012 for smoother highlight rolloff (and therefore a tad more dynamic range.

Quote from: tihon on July 07, 2013, 01:19:17 PM
tihon MLraw-to-blackmagick_film(log)  ACR 6.6 preset

I create this preset in Camera Raw 6.6, don't know how it works in other versions.

http://yadi.sk/d/gZzLvG3g6ZTTq - xml preset file
How did you derive those specific settings? Did you just match it by eye or is there a certain math behind it?
It definatelly looks log-ish but is it really true log? I am not saying that its worse than true log, I am just curious how to get "real" log out of ACR (if your preset isn't of course).

Maybe you could comment on my post above aswell. Thanks!
#70
Raw Video / Re: Turn your RAW footage into LOG
July 07, 2013, 09:26:57 AM
Hi,

I tried to convert my RAW files to log in ACR already before the whole RAW video craze but haven't really been successful, hopefully someone that understands that log business a bit better will figure it out...

If I understand correctly log is derived from linear sensor data, right?
If so, one would have to get the image to linear first and then apply a log curve, right?
Since PV2012 is as far as one can be from anything close to linear I decided to use PV2010 as a starting point because you can get a linear result out of ACR if you do the following (according to this):

- choose PV2010 in the "camera calibration" tab
- set white balance
- set Blacks, Brightness and Contrast to zero
- choose a linear curve in "curves" tab
- Enable CA removal (optional but recommended)
- set sharpness to Zero (optional)

->Convert back to PV2012 by clicking on the exclamation mark in the lower right corner.
-> save as Preset (optional but highly recommended to save time ;-)

Et voilĂ  we (should) have (almost) linear data that still has the pretty highlight rolloff from PV2012.
If one could explain what a log curve exactly is, that curve could be applied to PV2010 before its gets converted to PV2012.
#71
Latest version is crashing on my Win8 64bit machine because of insufficient disk space, I haven't checked older versions but I suspect them to behave in the same way.
Maybe you could add an error message and/or a check if the needed space is available on the volume?

Keep up the good work chmee!
#72
Another idea would be to have the data moved to the SD card in the background while not recording.
This way one could use a lower capacity (=cheaper) superfast CF card for shooting and cheap 64Gb SD cards for internal offloading between takes.
Additionally the splitted files could be merged during the offloading process (though this might be an even more programming intensive task than just splitting them up).
#73
Quote from: a1ex on June 09, 2013, 06:50:39 PM
Is it worth the extra hassle (programming complexity + workflow) for a 20% improvement in write speed?
If those 20% make the difference between beeing able to get the desired framerate (1080p30 for example) or the desired resolution (1920x1280@ 24fps for example) and not beeing able to get it, then yes it's totally worth it. Beeing able to overcrank to maybe 33fps for a 24p base shot would be a welcome addition.

Using a SSD (that hasn't even surfaced as a prototype) would not only hinder portability but almost double the cost of a ready to shoot rig (5D3+2cards+lens vs 5D3+cage/rails+battery-mount+battery+SSD-mount+SSD), using card splitting in ML  costs nothing extra (buying an extra SD card maybe...) so I don't see the time spent to develop it beeing wasted.
#74
Quote from: DANewman on June 07, 2013, 08:56:50 PMReally Adobe should be supporting native CineForm RAW, as then we wouldn't be having this discussion.

Adobe has apparently ZERO interest in doing that. Maybe you (as someone whose word might have some weight) could jump in to help those guys understand (good luck!).
Even if they do, it will most likely take like three iterations from now on (starting at the upcoming CC) to get it implemented... :-(
#75
Hi,

for flicker-free timelapse one has to shoot either wide open or has to press the DOF preview button and then unlock the lens to keep the aperture locked.
If shooting a timelapse without the above, the aperture will close and open with each image, this leads to flicker because the aperture is not 100% accurate (which is not relevant or visible for photography - I am talking about ~0.05EV).

Is there a way to keep the aperture locked while shooting timelapse?

Thanks for listening!

PS: Great new place this is. :)