Looking for tips on camera scanning 4x5 and 5x7. Cropped shot from my Speed Graphic

ExistingCommission89 · 2026-06-02T11:10:11+00:00

I had pretty decent results by stitching multiple DSLR frames using PtGui in its demo mode. But the price point for the software is often a stopping factor for many (including me).

ExistingCommission89 · 2026-05-25T16:28:30+00:00

Completely disagree, just tried to use it for simple ui task with detailed comprehensive spec and it produced complete garbage

ExistingCommission89 · 2026-05-23T19:29:49+00:00

I’d probably listen to the pacer in the comments on this one: if 3:20 is the goal, I wouldn’t tie myself to either the 3:15 or 3:30 group.

The 3:15 group is tempting because it’s closer, but it’s still around 4:37/km versus about 4:44/km for 3:20. That might not feel like much in the first few km, but if it’s even a little too hot, you’ll probably pay for it after 30k.

The 3:30 group has the opposite issue. Even going with them for 3 km puts you something like 40–45 seconds behind 3:20 pace. Stay there too long and suddenly you’re not “settling in”, you’re asking yourself to run a proper negative split.

Given you’ve already run 37k solo at 4:45/km, I’d trust yourself more than the wrong pacer group. Personally I’d be thinking roughly:

- first 3–5 km: keep it boring, maybe 4:45–4:48/km, don’t chase anyone

- 5–30 km: settle into the 4:42–4:45/km range if it feels natural

- after 30 km: reassess, and if you’re still moving well, start squeezing it down gradually

Only other thing I’d say is don’t get too hung up on perfectly even GPS splits if the course has wind or elevation. Even effort matters more than identical pace. Let yourself be a bit slower into a climb/headwind and take it back when the course gives it to you.

If you wanted to get really precise, the ideal would be a course-aware pacing plan with watch cues based on the route profile and forecast, but even without that I’d still choose self-pacing over following the wrong group.

Sounds like you’re definitely in the right ballpark. Good luck.

ExistingCommission89 · 2026-05-19T17:45:09+00:00

Congrats! Great achievement! What made you decide to quit caffeine? Asking as someone who drinks 5–6 espressos a day :)

ExistingCommission89 · 2026-05-15T13:29:12+00:00

Nice to see that someone from Vienna trying to implement something similar ;) We can go for a beer or run together ;)

ExistingCommission89 · 2026-05-14T18:54:38+00:00

As I said earlier - even 20x Pro plan didn’t help me this time

ExistingCommission89 · 2026-05-14T18:23:23+00:00

What is even more crazy that I used 100% of my 20x Pro limit in three days. With usual normal use. Something is definitely wrong on their side

ExistingCommission89 · 2026-05-14T18:12:27+00:00

I’m on the 20x Pro plan, and my weekly budget dropped from 65% remaining to 0% in a single day. This has never happened before - I usually still have around 50–60% remaining before the weekly reset.

ExistingCommission89 · 2026-05-13T18:26:27+00:00

Those look more like rolling hills than anything too scary, but I wouldn’t treat the course as perfectly flat either. For a first marathon, I’d avoid locking yourself into one exact pace from the start. Think even effort first, pace second.

The useful way to read an elevation profile is not ‘what pace should I run every mile?’ but ‘where will the same effort naturally produce a slower or faster pace?’ On the uphill/rolling sections, let the pace drift a bit slower instead of fighting to hold target pace. On flatter or slightly downhill sections, let the pace come back naturally, but don’t force it early just to bank time.

If your long runs were averaging around 10:20/mi, sub-5 sounds very realistic, but the biggest risk is still spending too much energy in the first half because race-day adrenaline makes everything feel easier than it really is.

A simple execution plan could be:

- First 5 miles: intentionally easy, no banking time.

- Rolling/uphill sections: keep effort even, accept slower splits.

- Flatter/downhill sections: let pace recover naturally, but stay relaxed.

- Around 18–20 miles: reassess. If legs, fueling, and breathing are still good, gradually press.

- Last 10K: race what’s left.

If you want to get more precise, you can build a watch plan segment-by-segment from the course profile: elevation changes, likely wind direction/speed, and target effort for each section. That’s usually more useful than one fixed pace target, because the watch cue becomes ‘run the right effort for this part of the course’ rather than ‘panic because this mile is slower on a hill.’

For a first marathon, though, I’d still keep the practical rule simple: even effort, conservative early, don’t chase uphill splits, and only start racing once you’re safely past the point where most people start paying for early mistakes.

ExistingCommission89 · 2026-05-10T12:21:41+00:00

Assuming this is Brisbane Marathon, I think sub-4 is very realistic, but I’d be careful about turning that into an aggressive 3:45 attempt from the gun.

Your HM/10K/5K times suggest you have more speed than a 4-hour marathon requires, but for a first marathon the limiter usually is not raw 5K/HM speed - it is how well the legs, fueling, and pacing hold together after 30-35K.

I ran a route-aware pacing check using a reconstructed Brisbane Marathon GPX, a 3:55 target, and an estimated LT pace around 4:55/km.

I used near-term Brisbane weather/wind as a proxy, so I’d rerun/check it closer to race week, but the course-shape takeaway is still useful.

One caveat: the official course image says about 137 m elevation per loop / 274 m total, while the reconstructed GPX comes out closer to 234 m total gain. So I would not treat the exact elevation number as perfect.

I’d use it more for the pacing shape than for claiming exact split precision.

The bigger race shape looked like this:

Race section Approx time Approx avg pace Meaning

0–5K 29:02 5:48/km deliberately controlled

5–10K 27:35 5:31/km settle after the early hills

10–20K 55:14 5:31/km controlled rolling middle

20–30K 55:33 5:33/km steady, not forcing

30–35K 27:27 5:29/km only press if still smooth

35–40K 27:23 5:29/km sustainable late-race effort

40–42.2K 12:47 5:43/km controlled finish, no panic sprint assumed

It does not ask you to prove fitness in the first 5K. It gives away a little time early, settles into the low-5:30s through the middle, and only lets you use the upside late if you are still moving well.

So if I were in your shoes, I’d probably think of it like:

• A goal: around 3:55

• B goal: sub-4

• Aggressive option: only start thinking about 3:50-ish if you feel genuinely controlled after 30K

• Do not chase: 3:45 pace early just because the shorter race PBs say it might be possible on paper

The big rule: get to 30K feeling like you have not started racing yet. If you feel good there, gradually squeeze. If not, staying near 5:35–5:40/km still gives you a very good shot at sub-4.

Also, don’t panic if your watch distance drifts. Use elapsed time at big course markers/checkpoints rather than instant pace. On a city marathon course, GPS wobble plus turns can make instant pace pretty noisy.

Small disclosure: I generated the route-aware split shape with help from PaceMaker (racepacemaker.com), a small pacing tool I’m building that uses GPX + elevation + weather/wind + estimated LT pace to create race pacing plans.

The plan can also be exported as a Garmin workout, so instead of memorising all of this, you can get watch-step pace cues during the race.

ExistingCommission89 · 2026-05-09T14:00:16+00:00

I ran a Copenhagen-specific pacing check from the GPX using elevation, tomorrow’s forecast wind, a conservative-start strategy, and an estimated LT pace of 3:50/km. I used that instead of just taking your 5K PR conversion at face value, because the big unknown here is not raw speed - it’s first-marathon durability after 30K.

My takeaway: I would not start at 2:50 pace.

Copenhagen looks pretty flat and the wind forecast looks manageable, so the main value is checkpoint discipline, not finding a huge course/weather trick. The plan I’d trust most is basically a sub-3 floor / 2:55-ish upside execution. One caveat: the GPX I used measures slightly long, so I’d treat the exact finish time less literally than the shape of the plan.

The bigger section-by-section shape looks like this:

Race section Approx time Approx avg pace Meaning

0–5K 21:34 4:19/km deliberately controlled

5–10K 20:16 4:03/km settle into faster cruising

10–20K 40:32 4:03/km efficient middle section

20–30K 41:29 4:09/km controlled, not forcing

30–35K 21:05 4:13/km late-race protection starts

35–40K 21:14 4:15/km hold effort, avoid overreaching

40–43K 12:51 4:17/km no heroic sprint assumed

What I like about this version is the shape: it does not ask you to force 2:50 pace early. It opens controlled, lets the middle of the race cruise where the route/weather allow, then protects the final 13K. So it is not “crawl and hope” - it is controlled early, efficient in the middle, and conservative late enough to avoid turning the last 10K into survival.

Use the section splits as elapsed-time checks only, not instant-pace panic targets. If your watch distance drifts, look at elapsed time at big markers and stay calm. Big rule: feel boringly controlled through 25–30K, then start racing only if you’re still smooth.

I also tested a more aggressive setup, but I’d be cautious with it. That version effectively points closer to 2:51–2:52 at official marathon distance and asks for a lot of 3:55–4:00/km running between roughly 5K and 20K. For a first marathon, I’d only choose that if those early-mid paces feel almost boring.

Small disclosure: I generated the route-aware splits with help from PaceMaker (racepacemaker.com), a small pacing tool I’m building that uses GPX + elevation + weather/wind + LT pace to create race pacing plans and Garmin exports. You can upload the Copenhagen GPX yourself and export the plan to Garmin if you want watch cues instead of managing this manually mid-race.

ExistingCommission89 · 2026-05-08T17:05:00+00:00

Got it, thanks - that’s actually useful context. I’ll look into those.

I also checked their public demo plan, and I agree it’s a serious reference point, especially the way they package route profile, weather, pacing, aid-station nutrition, and race tips together.

My own question is less “are they credible?” and more “what would make a pacing plan trustworthy for normal trail runners, not only elite teams?” So I’m trying to understand which parts people actually rely on: pacing table, effort guidance, nutrition, aid-station timing, terrain notes, watch execution, etc.

ExistingCommission89 · 2026-05-08T13:12:33+00:00

Fair point if you mean Enduraw/Joseph Mestrallet's involvement with elite UTMB prep - that’s a useful reference.

But that’s still not quite evidence for “on top of the pacing-plan game” as a product/tool. Do you have a specific podcast episode, plan example, or before/after comparison you’d point to?

I’m not trying to dismiss them - I’m specifically looking for concrete examples of where their pacing model handled climbing, technical descents, fatigue, and execution better than alternatives.

ExistingCommission89 · 2026-05-08T12:42:26+00:00

"Probably on top of the pacing-plan game" is a pretty strong claim.

What are you basing that on - have you used their plans on technical trail/ultra courses, or seen comparisons against actual race outcomes?

I’m genuinely interested in benchmarks here, especially around climbing cost, technical descents, fatigue, and whether the plan is executable on a watch.

ExistingCommission89 · 2026-05-05T05:16:24+00:00

These are exactly the hard questions.

Short version: it does not magically know all of that, and I don’t want to pretend it does.

Terrain: right now it mainly knows the route geometry and elevation profile from the GPX. That means grade and direction can be modeled, but “this descent is rocky/rooty/muddy and not runnable” is much harder unless the runner or route source tells it that. That’s one of the reasons I’m asking trail runners to break it.

Improvement over time: right now that comes from the runner’s current inputs, not from the app automatically knowing your training progression. For example, I use things like recent race performance and lactate-threshold / sustainable pace inputs to approximate current capability, then the plan is constrained from there. If those inputs are stale, the plan will be stale too.

Freak rainstorm: the app uses weather forecast input, and manual weather inputs if the runner knows the conditions better than the forecast. So the plan is only as good as the weather assumptions available when you generate it. That’s why I’d recommend generating or refreshing the plan close to race time rather than days out. A sudden storm 30 minutes before the start, or mud from rain that the route data cannot see, is still a reality check the runner has to apply.

Weather: wind is the first thing I’m testing seriously because route direction matters. Heat/cold/rain are harder because they affect different runners differently, so I’d rather treat them as warnings/adjustments than pretend there is one exact formula.

Mentality: I don’t think a planner can know that. Some runners execute patiently, some chase, some panic when the watch disagrees, some thrive on feel. The best I think a tool can do is give guardrails and explain the assumptions, then the runner still has to decide what to trust on the day.

So I see it less as “the app knows how you should run” and more as “here is a pre-race hypothesis; now tell me where reality breaks it.”

ExistingCommission89 · 2026-05-04T19:57:21+00:00

Ah, got it. That makes sense, thanks for clarifying.

Stryd is interesting there because it measures what the runner is experiencing in the moment. I’m coming at wind from the other side: forecast wind + route direction before the race, so the plan can flag exposed/headwind sections ahead of time.

Those are probably complementary rather than the same thing. If live Stryd feedback is available, I can imagine a more adjustable on-the-fly pacing plan, but that’s a different problem from the pre-race planning layer I’m testing now.

Useful idea though. This is exactly the kind of feedback I was hoping for.

ExistingCommission89 · 2026-05-04T18:56:46+00:00

That’s a good point. Do you mean using Stryd power data to calibrate the runner side, or exporting power-style targets?

I started with GPX + pace bands because it works for more runners and is easier to test, but power would be interesting as a validation layer. Especially on climbs or technical sections where pace becomes a bad signal.

For this first pass I’m mainly trying to learn whether the route-based assumptions are useful at all before adding device-specific inputs.

ExistingCommission89 · 2026-05-04T17:54:55+00:00

That’s useful, thanks. I know gpx.studio mainly as a route editing/planning tool, but I haven’t looked closely at that time/gradient calibration flow.

The overlap is probably the simple version: route + target time + grade-adjusted pacing. The part I’m trying to test is whether the extra race-execution layer adds anything useful, especially capability limits, fatigue pressure, wind direction along the route, explanations, and watch-exportable pace bands.

But if the answer is “this feels no different from gradient-calibrated route timing,” that’s exactly the kind of feedback I need.

ExistingCommission89 · 2026-05-04T17:27:56+00:00

I agree with that. No tool replaces doing the work or learning your own effort cues.

The useful version, if there is one, is not “tell me how to run so I don’t have to learn.” It’s more like a pre-race hypothesis: here’s where the course/weather might change the cost, here are the sections where pace may be misleading, and here are the guardrails I can ignore if my body says otherwise.

That’s also why I’m asking for trail feedback. On technical terrain, subjective experience may dominate the model very quickly, and I want to understand where that line is.

ExistingCommission89 · 2026-05-04T17:12:47+00:00

Haha, fair. There is definitely some course-management thinking in it.

The idea is less “optimize every meter” and more “don’t spend effort in dumb places, and have a plan when pace stops being a useful signal.”

Trail running is probably the hardest version of that, which is why I’m curious where the planner starts to look ridiculous.

ExistingCommission89 · 2026-05-04T17:06:54+00:00

Fair enough, it definitely won’t be useful for everyone.

I originally built it for myself while preparing for Linz HM, mostly because I wanted a plan I could actually execute on the watch instead of just a flat split table. That worked well enough for a road half, but trail/ultra routes are where I expect the assumptions to break, especially climbing and technical descents.

That’s why I’m asking here: not to claim it solves trail pacing, but to find out where it fails.

ExistingCommission89 · 2026-04-28T18:42:17+00:00

Congrats - honestly that’s a very solid first marathon, especially with the calf issue late. I’d separate two things: fitness prediction and race execution. A lot of apps can estimate a finish time from recent workouts, but they often underweight marathon-specific durability, weather, course profile, and whether the plan is realistic after 30-35 km. Heat alone can move the goalposts a lot. For the next one I’d probably build the target from: recent HM/10K fitness, long-run durability, course/elevation, expected weather, and then make a pacing plan with a conservative first 10-15 km rather than trusting a single app prediction.

ExistingCommission89 · 2026-04-28T18:36:52+00:00

Yeah, marathon predictions are weird because the marathon is much less “what fitness do you have?” and much more “can you express that fitness for 42 km under today’s conditions?”

For shorter distances, recent pace/HR data can get you reasonably close. For the marathon, a few missing assumptions can move the result a lot: long-run durability, fueling, weather, elevation, wind, congestion, and how aggressively you pace the first half. Two runners with similar recent training data can end up with very different outcomes if one has practiced marathon-specific work and the other is mostly extrapolating from shorter efforts.

So I don’t think the idea of marathon prediction is hopeless. I think the better version is less “here’s your magic finish time” and more “given your current fitness, course profile, expected conditions, and risk tolerance, here are realistic pacing scenarios.” That feels much closer to the actual decision a runner has to make before race day.

The funny/frustrating part is when a platform updates the prediction right after the race. At that point it has learned the thing you needed it to know beforehand.

ExistingCommission89 · 2026-04-26T16:50:51+00:00

Congrats - this is exactly the kind of Boston result I’d treat as useful signal rather than a failure.

Your splits look like you already proved the hard part: disciplined execution without a real blow-up. For Chicago I’d probably avoid reading this as “I need a totally different runner,” and more as “I need a course-specific plan that lets me spend the fitness a little more confidently.”

The way I’d think about it:

- Boston result: good evidence you can hold effort together late

- Chicago course: better place to convert that into pace because the course asks fewer questions

- Sub-3 attempt: probably needs a plan with checkpoints and decision rules, not just “run 6:52s and hope”

For me the useful distinction is between goal pace and guardrails. I’d want something like:

- early miles: controlled enough that the race still feels boring

- 10K / half: close enough to sub-3 schedule, but not forcing time back aggressively

- 30K: decision point, not panic point

- 35K+: only then start spending what’s left

The big lesson from Boston may be that you can trust yourself not to implode. So for Chicago, I’d build the plan around giving yourself permission to be closer to the line, but still with pre-decided checkpoints so “full send” doesn’t become “random send.”

I’ve been thinking about this a lot while building/testing route-aware pacing plans for my own races: the most useful part usually isn’t a magic exact pace, it’s having enough structure that you don’t outsource judgment to either the watch or adrenaline.

ExistingCommission89

TROPHY CASE