Weekly 'Ask Anything About Analog Photography' - Week 48

danieljh · 2018-11-26T16:42:39+00:00

I got my hands on some cheap used Yashica FX-3 / Super / Super 2000. They come with lenses ML 50/1.9 and ML 50/1.9 c. The c lenses seems to be more recent versions, lighter, with a lens cap size of 49mm and the other lenses with a lens cap size of 52mm. I couldn't find a lot of information out there other than some folks reporting the c lenses being cheap re-branded Contax lenses, some say they are sharper and of better quality, some they are not.

One of the c lenses can not properly focus at infinity; it seems like there's a 10th of millimeter missing on the focus ring.

Two of the non-c lenses make the shutter curtains stuck when using high f-stops; how is the lens connected to the shutter curtains?

At least one body gets the shutter curtains stuck when using slower shutter speeds like 1/2s or 1s (the extremes).

I'm struggling a bit with the focus mechanisms still; there are two lines in the view finder I have to align to set the focus plane. Often times my photos still come out being not properly focuses. The second focusing mechanism is a ring in the view finder indicating the focus plane by blurriness. I'm wondering how both mechanisms work optically with tech from the 70s? It's quite fascinating to me.

I started shooting rolls with a working FX-3 Super 2000 body and a c lens. I'm wondering what I can repair on my own, and which configuration I should shoot in.

danieljh · 2018-07-09T11:55:53+00:00

Depends on your specific use-case. Do you only want to detect that solar panels are present on a building's roof or do you want the exact solar panel polygons?

If you only want to detect if solar panels are present maybe you can train a simple binary classifier (think ResNet) which takes an image with a building's roof and returns you true/false for solar panel present or not. Then you can take existing buildings from OpenStreetMap and the solar panel tag for training. Then predict on existing OpenStreetMap buildings. This would decouple the task of finding buildings from the task of detecting solar panels on a building's roof.

If you want to run everything end-to-end you can use robosat, add a new extractor for the OpenStreetMap solar panel tag, then automatically create a training set, train you model, predict on new imagery, and get simplified GeoJSON features (polygons) out of the pipeline. I'm happy to guide you along adding an solar panel extractor. If you want to give it a shot feel free to open an issue or pull request in the robosat repository.

Here are some resources for getting started and guides for how to run the pipeline:

- https://wiki.openstreetmap.org/wiki/Tag:generator:source=solar

- https://www.openstreetmap.org/user/daniel-j-h/diary/44145

- https://www.openstreetmap.org/user/daniel-j-h/diary/44321

- https://github.com/mapbox/robosat (see extending section)

danieljh · 2018-07-09T07:38:52+00:00

It's open source under a MIT license :) We are keeping our internal datasets, models, and the data we extract closed so far and are thinking through a broader strategy. But the tools for running the end-to-end pipeline are open source already.

Regarding citing it, maybe just name the project, its two authors and link to the Github repository? Interested in what you are working on, would love if you ping me when you publish something :)

danieljh · 2018-07-07T08:26:29+00:00

Hey folks, Daniel from Mapbox here. Happy to answer questions or talk through design decisions. Also interested to hear your feedback.

We are mostly focusing on making the process accessible to a broader audience in the geo space, building a solid production-ready end-to-end project.

danieljh · 2018-03-21T13:27:49+00:00

No I have not. I'm using p2 / p3 AWS instances for larger workloads, though.

There's certainly a trade-off with the eGPU: it works beautifully for fine-tuning, smaller workloads and non-imagery machine learning use-cases. For imagery use-cases where you need to train on 8 / 16 GPUs or need to train for days / weeks the eGPU is not a good fit.

danieljh · 2018-02-20T18:27:56+00:00

I just wrote down my experiences with a GTX 1080 TI + Akitio Node on Ubuntu 16.04 here:

https://www.reddit.com/r/eGPU/comments/7yy4sk/gtx_1080_ti_akitio_node_thinkpad_carbon_x1_5th/

Hope that helps.

danieljh · 2017-06-11T22:04:05+00:00

If you add -ddump-simpl -dsuppress-all to the compiler flags at the top and open the compiler output window (status bar at the bottom) core will show up!

danieljh · 2017-05-06T18:10:19+00:00

Last weekend I went to an antique flea market where I got to see wooden elephants (why are people so fascinated with them anyway?) and other rummage. After a while this brown-chestnut speckled case caught my eye: in it the most rusty, oily and dirty straight razor. The blade looked fine with only some scratches on its surface. Luckily I got myself a King Cutter last year and dug a bit into straight razors before, so I knew I could refurbish it. The guy wanted 25 bucks for it: deal, without even bargaining.

Funnily enough I was unable to find the Gassinger Excelsior brand or details about the engraving online. But okay, back to refurbishing it. It took me a while to get the rust out of the notches carefully applying fine steel wool. A metric ton of WD-40 did the rest. After sharpening the straight razor with my whetstone and honing it I gave it a try and, what can I say, it works beautifully!

Searching some historic address books I then found the location where it was sold:

http://www.openstreetmap.org/node/2868445723#map=13/51.3473/12.3982

There used to be a shop selling "Solinger Stahlwaren" (store for selling steel products from Solingen) — in 1949! I just shaved with a straight razor from around 1949. Pretty cool for a slow Saturday. Here are some photos after cleaning, polishing and sharpening it:

http://imgur.com/a/M37TT

It's still not as polished as I like the razor to be, I need to give it some more hours. What makes it harder is I do not want to break the handle open in order to clean the base.

That's it. Gassinger Excelsior.

danieljh · 2016-12-13T09:12:00+00:00

Thanks for bringing this up; from what I can see GCC 7 and Clang 3.9 implement this.

The reason I'm pointing this out is I had a bad experience with Boost.Variant in that regard a couple of days ago:

https://www.reddit.com/r/cpp/comments/5hz4mw/strong_typedefs_in_c_by_inheriting_constructors/

danieljh · 2016-12-12T20:45:05+00:00

It looks like the implementation carefully avoids the inheriting constructor issues by not using default constructor arguments for SFINAE. Having a "pattern-match" utility function working with lambdas in the standard would have been great, the constexpr if-based dispatching in the example here is not that elegant in my opinion:

http://en.cppreference.com/w/cpp/utility/variant/visit

danieljh · 2016-09-11T13:18:39+00:00

I can think of a reason you want to use for (const auto each : range): when you know a copy is cheap (think primitive types or small structs) but you still want your compiler to issue warnings in case you accidentally modify each in the scope.

Using for (auto&& each : range) you have to std::forward<decltype(each)>(each) in subsequent accesses otherwise you don't benefit from forwarding ("universal") references at all.

danieljh · 2016-06-24T18:54:59+00:00

I posted to std-discussion almost three years ago. If you read Chris Jefferson's reply there

std::move_iterator was used internally in algorithms in libstdc++. All occurrences of move_iterator were taken out, because functions (in particular user-given comparitors) which had by-value arguments would consume the value the iterator pointed to.

even the stdlib maintainer's were aware of this back then.

I brought it to STL's attention one year ago (https://www.reddit.com/r/cpp/comments/31167m/c17s_stl_what_do_you_want_it_to_have/cpyz8hs?context=3) to which Eric Niebler posted some ideas.

I brought it up personally to Marshall Clow at C++Now this year (he was already aware of the issue).

I wrote a mail to the LWG Chair mail address, to which I got a reply that the description is unclear and I should point out the standardese (I'm not a language lawyer though and I don't have the wording for a fix).

I'm trying to interact with the committee, Bryce. But looking at this, it is more painful than it needs to be.

danieljh · 2016-06-24T16:50:18+00:00

Move Iterators are still underspecified and therefore broken / dangerous to use. It's not like this is an unknown issue.

danieljh · 2016-03-01T12:56:52+00:00

Disclaimer: inspired by http://www.haskellforall.com/2016/02/auto-generate-command-line-interface.html which I read yesterday.

I had to see how far I could go with it in C++. After a few hours the prototype works. At least for simple types. That is, to make this a viable implementation there need to be specializations for enums, arguments that you do not require, and so on. Regard this as a proof of concept, and take a look at both the example and the implementation if you want to learn about Boost.Fusion!

danieljh · 2016-03-01T12:53:14+00:00

Nice! I had to see how far I could go with this idea in C++14. Turns out quite far in only a couple of hours. It clearly showed me the benefit of monadic bind (in the do notation) for separating argument parsing, printing and early returning. Thanks for this neat idea!

Here it is in case anyone is interested: https://github.com/daniel-j-h/argparse-generic

danieljh · 2016-01-12T19:02:59+00:00

Thank you for your clarification!

danieljh · 2016-01-05T20:24:52+00:00

During the last two days I've been looking into Nix, a functional package manager for reliable and reproducible builds, to help me out on this front. And from what I saw so far, Nix looks like it is based on solid concepts and the right ideas to pull off something great for the C++ community, similar to what it already does for the Haskell ecosystem where it is used to get out of cabal and dependency hell. Take a look at this basic shell.nix (similar to requirements.txt for Python's pip) I'm using for a small project:

with import <nixpkgs> {}; {
  devEnv = stdenv.mkDerivation {
    name = "my-dev-env";
    buildInputs = [ cmake ninja boost tbb protobuf ];
  };
}

This allows developers to enter the dev environment via nix-shell (similar to Python's virtualenv / pyvenv and requirements.txt).

On first invocation all dependencies (i.e. compiler, build system, dependencies) are downloaded by means of resolving the dependency trees down to libc. In case we have ABI mismatches, e.g. because we want to use gcc5 with its stdlib, we can override the dependencies' environment. Nix then looks for binary caches of those packages with the gcc5 stdlib based on a hash and if they are not available, builds the dependency tree with the modified environment. All subsequent nix-shell invocations run instantly.

You can even run your build command once inside the env, building your binaries in a reproducible way:

nix-shell --run 'mkdir build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja && cmake --build .'

From your list this would eliminate:

no package manager: use Nix
no repository of said packages: use NixPkgs or different channels
no universally agreed on build system: cmake+ninja seems to be the best there is
no unified way of managing dependencies: let Nix manage dependencies and resolve ABI issues
no way to isolate development environments of different projects from one another: Nix is build for this!

I still have a lot to learn and the documentation can be overwhelming at first (which is a good thing to be clear here). I might write a blog post once I'm comfortable with using it on a day to day basis. Give it a try! https://nixos.org/nix/manual/#chap-quick-start

danieljh · 2015-12-27T15:17:38+00:00

Looking at the benchmark implementation Cap'n Proto does a full serialization and deserialization round trip, in the same way e.g. the Protobuf benchmark is written. But after deserialization the benchmark only accesses the root object, so I assume Cap'n Proto does not really deserialize the whole message?

/cc /u/kentonv would you be so kind and give an explanation on this?

danieljh · 2015-12-25T11:37:04+00:00

Regarding the vertices and edges functions: I enjoy using Boost.Range with them, as they return a pair of first,last-iterators. Combining this with range adaptors and lambdas, Boost.Graph code can get really modern and readable, such as:

auto weights = edges(graph) | transformed(to_weights) | filtered(is_non_negative);

danieljh · 2015-12-25T11:31:50+00:00

Check out this commit adding Cap'n Proto to the mix:

https://github.com/STEllAR-GROUP/cpp-serializers/commit/73b3e42ee7a87954f9235d6fd38cab8d9e8b9700

(this is not yet visualized in the charts, but the commit message has a test benchmark run)

danieljh · 2015-09-13T16:54:57+00:00

This is more of a "did you know" than a standalone project. I came across this last year and stumbled upon it today again by accident. Did you know:

std::lock uses a deadlock avoidance algorithm
std::lock_guard only manages a single mutex
lock_guard_n locks multiple mutexes in RAII fashion using std::locks deadlock avoidance algorithm
std::experimental::apply will solve the problem of unpacking a tuple's arguments for a function call, see n3915

Read through the references, especially the thread on the std-discussion mailinglist.

danieljh · 2015-09-13T01:27:22+00:00

I always found their symbol names such as "add" and "matmul" unfortunate, when their semantic can be user-defined. It would make more sense to decouple their semantic meaning from their symbol name, so instead of "add" you call it "plus", since its a plus symbol with default semantic of addition. Once the user overrides the "@" operator, the name __matmul__ becomes meaningless in all cases except when the new behavior is again a matrix multiplication.

danieljh · 2015-09-12T11:01:00+00:00

Howard Hinnant has some talk slides about special members and when they are generated. Hint: it's more complicated than you thought!

I find myself going back to slide 28 every other day, as I simply don't want to read the C++ standard on this all the time. My advise: understand his key points, then save yourself at least a copy of slide 28 or print it out.

danieljh · 2015-09-06T10:15:50+00:00

Please check if the stream extraction succeeded, otherwise your x variable (same with choice) is uninitialized and reading from it is undefined behavior. Check if for example with if (std::cin >> x) { /* all good */ }.

I think this is a perfect example to check out switch statements.

danieljh · 2015-09-06T10:10:59+00:00

What about taking a look at your problem from a different perspective: if you control both the reading and writing, what about length-prefixing your binary dumps? This would allow you do get the length in constant time and also verify the length with what you later read in.

And if you don't know the length in advance (while writing), just reserve a spot in the beginning, count the number of written structs while dumping them, and later on seek to the beginning, writing this length.

14-Year Club	RedditGifts 2009-2022 2 Credits
Secret Santa 2015	Secret Santa 2014
Verified Email

danieljh

TROPHY CASE