Messages

Probably the most reasonable way to interpret that "tip" would be "tip at the time of writing". That is, link translation should be done considering the date of the post containing that link.

Otherwise, replacing it with "unified" could also work.

The problem I see with those links is the lack of branch information. I mean, with a link like  https://bitbucket.org/hudson/magic-lantern/src/tip/modules/dual_iso/cr2hdr.c, how do we know which branch it's pointing at? Can we safely assume it's for the default branch "unified"?

Well, I'v been having a look to all the bitbucket.org links I could find in a quick search, and I saw the following patterns:

• Branches. Those links have the format https://bitbucket.org/hudson/magic-lantern/commits/branch/(branch name), and they translate to https://foss.heptapod.net/magic-lantern/magic-lantern/-/tree/branch/(branch name).
  
• Issues in the bug tracker. They have the format https://bitbucket.org/hudson/magic-lantern/issues/(issue number)/(title of the issue), and they translate to https://foss.heptapod.net/magic-lantern/magic-lantern/-/issues/(issue number)
  
• Commit IDs. They have the format https://bitbucket.org/hudson/magic-lantern/commits/(commit ID). We'll leave these for later, as we need the git-mapfile.
  
• Pointers to a file in a given commit. For example: https://bitbucket.org/hudson/magic-lantern/src/d318f774b24ecc7d533ab79dd9418d097442fd81/src/raw.c#lines-905. We'll leave these for later too.
  

And now there are some URLs where I don't know very well what to do with them:

• Links to a given file. In Bitbucket they were like this: https://bitbucket.org/hudson/magic-lantern/src/tip/modules/dual_iso/cr2hdr.c (for example). The problem is that the Heptapod link includes the branch information in it: https://foss.heptapod.net/magic-lantern/magic-lantern/-/blob/branch/unified/modules/dual_iso/cr2hdr.c, so I don't know where to get it from in the Bitbucket links.
  
• Links from repos created by other developers. For example: https://bitbucket.org/Dannephoto/switch_mini-git/src/master/, http://bitbucket.org/coutts/1000d_dev/src/default/, etc. Have they all been ported to Heptapod?
  

Wow, I haven't been on IRC in many years, and I still have to figure out Discord. I don't know if I'm a dinosaur or not enough of one... 

So we would have to hack the forum code then, I guess. Should I just download the code from Simple Machines and start hacking at it, or do you guys have installed any custom mods in this forum? I can also start making a "map" of URLs from the old repo and their correspondences in the new one, as time permits.

(If you need to discuss any details privately, just send me a message here for the moment, until I've figured out Discord...)

Okay, let's separate this into two problems: the "normal" links to Bitbucket and the links to specific commit IDs.

Pretty much, yes. However, I'd prefer a "soft" replacement, when displaying the forum posts, rather than permanently altering the forum database. There's plenty of room for making non-obvious mistakes (that could be noticed months after the change).

If you don't want to touch the forum DB itself, the solution would be to add a HTTP redirection somewhere. But the problem is that, since all the links still point to the bitbucket.org domain, either you convince the Bitbucket guys to add that redirection for you, or you'll still have to touch the forum posts, if only to point them to your own redirector.

What I mean is: you'll have to edit all the links so that they point to "myownbitbucket.org" (for example),  and add in that domain a server that would take into account all the different paths and redirect the user transparently to the appropiate URL. We'd still be editing the forum posts, but only to change the domain part (from bitbucket.org to myownbitbucket.org or whatever); the rest of the URL, which is where the "danger" lies, would be rewritten in the new redirect server. Does that sound good to you, or is it too convoluted? (I could handle the redirect server).

As for the commit IDs, my impression after reading this thread is that the simplest solution would be to ask the Heptapod people for a copy of the git-mapfile. Am I mistaken, or is that a static file that doesn't change anymore? (I mean: the new commits are done directly into the Heptapod server, right? They don't have any corresponding commits in Bitbucket). Either that, or reverse engineer how Heptapod generates the new commit IDs...

Thanks - for those who didn't get the joke, it means somebody still has to sit down and perform the work

Which is exactly the problem I'm trying to solve with Open Collective.

Excuse me if I'm missing something, but if I'm not mistaken, the tasks you mentioned above (rewriting all the links in the forum to go from Bitbucket to Heptapod) seem pretty much trivial, right? It's just a matter of loading the SQL dump of this forum and doing a search/replace. (the commit IDs are a different matter, admittedly).

I am asking this because I've long wanted to give some help to this project, after using it for so many years, but I have no experience with the kind of low level programming that you guys need, so when I read this, it sounded like something so easy that even *I* could do it...

(As for migrating the commit IDs, that might be above my skill level, but also: I've been looking around in the forum and the website, but haven't been able to find any link to specific commit IDs in Bitbucket. Do you have an example? )

Erm... let's see how I explain this.

Last December my EOS550D got bricked, don't know why. I sent it to Canon's tech support, and they returned it with firmware 1.1.0 installed. Obviously, I couldn't keep using the official build anymore, so I downloaded dfort's unofficial build. I was going to test it exahustively, but then got busy with work... and then 2020 happened and had to focus on other stuff.

Now I might finally have some free time over the holidays, so I thought I'd get a stab at this project again, but I'm finding myself wondering: has there been any updates to this unofficial build during this year? Or am I good testing the build I downloaded one year ago?

Incidentally: why isn't that build available anymore? Did dfort decide to take it offline, or did Bitbucket close the account? I know that it's trivially easy to get download space and a free git repo these days, but still, if you need something in that regard and I can be of help, just ask and I'll see what I can do.

Hello!

I just saw that dmilligan ported the deflickering script to Lightroom. My question is: is there any advantage in running it instead of using the Bridge version? The main one I can think of would be speed: is the Lua engine in Lightroom multithreaded? (Watching the deflickering script using just one core in my CPU gets kinda old...)

Actually, now that I've thought about it, there is a very simple solution. Since I only need LiveView to check the framing, and the exposure will be controlled by AutoETTR using QR data, I just disabled ExpSim in ML... and it seems to work.



Amazing how one can remain oblivious to the simplest solution in front of one's eyes.

Thanks, I see what you mean. I guess I didn't remember that AutoETTR was on during LiveView too.

I have tried using FPS override, but if the shutter gets too low (like 0.5 sec. or so), it will pretty much make the screen unusable, since it will refresh it at whatever frame rate gets calculated from the shutter, i.e., 0.5fps or so.

Hello:

Yesterday I was trying to make a sunset hyperlapse using AutoETTR and the advanced intervalometer when something really odd happened. First of all, my data:

  -I'm using a Canon EOS 550D.
  -I'm using a ML build from March 15 2014 (yes, I know, it's old, but I've been using it forever and it has always worked great, so I'd like to know what exactly went wrong before upgrading).
  -My AutoETTR parameters were: Exposure target at -1EV, Midtone SNR limit at 4, Shadows SNR limit at 2, Hightlight ignore at 0.1%, Allow clipping is Off.

Before starting with the time-lapse, I tried taking a couple of test pictures to allow AutoETTR to find the right exposure. I turned on LiveView (because I needed to see the framing for the hyperlapse), and the ISO set itself to 3200 (because it was dark). I took a pic, it came out overexposed (because it was dark, but the street lights were on) and AutoETTR said "the next picture will be taken at 1/2 ISO 100"... but the ISO stayed at 3200. I took another picture, and it came out again at ISO 3200... and of course, it was also overexposed.

I tried changing ISO by hand, but the camera didn't let me. Every time I changed the ISO, it set itself again to 3200, and AutoETTR didn't seem able to change it either. After doing several tests, it looked like:

  -If I turned off LiveView, both AutoETTR and me could change ISO without problems.
  -If I turned off exposure simulation, ISO could also be changed... but AutoETTR needs ExpSim on. (I should mention, BTW, that the Canon "ExpSim" warning was flashing all the time).
  -If I turned off AutoETTR, I also could change ISO.

Thinking now about it, I guess the reason I had never noticed this before is because I had always done day-to-night timelapses, so when I started them, there was always enough light for ExpSim to work properly. Yesterday I started the hyperlapse when it was already pretty dark.

My question is: what was forcing ISO to be at 3200? Was it ExpSim or AutoETTR, or were they interfering with each other? And what can I do in similar circumstances, when I do need LiveView on?

What platform are you on? PC or Mac?

If it's Mac, you should be using Prores HQ. If it's PC... it's complicated, but I've been using Cineform 10-bit and I've been getting good results.

anius: have you tried Cineform? It can go up to 10 bits, and from my experience it seems to be okay.

PaulJBis:  Thanks for answering my questions.  While we were talking about staccato, I was shocked that you said your interval was anywhere from 15 seconds to 30 seconds throughout a single timelapse.

No, that's not what I said. I said that I normally use intervals of 30 sec. or 1 min., but what I do NOT do is to change interval times within a single timelapse. If I start with a 30 sec. interval, I stick to it until the end.

Edit: or, in other words, what dmilligan said.

As for the "undo" feature I added:

I noticed that after I installed the latest version of the script, but I am not sure how to use that really. Maybe Paul can chime in to explain it to me?

Basically, before you perform any operation using the script (deflicker, ramp values...), it will automatically save the current state of all the XMP attributes in all your selected pictures into a "set", which is represented by the menu entry in the Undo dropdown. When you later select an option in that dropdown, the script takes all those XMP attributes and loads them again into your pictures, erasing whatever modification you just made (that is, "undoing" it). Basically, it's like the "Backup XMP sidecars" feature, except you don't have to manually admin several sets of XMP files.

There can also be several options in the dropdown, representing several undo levels. Basically, I wrote this to behave pretty much like the undo feature in After Effects, Photoshop, etc. (Of course, there can be bugs  ).

Hi, Joachim.

First, let me say thank for those two links. I am not sure how exactly the info in the second link can be translated to the recent version of ACR. The problem is that when the sliders are at zero the image is far away from beeing linear. The problem was discussed by Christian Bloch here aswell. I assume the settings he recommends approximate a linear gamma pretty well tough. Writing this post I would think that one should be able to find out pretty close what settings create a linear gamma on PV2012 with Photoshop and the colour picker when comparing the same image processed with PV2010.

Sorry for not replying sooner; I've been out of the loop lately, and yesterday I spent half an hour fighting with the forum software trying to quote automatically your message  . Anyway, you are right: the problem is that the "linear" curve in PV2012 isn't really linear, due to the magic that Adobe added to extract more detail from the highlights (I found a thread in Adobe's forums discussing this months ago, but can't find it right now).

I don't know about trying to reverse-enginner whatever Adobe has done in PV2012, but it seems easier to me to just keep using PV2010 for the shots we take specifically for timelapses, which is why I added that option to dmilligan's script.

The feature has been temporarily removed due to abuse (people quoting first/last posts, or really long messages).

There is an insert quote feature still available, you'll find it after hitting reply.

Sure, but if the post I'm replying to is really old, it won't show up in the list of posts (the "Topic Summary") in the Reply page.

Oh well.

I had replied to tetsusaiga privately, but for the benefit of any newbies, I'll repost here what I wrote to him about what ETTR is, with a bit of expansion:

Basically, and to summarize: digital sensors have more noise in the shadows; therefore, in order to avoid noise, you overexpose your shots as much as possible (without clipping), so that most of your picture is in the brighter side of the histogram (the right). If you prefer the picture darker, you can always darken it later (because you are shooting RAW). That's what ETTR is.

What is AutoETTR? Well, it's a module that calculates automatically what's the highest exposure you can make in any given picture without clipping the highlights. What's considered an "acceptable" amount of clipping? That's what all those parameters and buttons are for, to tune that to your preference.

Why is AutoETTR relevant to day-to-night timelapses? Because in these, the exposure changes with time, and you don't know in advance what the right exposure will be (unless you stay all day and night with a light meter and write down the values for each hour before your shoot ). So you use AutoETTR and let it expose for you.

Will this cause flicker, when AutoETTR changes ISO or shutter? Well, yes, but then you just have to deflicker later using dmilligan's script.

Hope this solves any doubts.

Hi all:

Sorry if this is just me being dense, but I've just spent half an hour looking for a way to reply and quote from a message in the previous page (i.e., one so old that doesn't show up in the "Topic summary" in the Reply page). The SMF manual says:

http://wiki.simplemachines.org/smf/Posting/

"There are two ways of replying to a post by quoting it. The first option is to click on the Quote button on the top right-hand side of the relevant post."

But I'm not seeing any "Quote" button here, on any post.

I wouldn't normally post for something so basic, but as I said, I've been looking for half an hour.

(Of course, I could just copy and paste and quote manually, but I want the link to the older post).

[PaulJBis:]

PaulJBis:  You said in your post above that you "just finished another sunset timelapse using AutoETTR, and at the end (when it was dark), it blew my highlights to the point that now I can't recover them in post. Thus, I'd like to know if there's a way to ramp EV so that, at the end of the timelapse, the software aims for a different value than at the beginning."

When you say "ramp EV exposure," are you talking about the "Exposure target" parameter in AutoETTR? How have your sunset/sunrise timelapses come along so far with AutoETTR? I'm trying to learn all that I can so any help or tips would be appreciated.

In the context of that post, I didn't mean the "Exposure target" parameter that you can set in AutoETTR. I meant the internal EV target that AutoETTR sets when it performs its calculations.

BTW; I've been out of the loop, shooting timelapses (among many other things). Will try to catch up tonight and see if there's been anything interesting.

dmilligan: I just sent you a git pull request. If you have any doubts, feel free to ask.

Thanks for getting back so quick. I can't see any difference in the images - or any sign of xmp files.

Try entering Camera Raw's preferences and setting it to "save image settings" in sidecar XMP files.

The script might tell you that it needs more iterations, but do the results look acceptable to you? I've had cases where the script said so, but I still liked the results.

As for your question, the script works using the metadata stored in the XMP sidecars. You might have to configure your system so that it stores the metadata there, instead of in the file itself (I don't remember right now what Bridge does with JPEG files).

Okay. I'll have to learn to use git and open a github account first then... 

I've modified the script to add a few things that I needed:

-The ability to ramp parameters from process 2010, instead of process 2012.

-The ability, likewise, to deflicker using the exposure value for process 2010, and the ability to save the deflickering data (the EV values) to an external file.

-I've also implemented an Undo stack. It's a new menu command: when you select it, it gives you the chance to undo the last few ramp/deflickers you've done, without having to back up the XMP files. (I should note: this feature currently works, but it has a few inconsistencies that I'd like to iron out).

@dmilligan: are you interested in merging these changes? How should I send them to you?

Hello again.

I'm starting to do some work to adapt the script to my workflow, which involves grading the RAW files to be as flat as possible and importing them into AE in order to do all the color correction there. This implies, among other things, using process 2010 for the RAW files... but also implies using a completely linear tone curve and zeroing out all the enhancements in Camera Raw (Brightness, Contrast, etc.).

I asked you a while ago whether the deflicker algorithm would work too in process 2010, and you mentioned that it wouldn't make much difference... but what about using PV2010 *and* the linear curve? (Note that, unlike in process 2012, the "linear curve" in PV2010 is really linear, at least AFAIK). Your current formula for calculating EV values is:

Code Select Expand

    (2 / log(2)) * log(value)

Would it serve equally for a linear curve?