#at first I stuck to the first option you got for optimization to reduce file size | Explore Tumblr Posts and Blogs

jerome-blog1 · 4 years

Text

Edit Away – The quest for a perfect HDR

A big thanks to everyone for visiting! This photo has 55’000 views and 550 favorites!

View Large ‘Edit Away’ On Black

(This is a re-edited HDR of Forest Railroad Bridge)

Note: Below tutorial was written for Photomatix Pro 2.22. Photomatix latest software version has similar but slightly different settings.

The quest for the perfect HDR – A Photomatix Tutorial

I’ve had a few people ask me how I make my HDRs, so I decided to post the guide here.

I’m not really explaining what a HDR is, as that has been explained really well before. (Check the links there too)

I use Photomatix, which you can try for free and download here: www.hdrsoft.com

I use the full (pro) version, which gives you the option to do Tone Mapping. I didn’t have that option with the free basic version, so you will have to buy the pro version as far as I know to make HDRs and to tone map them.

I almost always used a tripod so far, and generally make 3 exposures (3xp). These xp would all be 2 stops apart. So one with the highest xp (xp +2), one with xp 0, and one with the lowest xp (xp -2). For some photos I also used 5xp, where they are all 1 stop apart. I shoot JPG, as my camera doesn’t have RAW shooting options. 🙁 Sponsor me for a new camera? 🙂 Donate with Paypal

One thing you should keep in mind is that more xp has its advantages and or disadvantages.

Advantages of more xp

Higher color range – More different xp to get the color information from.

Less blur in some cases – If you are photographing things that are close to you in windy conditions, like leaves on a tree that are 1m or closer away from you, taking 5xp or even 7xp or more, will make sure that at least some of the photos will be aligned. This reduces blur on the final HDR because the 1 or 2 photos that might be unaligned will not be as visible if you have 5 that are. If you would only take 3xp, there is a great chance that if one of them is unaligned, it will show pretty clearly in the HDR, which is not always nice. I am not talking about soft blur, which usually does look pretty nice; I am talking more about seeing two leaves overlapping each other for example, which is not what we want. The more xp you take, the higher chance you have of your unaligned photo turning out to add soft blur, which is good.

Disadvantages of more xp

More work & takes longer – Logically, you are going to have to take an extra 2 or 4 photos. Sometimes you have to work fast because of changing conditions or movement, photographing people that have to sit still for a long time is hard for example.

More possibility of unaligned photos – Of course, the more photos you take, the higher the chance is that you get one that is not aligned. With only 3xp, if you are fast and your camera is stuck securely, and it’s not windy, you have a good chance that you won’t have any unaligned photos. But if you take 7xp there might just be one or two that won’t be aligned. Still, this might be part of the advantages as I explained above, since that might result in an accidental soft blur.

Soft blur

I have used this technique on some of my HDRs, and I think it looks very nice. So how do I do this? Well, if you haven’t found out yourself yet, it’s pretty easy. Blur one of the photos; usually I take the middle one or one that is a little overexposed, xp 0 or xp +1. However you do this is of course up to you, and I will let you experiment for yourself with that. I used Gaussian blur in Photoshop with a blur of 5 or 10 pixels.

Then you make the HDR as normal, and I have done this in 2 ways so far. Let’s say we have a photo that we made 3xp of and we use xp + 1 to blur. Either you can replace xp +1 with the blurred version, and make a HDR of 3xp of which one is blurred, or you can add the blurred version to all 3 originals. Then you will have 4xp. I like this result better usually and it’s not really more work.

Tip: Make the HDR from the normal exposures first, then blur one of the exposures, and add it to the other exposures, take them into Photomatix again, and use the button “Previous Settings” to get exactly the same HDR coloring and contrast etc as you got in the non-blurred HDR.

Edit: To get a blurred photo, of course you can also just set your camera to macro mode or make an unfocussed photo by focussing incorrectly. Doing this gives different results than blurring with Gaussian blur in Photoshop.

Edit 2: Lately I have been using a different method. Finish the HDR, then open it in Photoshop. Double the layer, and do a gaussian blur between 10 and 50 pixels or so. Set the layer to "overlay" mode and reduce the opacity to 50% or so if that looks better. Play around with the brightness and saturation of the blurred layer as this can give some nice effects as well. I sometimes also only blur certain parts of an image if that looks better.

Tone Mapping

This it one of the most important steps in getting a nice HDR. Take your time for this. I spend more time tone mapping sometimes than taking the photos.

I will explain the tone mapping in Photomatix, as that is the only program I have used so far.

If tone mapping is a magical machine that can create beautiful dreamy photos, then this machine has 7 weird dials and levers that can help you find the right combination of the perfect HDR.

Of course I must say that making a perfect HDR also requires perfect photos… 🙂

I will explain these "levers and dials" only as far as I know, I am no pro, I just try things out myself as well. The italic text is from Photomatix’s help file.

Luminosity Adjusts the brightness of the shadows and the amount of local contrast enhancement. Moving the slider to the right has the effect of boosting shadow details and brightening the image. Moving it to the left gives a more natural look to the tone mapped image.

Slide this to the left to make the image generally darker, and to the right to make it brighter. I have more often used it to make things brighter so far, because I love bright daylight images, but if you want a more natural, or darker image, maybe the left side is better.

Strength Controls the strength of local contrast enhancements. A value of 100% gives the maximum increase in local contrast.

Be very careful with this setting. This is one of the strongest edits. Play with it as much as you like, you will see the difference. It depends as well on what your photo is. If you have clouds in the photo, setting this higher than 50% often creates grey shadows on clouds that are the typical ugly HDR. I have only seen a very few HDRs with dark clouds that looked good. I only set this to 100%, or often around 70% when I have few or no clouds or sky in the photo. This setting can be set lower to reduce halos around clouds and other subjects in your photo as well.

Color Saturation Controls the saturation of the RGB color channels. The greater the saturation, the more intense the color. The value affects each color channel equally.

Set this low to create a flat image with less color, or to the right to make a bright colourful image. I often set this (too?) high, because I love color.

White Clip & Black Clip Both sliders control how the minimum and maximum values of the output image are set. Moving the sliders to the left increases global contrast. Moving it to the left reduces the clipping at the extremes. The White Clip slider sets the value for the maximum (pure white or level 255). The Black Clip slider sets the value for the minimum (pure black or level 0).

I usually set White Clip anywhere between 0.250% – 5.000% and Black Clip pretty low around 0.100%. Setting black too high, often creates halos around clouds, and makes the image seem weirdly dark.

Smoothing Controls the amount of smoothing of luminance variations. A higher value tends to give a more natural look to the image. A lower value increases sharpness.

I agree completely with Photomatix, and can only add that I prefer High, or Medium. I hardly ever use the lower settings, but have a look at them anyway just in case.

Microcontrast Controls the accentuation of local details. The default value (0) is the optimal value in most cases. However, this control may be useful in the case of a noisy image or when the accentuation of local details is not desirable (e.g. seams of a stitched pano in a uniform area may become visible when local details are too much enhanced).

So I assume that with the default value they mean “Very Low”? Im not sure. At least, Microcontrast does what it says it does. It makes the contrast between small details Very Low, Low, Medium or High. I usually use Medium or sometimes High. I find the lower values make the image too flat.

For the rest you find buttons under tone mapping for Settings to use Previous tone mapping settings, Default settings provided by Photomatix, these have never looked good according to me, and load and save settings. Save your settings if you think they look good and you want to use them more often. I use preview size 768, which is unfortunately the highest, I would like a higher resolution. (Set this size to be default: View > Default Options > tab HDRI > Preview Size 768.)

Hope this all helps; I would love feedback or suggestions. Let me know what you do differently, I’m interested in everyone’s techniques, as HDR is a powerful tool that can give very nice results if used correctly.

I will post this guide on some of the HDR groups, as I think it will be interesting for everyone!

Enjoy your quest for the perfect HDR!

and if you’ve found it, let us know of course! 🙂

Christiaan

Posted by Christiaan Leever NL on 2006-05-14 00:10:45

Tagged: , forest , railroad , bridge , hdr , softblur , dream , green , catchycolor , netherlands , nederland , holland , rails , train , tracks , tutorial , help , quest , learn , technique , tone mapping , luminosity , strength , saturation , white clip , black clip , smoothing , microcontrast , exposure , high dynamic range , 81 Points

The post Edit Away – The quest for a perfect HDR appeared first on Good Info.

0 notes

barelycompiles · 6 years

Text

Constructive Ways of Managing Quite Long Development Iteration Times

So you're a brogrammer now. You sling some Python, or Coffeescript, or bash, or whathaveyou. Now you're contributing so some mighty project, and it is taking quiet a while (in developer time) to build. Maybe the compiler is slow. Or the CI server runs a bunch of extra checks. Or you're generating virtual machines that take ages to install. Whatever your project, it can feel agonizing to change a few characters, start a build, and have to wait a long time for the build to finish before you actually know if your code is working. If you're lucky, the build runs sucessfully and you now have a working system to share with others. If you're unlucky, the build dies half an hour from now, and you'll be tweaking some more characters, triggering another build, and by then you'll have lost quite a lot of productivity. In an industry of instant gratification, latency measured below human perceptive levels, actually making your own software can be a very different experience to using premade software. Expect more pain and bugs than usual. When you clock out of a hard day's coding, you may have only moved the progress bar a few ticks, while the rest of the open source community seems to whizz by at light speed. It feels like being stuck in a local Turing tar pit, where even the most incremental code changes take forever to test. What a bother! Might as well ditch software entirely and go back to Triceratops trolleys or however things were done before computers.

The good news is that, as bad as a post-fifteen-minute build may be for software development, it's neither atypical nor fatal to the success of a project. You think you have it tough? Hardware development cycles can take months, so practice patience young programmer. If you're stressing about fixing that null pointer exception before the hackathon deadline in time for a pizza break, consider how the foreman feels managing a condo. He doesn't even get the benefit of instantly wiping his workspace when something builds wrong. A foreman (or forewoman) has to spend even more time and money to tear down any mistakes during construction. You got it lucky doing your jerb from a coffee shop.

As I said, it's not uncommon to suffer egregious build times that take far longer than a few milliseconds, stretching instead into the quarter hour, half hour, or multiple hour mark. This happens for a lot of reasons, basically ineptitude in build design, which we won't cover in this post. There are plenty of steps an engie can take to optimize build times, and if you're the punk suffering from those build times, I'm sure you know better than me what specifically is soaking up your productivity. If you can fix that, you should. A good technical leader will recognize when project structure is limiting productivity, and will reward anyone who can reduce these blockages. The technicals don't matter so much as the political power to effect that change. That's all I'll say about that.

Instead, this post is about what you can do to get the most out of a sucky code-build-test-repeat loop, where you've exhausted the technical and political possibilities for improving the loop time. Aside from rewriting the project from scratch (probably in Go), what can be done to stay productive in this hellish environment?

Recognize your daemons.

Take stock of the applications, services, processes, and so on that are sharing resources with the building project. If you're playing around in Photoshop the same time you're running a graphical benchmark, that probably adds some extra delay on top of the baseline delay. Disable networking programs, menulets, anything that is stealing precious resources from the build.

If you're building locally, consider moving the build process to a dedicated remote server. If you're building remotely and the server is always stalling, replicate the build locally. Even odds that the build system is awkward and designed for local operation XOR remote operation, i.e. not for both. If you can unify the build system so that it can run more similarly and successfully in both environments, that will exponentially improve production reliability in addition to improving build times. Use Docker. Anyway.

Debug logically.

Richard Feynman is said to have fixed a radio just by thinking about it. Some shit like that. The point is, you spend time thinking about a problem before you go and solve it. Especially when the act of solving it takes way more time than thinking about it. Become the compiler. Practice those stupid Java puzzlers. Once you hit Build, it will be very many nanoseconds in the future before you can fix the code and build again, so make every build count. Specifically:

Lint your shit. Your text editor can warn you of build-failing code before you actually build.

Unit test your shit. When you add functionality, write a dinky little test that should fail if the function is at all inaccurate. Learn the syntax for calling specific tests rather than the whole test suite.

Automate that shit. If you're setting up a database every code-test iteration, find some kind of process so that the computer does the work for you. Doesn't have to be a perfect POSIX compliant shell script. It doesn't have to be portable across different user accounts. It doesn't even have to be command line driven, just as long as YOU can get it to run and do the things you need in a basically reproducible fashion. If it fails half the time, run it twice the times.

Master the code base.

Software is shit. There is a very good chance that the build error you see bears the most strained and tenuous relationship to the actual source of the error. I hope you never have to debug microservices. Jesus.

In any case, study not just the error messages, but the code base as well, including the history. Does git-bisect show a particularly bad sequence of commits? Does churn show an unusually in-flux file? Does git-blame show a logic bomb your asleep ass slipped into development months ago? Which classes are poorly documented? Which classes' documentation are LIES? Baz Luhrmann would have sung "Add... Print statements." if he wrote this shit.

Boldly experiment.

In science, some experiments are so sensitive that they take decades to complete. You can't push a rover to mars faster than the laws of physics permit. So when the project calls inherently for long turnaround times, the thing to do is to pack that bitch with as many experiments as possible. Collect soil samples, record atomospheric measurements, take photos, gather dozens of metrics. It's a big investment, so diversify the treasures.

Do not be afraid to try out ideas on the code. Fork it. Branch out. Tie it up in an FPM bundle. Delete the parts that you don't like. Fix multiple bugs at once, because it's better to find out that 4 changes don't work in 1 hour than to find out that 4 changes don't work in 4 hours. Change the code to fix the top error message, and the next dozen, before you hit Build.

Fuck commit hygiene. What a waste of time! Do your dirt in a feature branch and rebase for cleanliness once the build works. Swap out dependencies, even just different versions of dependiencies. Pin that shit. Lock it down. Distrust semver. Control your space, now you have all the time in the world.

They say discipline boosts creativity. Not fascistic hierarchical discipline, just the idea that supplying your own structure to your work can actually lead you naturally and unexpectedly to new ideas. Try programming without classes and objects. Try installing operating systems without a mouse. What kind of algorithms would still work for that problem without losing idemopotence? How freeing is a system with full POSIX compliance? How freeing is a system with no POSIX guarantees? Change the system to work for you, or else change yourself to work in the system.

It can get so droll hitting Build, looking up an error code, changing one or two lines of code, repeat, repeat, repeat. Take a coffee break. Do something else for an hour, even if it's just coding in a slightly different project. To be pretentious, let your subconsciousness solve the problem for you while you consciously attend to other tasks. That single threaded grind can wear you down, so I personally recommend pipelining your life with more than just the same old same old. One of my coworkers had a multiple monitor setup. The first monitor was for coding. The second monitor was for "bullshit", basically Internet memes. Find your bullshit Zen. You can be productive, even when the system seems to be designed against productivity. Lurk in IRC; solo coding gets depressing after awhile.

If you're suffocating from long build times, breathe. You are not alone. Build times can certainly be improved, but history indicates you'll be far more productive if you treat long build times as axiomatic, just part of the inherent nature of the work. You can pine for a time machine to fast forward the build, or work on unrelated tickets, or program defensively. Standing still is not an option, not for this blog.

0 notes