There have been many different stitching methods. The one used by autostitch is the only automatic one AFAIK, and is widely (though not always visibly) licensed.
I've read a bit about it. It involves feature extraction after the fashion used for object recognition in machine vision, correlation of matching features in the various images, followed by analysis of the lens distortion implied by the measurable curvature in the correlated points. Then some adjustments can be made to the actual exposure levels to reduce discontinuity, and finally a new image is constructed with blending in the overlap region. Straightforward enough technique now, but a lot of work to implement effectively.
I doubt there are competitive implementations anywhere, but perhaps there are some inferior ones.
Autostitch has a number of tweakable options in how loosely the features must match to be considered matching, and things like that, but no capability (nor need! as older techniques did) of requiring the user to manually identify features.
You should set your camera to "Exposure lock", and take the first frame at a part of the scene with median lighting.
That would be scribus - it is, AFAIK, /the/ open source DTP program. I have barely tried it myself, but it is apparently very popular. And as with many such tools, it is cross-platform - try it with Linux, Windows or MacOS as you will.
I find it even more surprising how many people /pay/ for packages like this - when there is free software such as 7zip that does everything you need.
I also find it depressing how many people abuse WinZip and WinRAR by using them without paying for them. Shareware is commercial software sold for money - it is free to test and try out, but people should either pay for it (as you did for WinAce), or use something else.
And I find it depressing how companies can take other people's hard work, put a pretty face on it, call it there own and sell it. That's what WinZip did - the guts of the program were originally InfoZip's BSD-licensed zip libraries. I know that this is perfectly legal under the BSD, but I still feel something is morally wrong somewhere.
Dunno. I first stumbled on the "tool" at a client's shop. Only needed it for one photo so never thought much more about it.
Some time later, needed to do something similar so bought a copy of it figuring it *might* work for me -- assumed the ease of my first success with it was just a pleasant coincidence. Figured it would probably take "a bit of work" to make regular use of it but considered the potential gain as well worth the effort (e.g., NOT having to use wide-angle lenses, 360 views, etc.).
So, when I subsequently found it to be literally a "no-brainer" to use *regardless* (almost) of the "input" photos, I was really blown away. BFM without a doubt!
I've since found several cases where it was unable to stitch things together without significant visual artifacts. But, in each case, I almost *knew* I was going to have a problem *while* I was taking the photos (but couldn't articulate "why" since I didn't understand what the algorithm was doing).
Now, it's as if I go *looking* for opportunities to use it! :>
Hmmm... I had assumed it was just trying to convolve the DCT's from the individual images looking for a peak or a null. But, that was just an ignorant guess as to how the magic might work. Anything else that I could think of seemed like it would use more resources than this apparently was using.
OK, the latter makes sense -- once you know where to line things up.
My tool does everything by itself -- unless you have taken bad photos to begin with. E.g., in one case, I had taken overlapping photos of a line of small trees. The pattern was probably too regular for it and it matched up the "wrong" trees in successive images.
In another (360) case, most of the photos were at near infinite distance (the horizon) but a couple with very close content (~10 feet). The resulting image was pretty significantly "bent". E.g., the cover photo in newsletter shows a similar curvature though not anywhere as severe!
Hmmm... I'll see what the various controls are. For the most part, I just snap photos until something looks "about right" (i.e., without really thinking about what I am doing -- though I've learned that "macro" is almost essential for anything within arm's reach)
Unless it does something that FrameMaker *doesn't* (which would be a stretch), I wouldn't be interested. I think Frame was only about $500 when I bought my first "version". So, I've maybe laid out ~$1K considering upgrades -- well worth the amount of use I get out of it! And, the number of bugs/workarounds that I've had to deal with is surprisingly few. (I don't like having to debug someone else's tools...)
Yes - multi-column layouts need synchronising like this.
For single-column layouts, it can be useful to stretch or shrink the vertical space a little to improve the layout, such as to avoid widows or orphans. I don't know how Frame Maker handles this - TeX will do it automatically within certain limits, and let you manually specify it outside that. And as usual with spacing, it applies more of the stretch to larger spaces such as inter-paragraph spaces than to inter-line spaces.
That's a little different from what I am used to with TeX / LaTeX, which treats everything as a whole. (You /can/ make framed boxes like this - sometimes that's very useful - but it's not the usual method). But then, Frame Maker and TeX are designed to work in very different ways - FM is much more of a visual layout tool, while TeX has a strong separation between visual appearance and textual content, and runs as a batch process.
Manual modifications like that are always a pain, especially if the document may be changed later. But sometimes they are unavoidable.
I managed to get by for years without using a word processor at all - LaTeX handled everything I needed. But unfortunately that poses certain challenges for working with colleagues and customers who don't use it.
I had missed the point in an earlier post where you said /you/ were the typesetter...
Here's a few tips - and I'm aware that these might be considered "style choices" rather than "good typesetting rules", and that you might also have knowingly broken them because of the short line-length constraints.
Use non-breaking spaces in cases like "Mr. Bill", "N. Sixth", and "3:00 pm".
Be /very/ careful with a name like "Kirk - Bear". I can see that you might want to write it that way, with spaces around the hyphen, as a sort of logo. But avoid line breaks that have the hyphen on the beginning of a line, and avoid ending a line with the hyphen if a neighbouring line is also (automatically) hyphenated.
Your vertical spacing around the picture on page 2 is unbalanced, and I think the "Upcoming Activities" needs more vertical space.
Other than that, it is - as I said before - very well done.
There is a big difference between technical writing and publications with more specific layout requirements.
Technical papers need good typesetting so that they are easy to read - newspapers (and library newsletters) need to look good to attract attention and readers. So for technical writing, you want as much to be automated as possible, and you use a software-friendly layout (such as long enough lines so that bad line breaks are rare). For newspapers, it's okay to spend more time on "artistic tweaking" to make it look good.
I am a well-balanced person - I can't draw landscapes /or/ living things :)
On a sunny day (Wed, 22 Dec 2010 10:58:32 +0100) it happened David Brown wrote in :
Yep, ~/compile/scribus/scribus-1.3.3.7/scribus still on my system, don't remember why it did not work, maybe it did not compile because of 'other things' it needed. carried from disk to disk :-) Probably left it there for 'one of these days'. TB size harddisks make you do that.
It seems written in C++ ,maybe that is why I left it.... :-)
I would be surprised if a FrameMaker owner would switch to Scribus (not that I've used either, so my comparison here is based on third-hand knowledge and web sites). There are cases where free, zero-cost open source software is much better than expensive commercial equivalents, but I don't think this is one of them. This is especially in your case, where money is not an object (since you've already paid it), and long experience is a big point in FrameMaker's favour.
I am merely making the suggestion of Scribus for anyone wanting to try it. While I doubt that you would switch to using it, you may be interested in trying it for comparison.
I believe that what Ernie Lundquist actually said is, "No matter how much you dislike pickles, it is, after all, the only thing you can do with cucumbers." Your version is more logical.
I'm not a zealot. I don't want to make a career out of maintaining my tools (unless I have to) but, rather, want to use a tool to get a job done. *Now* -- not when they get around to fixing some bug that is standing in my way (note that this critique applies equally to commercial products -- perhaps even MORESO as you are entirely at THEIR mercy as to when and IF they will fix the problem!).
As I said, there are many things that FrameMaker *can't* do that VP could. I have publications that I did under VP that are *stuck* there because of many layout tricks I could coerce VP to do for me that FM's design precludes.
The problem I find with many "packages" is getting all the right cruft in place that the package depends on. In the UN*X world, you have to make a commitment towards a particular direction as everything BUILDS on everything else. By contrast, the Windows world rebundles (usually needlessly reinventing!) all the cruft that a particular application is likely to need *with* the application (hence the bloat -- in both cases).
If you just install a prebuilt package, you are putting your faith in the "builder" that he understood the various (inevitable) compiler warnings, dependancies, etc. and made smart choices about what to do in each case (too often, people just blindly build things and as long as make ends "successfully" they figure "all is well").
[I build every application on my UN*X boxen from scratch so I have a better feel for what *might* go wrong "in use"]
I'm doing my end of year "swap in/out" of hardware so maybe I'll just install a prebuilt version and play with it long enough to at least see what it does/doesn't (that way I don't have to make a commitment to the software beyond reformatting the disk)
OTOH, it also imposes constraints on what you can *do* in those "other columns". E.g., if you use a different size typeface you get weird side-effects as one tries to force the other to "comply".
FM gives you control over widows/orphans on a "per type" basis. So, you can change how "Heading Text" is handled differently from "body text", etc.
Likewise, you have constraints on the extents to which text within a line is stretched/compressed. But, you typically need to *see* how things layout before you can decide if those are appropriate "for this publication". (as I said, you can do things in your layout to COMPLICATE your life :< )
FM (and most other WYSIWYG DTP packages that I've played with) *loves* to break things into little "units" whenever it can do so without looking like it is being obsessive. :> E.g., each "cell" in a table has it's own specific formatting.
Nominally, the "table heading" (e.g., top row) cells have one format ("paragraph type") while the cells in the *body* of the table have another. E.g., how far to indent from the edge of the "cell", how to hyphenate, what typeface, tabstops, etc. These can be overridden for individual cells, the table full of cells, *all* cells (i.e., the "cell body" paragraph type), etc.
The "title" for the table (e.g., "Table 3-9: Common Insect Larvae found in Foodstuffs") is a separate type and "thing". *References* to that title are different things, etc.
This is hard to get used to until you think in terms of *other* publications for which it could be used (e.g., imagine laying out a "weekly sale brochure" for your local grocery store...).
Different DTP tools give you different ways of *using* this "meta-information". Commonly, you can build a ToC that just includes all "Chapter Heading"s. A list of figures that tabulates all "Figure Heading"s, etc.
FM, for example, will let you create cross references to instances of specific paragraph types. An obvious candidate is "Figure Headings" or "Table Headings" -- so you get "consult the illustration in Figure 23.5 on page 94" automatically.
Exactly. Though I think there are packages (lyx?) that wrap an interactive user interface around it.
I've just found DTP to be an inherently interactive process. You tweek one thing and see what else changes as a result. E.g., if I put a non-breaking space here to keep this phrase intact IN THIS INSTANCE, what gets munged in the *next* paragraph that I will need to "fix"?
I've disciplined myself not to use them. This may be a bit Draconian of a stand but it's too easy to forget where those "tweeks" are in a document. So, you could end up tweeking something right next to it as a result of that previous tweek (that you have forgotten about).
When things need that level of fine tweeking, I resort to rewriting the text to cause the "natural" (un-tweeked) appearance to be more acceptable (sometimes at the expense of more stilted prose :-/ )
That's why I opted on using PDF's for publications and notes. It's too hard to prepare things that others will be able to review AS YOU INTENDED THEM using other presentation formats.
The problem with non-breaking spaces (besides the fact that you have to *insert* them (i.e., replace the normal space with a non-breaking one) is they make that "phrase" physically longer (intentionally). I typically only do this selectively (e.g., a global "search and replace" -- possible in FrameMaker even with formatting stuff -- will often end up causing a problem elsewhere in the document. (short column widths really makes things tough!)
The bigger "problem", IMO, is my not treating "Kirk - Bear Canyon" (KBCN) more formally. E.g., the names of each of the sponsors are typeset in italics -- yet KBCN isn't.
On the one hand, you want to litter the text with "Kirk - Bear Canyon" to drive that home to the reader (this is, in a sense, a "sales pitch"!). OTOH, you end up with that much more italics in the document (which is already seeing lots of pressure as a result of book titles, web links, etc.).
This is probably a fault in the spacing associated with the "font"s design. "Display fonts" (i.e., the wacky, decorative fonts like the one I used for the "article titles") are often poorly built. I.e., these are the types of things you get in those "5,000 fonts for $9.95" packages.
There are "space above" and "space below" parameters for each paragraph type (e.g., "Article Title", "body text", etc.). These are conditionally applied and interact with their counterpart parameters in the "paragraph types" above and below.
There is an invisible "column top" created for the two leftmost columns on that page -- a consequence of the *bottom* edge of that photo *plus* any "space below" parameter that may be associated with the photo. This interacts differently (but consistently!) with the "Article Title" font at the top of column 1 and the "body text" font at the top of column 2.
(notice how the "Article Title" font lines up "correctly" in the top of column 3).
All I can do is play with parameters looking for a sweet spot that results in FM putting the text where you would like it in these two instances. Note that if I change the definition of the "Article Title" paragraph type, then it has consequences elsewhere in the document. (notice how "Summer Reading Program" does/doesn't appear to line up with a "baseline" *above* in the adjoining column)
That "article" was tough to format. Too many conflicting "things" in each of the items within (it is essentially a list of "mini-articles"). I.e., each "mini-article" (event) has a date, time (sometimes timeSPAN), title and "responsible party".
I felt people wanted to see them expressed chronologically (and NOT "by topic"). So, date was the key item, with the time being secondary -- and closely associated with date. Left justifying the date and right justifying the time ON THE SAME LINE seemed pretty intuitive and, for the most part, worked great! The reader knows what to expect, where.
The "title" of each tends to be long. Too long to tolerate anything else on the same line. So, the "responsible party" had to fall onto yet another line. I opted to right justify it as it would, otherwise, have NOT "set the title off" to draw attention to it *as* a "title".
So, we've got three lines of text before we get to the description (body) of the event.
And, you would need at least *one* line between events. If I had opted for more, it ran the risk of looking too "airy" (remember, the baselines of the text in the adjoining column force things to line up in nice clean multiples of the line spacing... so, put one, two or three blank lines between events -- not 1.5! :-/ Unless I also diddled with the fonts used for the title/date-time, etc.
If I had chosen to start that whole "article" at the bottom of the preceding column (i.e., 86 the little blurb about "subordinate Clauses"), then I would have had more space to play with -- but, still had to fight the "swiss cheese" look that would result (everything else in the document tends to have a "tightness" to it).
The biggest single problem with the layout is that it isn't very "senior friendly". The typefaces are too small, columns too tight, etc. OTOH, stepping up to a two-column layout (almost essential if you use a larger typeface for the body of the text) would have made the document a lot longer. (and printing and mailing costs disproportionately so) E.g., examine the "before" and "since" editions -- much looser layouts but a lot less *content*. (consider the last page is devoid of *real* content as it acts as a mailing label -- the newsletter is folded in half on the solid line)
It was my first "non-technical" publication. I try to make each new project a "learning experience". So, in that sense, it was a success. Just figuring out how to merge
*my* writing (and editing) with that of others without having it "obvious" was an interesting experience!
From the Friends' point of view, it was a *great* success as it attracted a lot of attention -- which, after all, was it's intent!
Yes. There is also the *intent* and "emotion" to consider. E.g., technical papers are intended to be (largely) "cool" presentations, dispassionate, etc. Informative. Rational.
Newspapers should (theoretically) be likewise -- though there tends to be more of a sensational aspect as they are in the business of selling newspapers -- making you *want* to read them.
Sales brochures, flyers, etc. want to be terse and hard-hitting. They want to generate excitement and/or irrational responses in the reader to "trick" (do I sound too cynical? :> ) the reader into parting with his money.
I recall hearing that grocery ads tend to emphasize *red* as red is psychologically associated with hunger (though I would be hard pressed to find that reference :< ).
Then you have no problem! :> I am puzzled at the inconsistency (and lack of rational explanation there for) in *my* skill set in this regard. One would assume that being able to draw a particular shape would be invariant of the thing *owning* that shape...
*Far* beyond my goals! I'd be thrilled being able to draw a good *outline* of a person... :-/
I went to an art exhibit last year and spent a full 30 minutes examining an oil painting of a native american *convinced* that it was a photograph. Short of *touching* the work (frowned upon!), I tried everything I could imagine to convince myself that the few brush strokes that *were* visible were not, actually, just a "clear, textured overlay" atop a traditional photograph.
Absolutely amazing to see people with "alternative skills"... especially when those are excellent!
[I want to meet the guy who invented SEX and see what he's working on, now!]
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.