I've done the following:
1. edited win32config.h - replaced the version definition toward the end
with "cvs20080123 built by Yuv"
2. renamed license files for consistency and added .txt at the end of
all text files so that on Windows they do open with a text editor.
3. rewritten README.txt with emphasis on experimental and unstable nature.
4. Ippei is right: license should not bother users, only distributors
and developers. I've applied this principle for as far as I found it
applicable to a text file / distribution of CLI tools.
For a GUI based distribution and for an installer / dmg, I suggest
limiting all licensing blah blah to the two sentences in the LICENSE
section of the rewritten README.txt. It will still require a click to be
dismissed, though, but chances are that it will be also read.
I linked the distribution from
<http://panospace.wordpress.com/downloads/>
comments welcome.
next: how to do the same for the OSX version?
Yuv
panocanarias wrote:
> beside renaming, what changes did you incorporate?
> [ compared to enfuse pre3 version, linked on wiki page ]
all changes that have been checked into the repository until this morning.
Yuv
It seems the ContrastWindowSize parameter was added, and that HardMask
was sped up. Also, the bug were colored patches appeared with non
perfectly overlapping images was fixed (all of this for enfuse).
So it makes sense to download and test this new alpha version.
http://enblend.cvs.sourceforge.net/enblend/enblend/src/enfuse.cc?r1=1.4&r2=1.6
Cheers,
Seb
Most importantly:
The bug that limited the windows version of enfuse to blend only 6 (or so)
images and the problems (weird colors) with slightly non-overlapping image
parts have been fixed.
The Hugin SDK v2, which Yuv used includes a libtiff that supports LZW as well.
ciao
>
> Klaus
> >
>
you may always ask, and sometimes there is somebody who has the time to
give an answer. Seb has given you a good one, and Pablo added even more
information - better than anything I could have ever told you.
Allow me to give another answer. Longer and slightly ambiguous, I hope
it will help you understand so that next time you can help somebody in
the same situation:
<http://panospace.wordpress.com/2008/01/23/new-enblendenfuse-snapshot-for-windows/>
Yuv
Yuval Levy wrote:
>
> Allow me to give another answer. Longer and slightly ambiguous, I hope
> it will help you understand so that next time you can help somebody in
> the same situation:
>
> <http://panospace.wordpress.com/2008/01/23/new-enblendenfuse-snapshot-for-windows/>
Why link to the CVS list but not include the ChangeLog? For enblend, the
Changelog is a good resource. Also, the Changelog is automatically in sync
with what you distribute.
For hugin I used to use svn2cl to extract it from the svn changelog message,
but that fails with a SVN error now.
ciao
Pablo
Pablo d'Angelo wrote:
> Why link to the CVS list but not include the ChangeLog? For enblend, the
> Changelog is a good resource. Also, the Changelog is automatically in sync
> with what you distribute.
the link to the CVS list is just a "forensic link" in an article
explaining to a user how to investigate further when the short answer
"every change until checkout" is not enough, and how builders get
informed when it is time to build again.
I did not include a ChangeLog at all in my snapshot. With that I mean
the ChangeLog file that is in CVS. I also do not intend to put one at
this stage. Reasons:
1. testers should run a test suite no matter what changes happened. Some
things that worked before might be broken now, or the other way around.
Providing a ChangeLog is an incentive to try new features and corrected
bugs, while assuming that everything else works. If you want tester to
test something particular, you can ask for it here.
2. some of the changes documented in the ChangeLog file do not apply. I
did not include Erik's droplets in this distribution. It is a bare
binary distribution in archive form for testers. Testers know where to
get Erik's latest droplets from, and they know to place all files in the
right place.
3. I find the ChangeLog file long and confusing. I wonder if Klaus would
have found in it the answer that Seb and you gave him. So for testers I
would not put any ChangeLog becuse of reason 1 and for users I would put
in a human-edited "what is new in this release" for every release.
I propose testing such a "what is new in this release" when we are at
the beta or release candidate level. At that point we hopefully have one
installer that puts binaries, droplets, documentation, etc. in place. It
will probably be the hugin installer anyway, or do you want to provide a
separate installer for enblend?
Yuv
Yuval Levy schrieb:
> Hi Pablo,
>
> I propose testing such a "what is new in this release" when we are at
> the beta or release candidate level. At that point we hopefully have one
> installer that puts binaries, droplets, documentation, etc. in place. It
> will probably be the hugin installer anyway, or do you want to provide a
> separate installer for enblend?
There is one in win32/msi (needs some more polishing to create shortcuts on
the desktop, though), and its addition is documented in the ChangeLog.
Good night,
Pablo
> I linked the distribution from
> <http://panospace.wordpress.com/downloads/>
I've updated the download link on the wiki page to point to that
page.
best regards
Erik Krause
http://www.erik-krause.de
I think it will need a complete overhaul so that people who run the
hugin installer and the enblend installer won't get confusion on their
machines.
Yuv
thanks. I'll either need to add your droplets to the distribution, or
add a link to the droplets from there.
What do you prefer?
I have not linked to the URLs you published here as you requested.
Yuv