Skip to main content

Dear John Nack #2

I suppose I should name this Dear Adobe, since John isn't actually involved with Lightroom or Photoshop. And I will, next time.

I LOVE the Adaptive Wide Angle filter in Photoshop CC .... except when I don't.

AWA is a filter like Lens Corrections, that places a preview of your image in  window of its own, where you modify various controls and view the effects in more-or-less real time. When you click OK, the modifications are applied to the entire image. While there are a number of options, which vary the amount and type of controls available, I use it on panoramas. You draw a line on the image, by clicking the endpoints, and a guide line is presented, bisecting a circle. By clicking where the line and circle intersect, you can cause the line to rotate to a different angle. But unlike a simple image rotation, you can have many lines, rotated to various angles, manipulating a mesh superimposed on the image.

I use it to straighten out panoramas, so my horizontals are horizontal and my verticals are all vertical. But you could be more creative with your selections, and generate something more cubist.

I forgot to mention, since AWA is presumably intended for application to wide-angle images, the two points you select are connected by an arc, not a line, and the intensity of the arc depends on where you are in the image. That is, near the top the arc is a rainbow, near the bottom it is a cup, and in the middle it is a straight line.

Pre- & Post Arc Complexity

Sometimes the degree of curvature is an excellent match to the portion of the image I want to adjust, but sometimes the system wants to draw an arc, when I want a straight line, or at least a drastically different radius of curvature. I wish there were a way to control the curvature, maybe an adjustment in the sidebar. Actually, it's something you need to adjust in the middle of setting the end-points for a line. Perhaps a control-click could specify one or more intermediate points, similar to the way you draw bezier. In fact, why not allow bezier curves, not just arcs? Most people wouldn't use the fancier features, but a few perverts creative types would.

As well, You don't always want a curve  totally flattened out. Since wide-angle distortion has become a part of our visual vocabulary, there are times when you want to leave some distortion, or even to create some where there wasn't any! Wouldn't it be cool if you could adjust the post-flattening characteristics of the line, as well as the pre-flattening ones? Of course, you COULD achieve the same effect by using a "wrong" curve for the original line, then, when it was flattened, you would wind up with some curvature. In fact, all that's needed is to be able to re-adjust the points that define the curve, including the one or more intermediate points. Click the two endpoints of some feature to define a line, then drag the automatically provided mid-point away from the line, to introduce curvature where there was none.

Moving Reference Points away from Line Endpoints

A totally different problem I have is that sometimes the features I want to snap to, don't extend all the way across the region that should be modified. For example, if there's a wall with a couple of windows in it, the bottoms of the windows define a horizontal line ( usually ). But the line should extend right across the wall. AWA provides a zoom-in view of the endpoint, allowing you to precisely place the point where it belongs. But if you click on the windows, you aren't affecting the whole wall. If you go to the edge of the wall, there are no reference points to work by.

My solution is to set an endpoint on one window, then drag across to the other end of the wall, setting the endpoint by guessing where the reference point is on the second window. Then I move the first endpoint to its end of the wall, again guessing where the reference point is.

One simple solution would be to define the curve using the endpoints and intermediate point, and then extend the resulting line to the edges of the region. In effect, the end points are turned into intermediate points. I'm not sure how that would work with beziers.

Another solution is to lock the preview window in one place (the window in the wall) while setting the endpoint at the end of the wall. The up-down location of the endpoint is critical, since it is defining a horizontal; the left-right position is less critical---it doesn't matter if it extends past the edge of the wall, or stops a fraction short. Perhaps you could have multiple preview windows, the way you have multiple reference points in the Sharpen->Shake Reduction filter.

Automating Line Angles

As I mentioned, the result of clicking twice on the image is a straight line which can be rotated to any angle you like. But it's irritating to rotate it some tiny amount. Long lines get better precision, while shorter lines are difficult to adjust accurately. Why can't you just specify that some line should become horizontal, or should become vertical, thought I? After imaging some overly-complicated ways that could be done, I thought the best solution would be to hold down the shift key, just like you do when drawing lines to restrict them to horizontal, vertical or diagonal. Well, that's a silly idea, but I gave it a try, anyway. What do you know, those Adobe engineers are almost as smart as I am! :-)

Endpoint Fine Adjustment

The preview gives you the ability to see close-in around the endpoint, but there is no fine-movement control, or, at least, I haven't found it. Once the proximity of the end-point is established, it would be good to set the exact location in a more precise manner, even pixel-by-pixel. I've tried chording the shift, control, option and command keys, but they don't seem to affect the behaviour.

Autoscale

When you go into AWA, the image occupies most of the frame. However, since it may not be rectangular, as a result of merging multiple images into a panorama, it may not fill it entirely, in both horizontal and vertical. On the contrary, while one dimension may not fill the frame, the other dimension frequently overflows it, like a camera viewfinder that shows you only 90% of the image.

I prefer to work on the entire image, even if the edges may be not entirely useful, do to curvature and jaggedness. So I wish there were a button to set the scale so the entire image is visible.

Once the work is done, the shape of the image may be altered somewhat, due to distorting the mesh. I want at least one dimension to totally fill the frame, during the processing from filter preview into actual image, since my superstitions tell me I get more effective pixels that way. I haven't tested it, so maybe I'm wrong. Still, it would be nice if there were FIT and FILL options, as there are in the Lightroom navigator, to set the scale to exactly the correct values. As it is, I type numbers into the scale adjustment, or scrub the slider, or use the arrows with or without the shift key. But it takes time, and sliding the image up or down, when it's something that computers should be doing for us. Of course, I may further optimize the scale, prior to applying the changes, if I'm intending to crop the image further.

Summary


So there's my list. One of my requests is already implemented. Are any others already there, just waiting for me to find the right commands? Will Adobe think I'm out-to-lunch, or will I be receiving royalty checks ($0.003 a year) for inventing brilliant ideas?

Comments

Popular posts from this blog

Creating Perl5 Objects with Moxie

Having in the previous article prepared data types for car suits and card ranks, I can now combine them to provide a playing card class, using Stevan Little's Moxie module (version 0.04, so definitely early days.) The goal is to provide an object-oriented paradigm to the Perl 5 programming language which is more sophisticated, more powerful and less verbose than manually bless()-ing hashes. To achieve that goal it needs to be faster and light-weight compared to Moose. Currently, Moxie.pm and and MOP.pm are add-on modules, but eventually, when they are more complete, when the wrinkles have been ironed out, and when they have gained acceptance and a community of users, they might be merged into the Perl core.

One significant feature of Moxie is that it reduces boilerplate code. You don't have to specify warnigns or strict. As well, the features or the perl you are using are enabled, among them say, state, signatures, and post_deref.
A Simple Moxie Class package Card { …

Perl5, Moxie and Enumurated Data Types

Moxie - a new object system for Perl5 Stevan Little created the Moose multiverse to upgrade the Perl 5 programming language's object-oriented system more in line with the wonderfull world of Perl 6. Unfortunately, it's grown into a bloated giant, which has inspired light-weight alternatives Moos, Moo, Mo, and others. Now he's trying to create a modern, efficient OO system that can become built into the language.

I've seen a few of his presentations at YAPC (Yet Another Perl Conference, now known as TPC, The Perl Conference), among them ‎p5 mop final final v5 this is the last one i promise tar gz<. So I was delighted to recently see an announcement of the module Moxie, and decided to try implementing a card game.

While the package provides some POD documentation about the main module, Moxie, it doesn't actually explain the enum package, Moxie::Enum. But delving into the tests directory reveals its secrets.
Creating an Enum package Ranks { use Moxie::Enum; …

Adventures in Autovivification

Having recently started a new job, I was exposed to old code with multi-step tests against autovivification in multi-level hashes. You get used to the code you have seen, but in a new environment it‘s irritating and jarring.
Moose does not generally have the problem, first because class structure is pre-declared, because values are accessed using accessor functions rather than directly, and because responsibility is delegated down to attributes, avoiding long chains. On the other hand, Moose has it's own overhead, so hand-rolled objects, and bare structures still have their use.
If you don‘t protect against autovivification, then mis-spelling a key, or referencing keys which haven‘t been instantiated in this instance, causes those keys to instantly come into existence.
#!/usr/bin/perl use warnings; use strict; use Data::Dump 'dump'; use 5.024; my $var = {key1 => {key2 => {key3 => 'a'}}}; say dump $var; if ( $var->{key1}{key2}{key3b}[13]{foob…