Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 52

Thread: New utility by Jeff Conrad: Sun/Moon calculator

  1. #41

    Join Date
    Apr 2004
    Location
    SF Bay Area, California, USA
    Posts
    331

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    I don’t provide times for nautical or astronomical twilight, because they’re usually not relevant to terrestrial photography—at the end of evening civil twilight, it’s mighty dark. There are perhaps a few exceptions, such as very thin crescent moons and astrophotography, but I tried to show what’s needed most of the time while minimizing the clutter.

    I’ve had many—mainly individual—requests for all manner of things; had they all been incorporated, it would be almost impossible to find the stuff that most people want. And the results wouldn’t fit on the page. Showing all twilight times is certainly one of the more reasonable requests. These times are easy to calculate, and I suppose it wouldn’t be that difficult to control using yet another user preference, but there already so many of those that I’ve gotten a few complaints ... In any event, it’s not currently high on the list. I’ve put most of the effort into the search features, because quite honestly, applications that just give Sun and Moon times are a dime a dozen. I do agree that with many sites (such as the USNO), you need to make a handful of calls to get all the data you need. I’ve never tried to do this with the USNO using GETs, so I can’t offer much comment.

    For what you’re trying to do, TPE obviously isn’t the solution. And at least for now, the Web app is far behind the iOS app in capability. I also agree that sunrisesunset.com probably isn’t the ideal solution. Have you tried the API for timeanddate.com? Of course, I don’t know what they hit you for once the trial period expires.

    It’s interesting that you’re calculating sky luminance, which can be a big issue when trying to catch the Moon without resorting to a composite exposure. I’ve long tried to do it using the CIE method (ISO 15469) but have had trouble finding a way to calculate zenith luminance at solar altitudes less than zero. How do you handle this?

    Anyway, let me see what I can do.

  2. #42

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    I undestand your point, Jeff. I didn't tried TimeAndDate API. I'm building my Rainmeter "skin" so that I could share this once it's finished (aka publish it on a site like DeviantArt or Customize.org). Using TimeAndDate API could be enough if it was only me that we're talking about (and even then, I don't know if they allow parameters or they still do it exclusively by Javascript, like they do for the main site), but I envision a "skin" that could be potentially used by other Rainmeter users, as well.

    Quote Originally Posted by Jeff Conrad
    It’s interesting that you’re calculating sky luminance, which can be a big issue when trying to catch the Moon without resorting to a composite exposure. I’ve long tried to do it using the CIE method (ISO 15469) but have had trouble finding a way to calculate zenith luminance at solar altitudes less than zero. How do you handle this?
    Oh no, I'm not using that type of calculations - I'm not that much of an expert. I thought about it though, got some info about it and stuff, but decided it was best (and enough) to keep it very simple. My method is quite straightforward...although it may seem complicated after reading below :P...

    1) I set a "day begin" time variable (which used to be 00:00 in 24h time, but it logically should be = sun transit time - 12 hours, OR, if sun transit time isn't available, = the middle night time point between astronomical twilights/nautical twilights/civil twilights/sunrise-sunset). This is essentially the absolute middle of the night. For example, if sun transit time is 13:10, then the "day begin" would be 01:10. If sun transit time isn't available (at high latitudes in certain months, for example), but I have let's say the astronomical twilights of 02:34 and 22:40, then the "day begin" would be the middle night point between them, which is 00:37.

    2) I set a "day end" time variable (which used to be 24:00 in 24h time, but it logically should be = sun transit time + 12 hours, OR, if sun transit time isn't available, = the middle night time point between the next astronomical twilights/nautical twilights/civil twilights/sunrise-sunset). This is essentially the absolute middle of the next night. The calculation is similar to the "day begin" variable, except it's 24 h later.

    3) Now I have all the points in time during a 24h day when the sky brightness rates are changing (aka when the sky brightness is changing slower or faster): "day begin", morning astronomical twilight, morning nautical twilight, morning civil twilight, sunrise, sun transit, sunset, evening civil twilight, evening nautical twilight, evening astronomical twilight and "day end".

    4) I then assign predetermined values of "brightness" to each one of the above events ("tint points" like I use in my skin - see section "ImageTint" here to understand how brightness is simulated by "tinting" an image). By trial and error I noticed the following are decent aproximates, at least for my latitude and season (the values vary between 0 and 255, obviously, as they are color related variables):

    day begin tint point = 30 (not completely black, but a little fuzzy "light": stars, moon, etc.)
    morning astronomical twilight tint point = 40 (a little brighter than full night, but still dark)
    morning nautical twilight tint point = 50 (a little brighter than astronomical twilight, but still dark)
    morning civil twilight tint point = 60 (a little brighter than nautical twilight, but still dark enough)
    sunrise tint point = 160 (this is when the light gets really intense, aka night is becoming day)
    sun transit tint point = 255 (full sun luminance, as it's the moment when the sun is at its highest point in the sky)
    sunset tint point = 160 (same as sunrise)
    evening civil twilight tint point = 60 (same as the opposite twilight)
    evening nautical twilight tint point = 50 (same as the opposite twilight)
    evening astronomical twilight tint point = 40 (same as the opposite twilight)
    "day end" tint point = 30 (same as day begin)

    5) Now I calculate the number of minutes between the consecutive points in time during a 24h day when the sky brightness rates are changing, which were listed at 3) (e.g. the number of minutes between "day begin" and "morning astronomical twilight", then the number of minutes between "morning astronomical twilight" and "morning nautical twilight" and so on, until the "day end"). These are necessary for calculations later, at 6).

    6) I then calculate the "tint steps", which are defined as "how much does brightness (or tint) change per minute" for the different intervals of the day.

    The formula is : Interval Tint Step = (Tint Point of the End of the Interval - Tint Point of the Start of the Interval) / Number of Minutes of the Interval
    For example, the "morning civil twilight tint step" = (sunrise tint point - morning civil twilight tint point) / number of minutes of morning civil twilight =
    = (160 - 60) / number of minutes of morning civil twilight.

    Note : The number of minutes of morning civil twilight is essentially the time difference in minutes betwen morning civil twilight and sunrise.

    These "tint steps" are used later in calculating the final tint (brightness) that should be applied to the image of the sky. Bear in mind that because, for example, "evening civil twilight tint point" < "sunset tint point" (60<160), the "tint step" for evening civil twilight will be negative, thus allowing me to "decrease" the brightness in the second part of the day (the part after the sun transit time) in the final calculations below.

    7) Finally, I calculate the final brightness/tint that I apply to the sky image:

    Tint Color (aka Brightness) = Tint point of the start of the interval I'm in + (Current time - Start of the interval time I'm in) x "Tint step" of the interval I'm in

    Note : the (Current time - Start of the interval time) are all measured in minutes.

    For example, the formula for calculating the brightness while during the "morning civil twilight"<--->"sunrise" interval would be
    Tint Color (aka Brightness) = morning civil twilight tint point + (current time - morning civil twilight time) x "morning civil twilight tint step"

    Practical example :
    In the case of San Francisco on 22 June 2015, your utility gives 05:17 as the dawn (aka morning civil twilight) time and 05:48 as the sunrise time. Let's say the current time is 05:37. We have:

    Number of minutes between "morning civil twilight" and sunrise (determined in step 5)) = 05:48 - 05:17 = 31 minutes
    Morning civil twilight tint step (determined in step 6)) = (sunrise tint point - morning civil twilight tint point) / number of minutes of morning civil twilight =
    = (160 - 60) / 31 = 100 / 31 = 3.23
    Brightness (determined in step 7)) = morning civil twilight tint point + (current time - morning civil twilight time) x "morning civil twilight tint step" =
    = 60 + (05:37-05:17) x 3.23 = 60 + 20 x 3.23 = 60 + 64.52 = 124.52

    So I'll apply a brightness of 124.52 to the image of the sky if the current time is 05:37. The formula gets recalculated every minute. When going past the sunrise, it gets more radically recalculated, as I enter a different day interval : the one between the sunrise and the sun transit time. So the number of minutes at step 5) changes, and so does the "tint step" at step 6), making the final brightness to change at a different rate per minute compared to the previous interval. The algorithm is applied for the subsequent intervals as well. As I said at step 6), when going past sun transit time, the "tint step" will become negative, as the "tint points" (aka brigthness points) for the end of the intervals are lower then the "tint points" for the start of the same intervals, so when perfoming the subtraction at step 6) I get negative values. This allows the general formula at step 7) to gradually decrease the brightness that's applied to the image of the sky, therefore simulating the coming of the sunset/twilights/night.

    Now I'm aware my method is by no means bullet proof, but for my conditions it does its job more than well. The tint point are only approximations and I'm aware that sunrise tint point value should be closer to sun transit tint point value or that the final formula should probably be logarithmic instead of linear, as it is now. I also realize the formula may not be perfectly appropriate for higher latitudes than mine, but that could easily be corrected by multiplying the tint point values with a latitude related variable. The same goes for seasons : if the winter days are, as I suspect, "darker" than the summer days, a similar correction could be enforced. The effect of weather (mainly clouds) on sky brigthness isn't really a concern, at least in what I need to accomplish, as the sky image would be mostly covered by clouds image when this happens, anyway. Calculating sky brightness then would be of no use, because the user would see only a little portion of the sky (which keeps its brightness if we take the clouds/shadows out of the equation).

    As for "calculating zenith luminance at solar altitudes less than zero", well, I told you I'm no expert - I'm not sure what you mean by that. If you could try to shortly explain it in a less technical way, it would help.

    Hope I could provide a different perspective on the answer you were probably expecting. I guess I anticipated those difficulties when getting info on the "professional method" of calculating sky luminance, otherwise I would have taken that path myself, probably.

    P.S. Sorry for the long post.

  3. #43

    Join Date
    Apr 2004
    Location
    SF Bay Area, California, USA
    Posts
    331

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    Quote Originally Posted by Yincognyto View Post
    As for "calculating zenith luminance at solar altitudes less than zero", well, I told you I'm no expert - I'm not sure what you mean by that. If you could try to shortly explain it in a less technical way, it would help.
    The CIE method for determining sky luminance distribution is based on the luminance of the sky at the zenith. Although the formulas for this luminance vs. Sun altitude are quite simple, the formulas I’ve found are limited to times when the Sun is above the horizon. It’s possible, of course, that the CIE method doesn’t work when the Sun is below the horizon, anyway.

    I think the CIE formula is pretty long in the tooth, so there well may be better methods available now. I just haven’t found one ...

    I’ve long wondered when someone would provide a VR application that accurately represents the luminance and color of the twilight sky—Google Earth is an interesting start, but it’s definitely not there yet. Someone else well may have done it. But twilight is pretty tricky; as far as I know, the definitive treatise is still Georgii Rozenberg’s 1966 book.

    As it turns out, adding a parameter to suppress the Sun/Moon Calculator’s main form wasn’t the difficult. Nor was adding an option to show astronomical and nautical twilight. The devil is always in the details, of course—including updates to the documentation and making sure that something isn’t inadvertently broken. I hope to have a beta posted in a day or so.

  4. #44

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    Quote Originally Posted by Jeff Conrad
    As it turns out, adding a parameter to suppress the Sun/Moon Calculator’s main form wasn’t the difficult. Nor was adding an option to show astronomical and nautical twilight. The devil is always in the details, of course—including updates to the documentation and making sure that something isn’t inadvertently broken. I hope to have a beta posted in a day or so.
    Wow, that's fantastic! Can't wait to test it (and hopefully use it in my weather skin)! Thank you!

  5. #45

    Join Date
    Apr 2004
    Location
    SF Bay Area, California, USA
    Posts
    331

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    Adding a parameter to suppress the Sun/Moon Calculator’s main form was straightforward, but setting things up so that a GET would produce readily captured output is not, mainly because of the way client-side JavaScript works nowadays. Capture might still be possible with IE 8, but I would not wish that browser on anyone—especially for use with the Sun/Moon Calculator, because the JavaScript performance is politely described as abysmal. So—at least for now—it isn’t happening.

    I did add the ability to show the times of astronomical and nautical twilight, as well as a few other features. The release version is now posted.

  6. #46

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    Quote Originally Posted by Jeff Conrad View Post
    I did add the ability to show the times of astronomical and nautical twilight, as well as a few other features. The release version is now posted.
    I just tried the Sun/Moon Calculator and it's exactly as it was before (that is, no astronomical and nautical twilights - aka the "old version"). Maybe I tried too soon? Or does this require an additional parameter?

  7. #47

    Join Date
    Apr 2004
    Location
    SF Bay Area, California, USA
    Posts
    331

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    It’s a user preference that needs to be set manually. It’s sticky, though, so at the next invocation with parameters, the additional times should be displayed. The new version clears any previously set preferences on first loading, so if any were set to other than default, they need to be set again. But it should be a one-time procedure.

  8. #48

    Join Date
    Apr 2004
    Location
    SF Bay Area, California, USA
    Posts
    331

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    It’s arguably messy to have to manually set options for a programmatic invocation. I’ve added parameters to set several User Preferences at invocation; they have the same effect as setting these options on the User Preferences form, so they’re retained across invocations. Give tw=a to show all twilight times.

    The new parameters represent only a small fraction of the available User Preference options, but the others are arguably less important for programmatic invocation. Moreover, I suspect the number of people who use the parameter interface can easily be counted on both hands.
    Last edited by Jeff Conrad; 19-Jul-2015 at 01:32. Reason: spelling

  9. #49
    Alan Klein's Avatar
    Join Date
    Jun 2015
    Location
    New Jersey was NYC
    Posts
    2,580

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    Jeff: I've been using TPE on my Samsung Galaxy S4 for awhile now. What advantages with yours? Thanks.

  10. #50

    Join Date
    Apr 2004
    Location
    SF Bay Area, California, USA
    Posts
    331

    Re: New utility by Jeff Conrad: Sun/Moon calculator

    Alan,

    There may not be an advantage. But the only version of TPE that I’ve used is the desktop app (both old and new), so it’s tough to give a solid answer.

    It looks to me as if the Android app is missing a number of the features on the TPE for iOS 3, but to be honest, I’m not that familiar with the Android version—all I know is in the introductory video. I don’t know what is planned for the Android app.

    Currency
    The first thing I would observe is that the Sun/Moon Calculator is very much a legacy application, which should be evident from the layout. It’s had some significant updates since 1998, but it makes no attempt to function as a mobile app. I’ve actually never tried it, but doubt I would be impressed. So if you want to use it on your phone, I think it’s an easy decision. I prefer to do planning on a larger canvas, but perhaps I’m just a legacy user.

    Map Integration
    Next, the Sun/Moon Calculator doesn’t integrate the Sun and Moon data with the map. You can open the TPE desktop app or the Sun/Moon Calculator’s Az/Alt Tool to the calculator’s current location but it’s an extra step. And there is no synchronization between the calculator and either of the other apps. Depending on how you work, this may or may not be an issue.

    Depending on what you do, using a map at some point would seem almost unavoidable, so TPE has the advantage of being map-centric. I’ve used digital maps (National Geographic TOPO!) since early 1997, when Google Maps and TPE were years in the future. But TOPO! is long defunct (a sad story ...), so it’s no longer an option. And with TPE and my Az/Alt Tool, you get the ability to get the altitude to a feature as well as the azimuth and distance—an essential capability if you want to align the Sun or Moon with a feature. Most other programs just weren’t written for photographers.

    Features in the Sun/Moon Calculator
    If the video represents all that’s available on the Android app, the Sun/Moon Calculator does have one notable additional feature: the ability to find dates on which the Sun or Moon is within a certain range of azimuth and altitude. If you do this sort of thing, it’s a big advantage; if you don’t, it’s of no value.

    Features in TPE for iOS 3
    The iOS 3 version of TPE seems to have several features not available for Android, including

    1. The ability to find dates on which the Sun or Moon is in a certain position. It’s somewhat different from my date search; mine is more flexible, but more work to set up, as many have told me ...
    2. The ability to adjust elevation data that are suspect (digital elevation models are a work in progress), and the ability to specify the height above ground of man-made structures. The latter is especially handy if you want to align the Sun or Moon with a building.

    And the iOS version seems to be very nicely implemented—you might want to look at some of the video tutorials—they might even make you want a new iPhone or iPad ...

    So I’m not sure there’s a good answer to your question—it’s very much a matter of personal preference and the type of photography you do. TPE is a great app, so you’re already pretty well covered.
    Last edited by Jeff Conrad; 20-Jul-2015 at 22:10. Reason: Fixed confusing sentence

Similar Threads

  1. Is there any real utility to ULF?
    By Tom Hieb in forum Cameras - ULF (Ultra Large Format) and Accessories
    Replies: 271
    Last Post: 21-Sep-2023, 03:01
  2. New articles by Jeff Conrad on DoF
    By QT Luong in forum Feedback
    Replies: 27
    Last Post: 5-Jan-2022, 06:56
  3. New article by Jeff Conrad: Introduction to DOF
    By QT Luong in forum Feedback
    Replies: 10
    Last Post: 7-Mar-2005, 23:37
  4. Steve Grimes'"Utility Sinar Lens Boards"
    By Robert J. Triffin in forum Lenses & Lens Accessories
    Replies: 0
    Last Post: 9-Nov-2001, 08:46
  5. Arca Brainbox utility?
    By Steve Singleton in forum Gear
    Replies: 17
    Last Post: 27-Apr-2000, 01:49

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •