Apple Event: May 7th at 7 am PT

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Sort by time of day, regardless of date

Is there any way to sort the Images in the Browser by time of day, independent of date? Time is available -- each Image has a date/time stamp, and the Filter HUD Rule "Date" includes a "Capture Hour" option.


Thanks.


(Ideally, I'd like to sort by solar time -- I'd think this would be of interest to naturalists -- but that seems to be a project for coming years.)


Message was edited by: Kirby Krieger -- corrected name of Rule option.

MacBook Pro 13, Mac OS X (10.6.8), 8 G / 500 G internal / 5 TB external / NEC 2490 / ColorMunki Pho

Posted on Jan 12, 2012 4:32 AM

Reply
Question marked as Best reply

Posted on Jan 12, 2012 5:13 AM

Ah you don't remeber this Possible to sort by time (and only time)

31 replies

Jan 16, 2012 4:57 AM in response to Kirby Krieger

Hello Kirby,

right now I am refactoring my Planetarium Program, written in Objective C - I need to create a version in Racket, to be used by my students in a programming project.


If you think it might be useful for what you are trying to do right now, I could isolate that part of the program, that computes the Julian date, the right ascension, and the declination of the sun (and Moon) for a given date, and from that computes azimuth and height, given longitude, latitude, and height, and time in UTC.

I would then deploy it as an Apple script, with the parameters: Date and Time in UTC, geographic position.


If you are interested, let me know.


Cheers

Léonie

Jan 16, 2012 5:07 AM in response to léonie

I am -- though I don't have the expertise to be sure that what you are offering could be used successfully. Frank has posted back to this thread as well -- let me read though all the posts and see if I can't come up with a mutually understood goal, and then we can see if it is reachable. I'll post back later today (prob. much later 🙂 ).


Thanks for the offer 😎 .

Jan 16, 2012 5:22 AM in response to Frank Caggiano

Frank Caggiano wrote:

So would solar time to the nearest minute be ok or would you need it to the second? And what to you think in the general case?

I would think the nearest 6 minutes would provide a precision finer than which is not usable -- but I suppose I should specify 6 minutes on, say, a twelve-hours-of-daylight day. (I assume we are really talking about changes in position, and not changes in time -- though your question uses terms for time, right?)


As you can see, I need to process this a bit. Let me read through the whole thread -- I'll post something back later today (after sundown 🙂 ). The goal -- I think -- is to stamp each Image with the point in a normalized solar day at the time the exposure was made. This _may_ be the "Mean Solar Time".

Jan 16, 2012 5:30 AM in response to Kirby Krieger

Sorry for being so cryptic - I tend to forget that not everybody has graduated in astronomy like me 😁


What the script could be made to tell you:

  • take the GPS data and the capture date from an image
  • set two custom tags in the image:
    • height of the sun above the horizon in degrees (astronomicallythe height)
    • the direction towards the sun in degrees, counting from the north (astronomically the azimuth)


I think I can offer to contribute the number crunching routines , and I see that Frank has solved most of the GPS tags and custom tags part already...

Jan 16, 2012 2:01 PM in response to Frank Caggiano

My undergrade students (second year) do their programming projects for functional programming in Scheme/Racket, and for them I need this module. It would be easier to assign this task to the graduates, skilled in image processing and Python, but for those students we have different projects.


That Planetarium-algorithms I already programmed in Java with Cocoa (just when I got it finished, Apple dropped the Cocoa Java interface), in Objective C, and in Povray. AppleScript would be a nice addition to my collection.


I really am not sure if it would add anything essential to what Kirby is trying to do, but computing the exact elliptical orbit of the earth around the sun would improve the accuracy of the solar time compared to the mean solar time by up to 15 minutes, and to have the height of the sun above the horizon might help to look for seasonal changes - the difference in height "summer - winter" is enormous - up to 46°.

Jan 16, 2012 7:59 PM in response to léonie

I'm using the equations from this site http://www.pveducation.org/pvcdrom/properties-of-sunlight/solar-time.


The solar time calculations take into account the equation of time to compensate for the orbit but as I'm not an astronomer (or even play one on television 🙂) I'd appreciate it if you'd give their info a quick once over. It seems to be doing a good job.


I have the basic solar time time stuff up in AppleScript but I'm now running into problems interfacing with Aperture. The biggest gotcha is the lack of the ability to get TZ info on an image. It's not part of the EXIF time field and Aperture doesn;t make it avaiable. I'm using some web servies, give the longitude and get back the offset from UTC but not sure if it's all really worth it.


regards

Jan 16, 2012 8:56 PM in response to Frank Caggiano

I'm surprised. We have GPS (emphasis on Global), but our cameras don't record universal time or any proxy for it? I should think the EXIF consortium would be working double-time to get this added.


I still haven't caught up to this, but ... just to make sure I'm on the same page: I could make use of, would like to have available, think it would be cool (I believe that's "kool" in Florda 😁 ), and even think others would like to have available, a numerical index that allowed one to rank one's photos in a continuum that starts with "first light" and ends with "last light", with the fixed points of sunrise, solar noon (=high point), and sunset. I think of this as "normalizing" clock time to relative solar height: mapping our daylight clock hours back onto the experienced solar day, with those three points fixed.


Does that make sense? My "time" divisions are "First light, Sunrise, Morning, High in the sky, Afternoon, Sunset, Dusk". "Morning" for me is "after sunrise and before 'high in the sky' ". I realize that 7 AM may be "morning" for most of the world, but photographically (for me, anyway) half the year it is dark out at 7 AM and this is "night". So I'm looking for a numerical index that will allow me to apply (much more precise) "time" divisions. (As mentioned previously re: precision: four to ten division per hour are, I would think, sufficient for artists and naturalists. Forensics would require orders of magnitude more precision.)


Secondarily, it would be interesting to be able to rank photographs by the height of the sun. This is different than ranking the photographs by where in the solar day they occur. I would be fascinated to mine my data with this other index available (height of sun, with perhaps a tag for before and after solar noon) -- but that, to me, is icing: the cake is knowing across days of the year where in the solar day each photograph fits.


Again -- did that make sense?


(Aside: I imagine these two things are linked, but I can't "get it" yet. As far as I've gotten is: the first index tunes one in with the diurnal rythms of nature. The second index might tune one in to the diurnal rythm of light itself -- _if_ "high noon" in winter looks like a late spring morning when the sun is at the same height. I suspect the seasonal factors (guessing: moisture in the air) overwhelm the effect of the sun's height -- but I don't know. If the "look" of the light is removed, then one is left with just the angle of the shadows and the size relationships between forms and shadows.)


Please don't put undue time into this. I _really_ like the idea -- but at this point it's not worth actual sweat. My thanks to you, Frank, and to Léonie for working on this and for putting up with my thinking out loud.


Semi-OT: I have changed all my computer clock settings to 24-hour time. I like it. On the other hand, I looked up from my desk at 19:39 and saw on an old analog time-piece that it was about an hour and some past when I was due somewhere. "19" now means something to me 😉 . Next up is changing my cameras to UT.

Jan 17, 2012 1:06 AM in response to Frank Caggiano

Hello Frank,

I'm using the equations from this sitehttp://www.pveducation.org/pvcdrom/properties-of-sunlight/solar-time.


.... I'd appreciate it if you'd give their info a quick once over. It seems to be doing a good job.

with pleasure, I just had a look: The approximation for the equation of the time EOT really is very accurate and efficient to compute - it's the best you can do, if you are not willing to take the periodic disturbances caused by the Moon and the larger planet into account, also the long periodic effect of the celestical equator and the Ecliptic (nutation and precession {"Präzedenz" in german}). I would not use this equation for navigation - I might run the ship aground this way, but to sort by time of day it is perfect. I am thinking to use the keplerian elements to do a more precise computation of the ephemerides, because I want to use them for astro navigation as well.


The biggest gotcha is the lack of the ability to get TZ info on an image.

I'll look into that later, now I don't have time right now.


My biggest problem is to get Apple Script to compute trigonometric functions; I found "sin" and"cos" in the satimag.osax, but I do not like to use a non-standard scripting addition for a public Apple Script. Do you have a better solution?


Regards

Léonie

Jan 17, 2012 5:54 AM in response to léonie

leonieDF wrote:



My biggest problem is to get Apple Script to compute trigonometric functions; I found "sin" and"cos" in the satimag.osax, but I do not like to use a non-standard scripting addition for a public Apple Script. Do you have a better solution?


Regards

Léonie

I do but I'm not on the system where I develop right now. I'll get them to you later.


regards

Jan 17, 2012 7:45 AM in response to Frank Caggiano

The biggest gotcha is the lack of the ability to get TZ info on an image. It's not part of the EXIF time field and Aperture doesn;t make it avaiable.

And AppleScript does not make it available either: The "date" class in AppleScript does not have a property "timezone".


To compare notes on the handling of dates:

User uploaded file

  • Since AppleScript does not know the Timezone property, it presents all dates in the system timezone, and the offset between System Time and Universal Time is computed by "time to GMT".
  • My camera is set to UTC; I import using "camera time UTC", "Actual Time UTC"; Aperture displays it as "GMT".
  • When I read the date in Apple Script with 'value of EXIF tag "ImageDate" ', the GMT/UTC time is converted correctly to the current local time, so it seems to be unnecessary, to know the time zone setting in Aperture; to convert to UTC it should suffice to add the "time to GMT"offset.
  • But, however I set the Timezone-Import settings, the date I see in Applescript is the "Date created" as displayed in Aperture, but since Aperture displays this tag in local time, the results do match.


Does that match your observations?

What I do not like at all, is that my UTC dates are displayed as GMT, I wonder what will happen in summer, when the GMT timezone will switch to daylight saving time?


Regards

Léonie

Jan 17, 2012 11:25 AM in response to léonie

Léonie,


This is what I am using for sine and cosine. Don't know if you need the rest or can work off these. These seem to work but I'm no mathematician so I can give no guarantee.


regards


-- Trig functions from http://lists.apple.com/archives/applescript-users/2004/Feb/msg00939.html

-- "A simple Taylor series expansion needs a whole lot more iterations for angles for

-- which the answer is nearly unity. Chebycheff polynomials are a whole lot better."

----------------------------

on cosine(x) -- degrees

local myCos, numerator, denominator, factor


set myCos to 0

if (x = 90) or (x = 270) then

set myCos to 0

else

set x to (x - (((x / 360) div 1) * 360)) * (pi / 180)

set {myCos, numerator, denominator, factor} to {0, 1, 1, -(x ^ 2)}

repeat with i from 2 to 40 by 2

set myCos to myCos + numerator / denominator

set numerator to numerator * factor

set denominator to denominator * i * (i - 1)

end repeat

end if

return myCos

end cosine


----------------------------

on sine(x) -- degrees

local mySin, numerator, denomintator, factor


set mySin to 0

if (x = 180) or (x = 360) then

set mySin to 0

else

set x to (x - (((x / 360) div 1) * 360)) * (pi / 180)

set {mySin, numerator, denominator, factor} to {0, x, 1, -(x ^ 2)}

repeat with i from 3 to 40 by 2

set mySin to mySin + numerator / denominator

set numerator to numerator * factor

set denominator to denominator * i * (i - 1)

end repeat

end if

return mySin

end sine

Jan 17, 2012 12:10 PM in response to Frank Caggiano

Thank you, Frank, that is perfect, just what I was looking for - now I don't have to reimplement the "Numerical Recepies in C" 🙂


Usually I use the Smile companion osax (http://www.satimage.fr/software/en/downloads/index.html), there are many numerical functions, but those are not part of the Apple Script standard distribution.



Have you ever noticed this strange behaviour of the Apple Script Editor? My Date&Time preferences are set to US (Computer), but still the AppleScript Editor replaces any Date String I enter immediately by a german date string. I wonder, if I ever wil be able to deploy my script with english date formatting.


For example: "1/11900 12:00:00" will be replaced immediately by "Montag, 1. Januar 1900 12:00:00"


(* Standard reference dates: Epoch and Bessel Year *)

global J2000date, J1900date, B1950date, B1982date-- date objects

global J2000, J1900-- Julian date constants


set J1900date to (date "Montag, 1. Januar 1900 12:00:00") - 1 * days

-- Julian year J1900,1900 Jan 0.5 TT

set J1900 to 2415020

set J2000date to date "Samstag, 1. Januar 2000 12:00:00"

-- Julian year J2000,2000 Jan 1.5 TT

set J2000 to 24151545

set B1950date to (date "Sonntag, 1. Januar 1950 00:00:00") + 0.923 * days

-- Besselian year 1950



Cheers

Léonie

Sort by time of day, regardless of date

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.