Syntax

[carlseibert]

Hi,

I'm working on a video on Exif data in PM+ and I have a couple of syntax questions to clear up, meaning that the overwhelming likelihood is that I've stupidly overlooked something(s).

What is the syntax for searching for an fstop? I can do greater than or less than, but I can't figure out equal to.

When searching location, I can do "within some value of some coordinates" But I again can't figure out "equal to". Frankly, I think that this is intentional, because the chance of exactly matching a coordinate to the 5th decimal is pretty near zero, given that people locomote and GPS is dithered. But I'm just checking that I haven't missed something.

(On my test image, within 1 foot failed and within 5 feet succeeded, when using the values from the file as search terms, BTW. I'm not sure what that means, given that in the one instance, a five-decimal match might/should actually happen.)

It seems that PM+ will only accept decimal GPS coordinates for search, even if a given image may have it written in degrees-minutes-seconds. Correct?

It also appears that values in "within", values less than one require a leading zero - like "0.25", rather than just ".25" Right?

Oh, and it appears that greater/less than or equal to has to be done as ">=", rather than "=>" True?

-Carl

And yeah, the whole topic of Exif just gives me the heebie jeebies......

[Kirk Baker]

Carl,

I'm working on a video on Exif data in PM+ and I have a couple of syntax questions to clear up, meaning that the overwhelming likelihood is that I've stupidly overlooked something(s).

What is the syntax for searching for an fstop? I can do greater than or less than, but I can't figure out equal to.

fstop is treated as a floating point numerical value.  Its comparison operators are:

CT_FLOAT      => [OP_EQ, OP_NEQ, OP_LT, OP_LTE, OP_GTE, OP_GT]

In order, those should be: =, <>, <, <=, >=, and >

When searching location, I can do "within some value of some coordinates" But I again can't figure out "equal to". Frankly, I think that this is intentional, because the chance of exactly matching a coordinate to the 5th decimal is pretty near zero, given that people locomote and GPS is dithered. But I'm just checking that I haven't missed something.

(On my test image, within 1 foot failed and within 5 feet succeeded, when using the values from the file as search terms, BTW. I'm not sure what that means, given that in the one instance, a five-decimal match might/should actually happen.)

It seems that PM+ will only accept decimal GPS coordinates for search, even if a given image may have it written in degrees-minutes-seconds. Correct?

Currently, yes.  The next build will allow GPS coordinates in virtually all GPS formats to be specified.

I believe 'within' is the only allowed type of GPS coordinates.  You can make it nearly exact by using very small units of miles or kilometers.

It also appears that values in "within", values less than one require a leading zero - like "0.25", rather than just ".25" Right?

Yes, leading zero is required.

Oh, and it appears that greater/less than or equal to has to be done as ">=", rather than "=>" True?

Yes.

-Kirk

[carlseibert]

Thanks.

In fstop, all the operators other than "=" seem to be working fine for me. Equal doesn't seem to be working.

I did a little Googling on GPS. Interesting. Turns out they stopped dithering some 20 years ago. I didn't get the memo. :-) Back when they did dither, it wasn't just a little bit. The results were way off.  Like run aground or fly into Class B airspace off. Undithering freed GPS to be the economically viable thing that it is today, according to the interwebs.

You do still get "accuracy within x" in your GPS app or device, but nowadays, the actual accuracy is generally within 5 meters to 10cm, under ideal conditions, depending on whether your receiver has found older satellites or the newer L5-capable ones.  And the results, error included, are still practically usable. As I sit here (indoors), my phone is telling me that my fix is within 42 ft. Not bad. Apparently, in a few years, the whole constellation will be upgraded.

The test image I've been using - scientifically chosen because it's a silly picture that amuses me - is off by about 60 feet. As shown on the satellite photo view in the map in PM+. It was shot in a car, so it wasn't a clear view of the sky situation. I can fix it in Photo Mechanic, if I want. (As you well know, since you wrote it :-)

How wide to set your "within" search becomes a very literal, visualizable example for teaching the basic search principle of widening the search enough to be sure that you aren't accidentally excluding the returns you need and then narrowing it to eliminate extraneous returns. When I use that, probably sooner than later, it will be a direct result of this conversation. Thank you!

[Kirk Baker]

Carl,

In fstop, all the operators other than "=" seem to be working fine for me. Equal doesn't seem to be working.

Can you post an example query that you expect should work?

Thanks,

-Kirk

[carlseibert]

Ah!  It's the dot!

fstop =2.8 fails.

But fstop =8 succeeds.   So does fstop=8. Or any other integer. 13, for example.

<= or >= work regardless of whether or not there's a decimal.

-Carl

[Kirk Baker]

Carl,

Ah!  It's the dot!

fstop =2.8 fails.

Thanks for that additional info.  I looked at the data for f2.8 and it is stored as a double-precision floating point value when ends up being an approximation and not the pure value.

Its value is 2.79999995231628 which is really close to 2.8 but isn't 2.8 exactly.

I'll have to think on a solution.

-Kirk

[carlseibert]

MATH!!!!!!     [.... hides under the blanket....]


Why you're the top developer and I'm just some internet guy....

[Kirk Baker]

Carl,

MATH!!!!!!     [.... hides under the blanket....]


Why you're the top developer and I'm just some internet guy....

I have found a solution and it will require that your catalog(s) be updated, but it will make exact searches for a f-stop of 2.8 return valid results.  It won't be in the next build however.  My fix didn't make the cut in time for the next build, which should arrive soon.

-Kirk

[carlseibert]

Very cool. You rock.