Hmm.
I'm not buying in on many of your arguments here.
I don't know enough about this particular change in Enfuse. Was the
decision to treat all pages of multipage TIFF files equally taken with
a clear understanding of the repercussions of that choice?
Certainly it is not the case that all pages will always be of equal
importance to the user. Like I say, I wasn't "around the table" for
the discussion. But I *have* been around other tables, discussing
other things. And this decision sure has the flavor of an
enthusiastic developer implementing what they personally wanted/
needed... without (sorry) "thinking about it a bit further."
Programmers, especially programmers of Open Source tools, build things
that "ordinary people" (that is, non-programmers) will use. Over the
years, I have encountered far too many programmers who are very very
sensitive to having their work criticized. A reaction of "Go fix it
yourself!" is disingenuous -- ordinary users are *not* programmers and
can't fix it themselves.
eo
On Sep 13, 2010, at 6:52 AM, Yuval Levy wrote:
On September 12, 2010 05:01:21 am Erik Krause wrote:
Am 12.09.2010 08:51, schrieb Harry van der Wolf:
You can also use tiffsplit to split your tiffs first.
Hmm, an additional step that wouldn't be necessary if the programmers
would have thought a bit further...
You might be surprised to find out that the "programmers" (I
actually prefer
the term "contributing users") actually did think further.
No Free software contributor expects a turnkey solution for his
problems from
another contributor. But Free software contributors expect to be
treated with
respect. The above statement belittles the work of all those who have
contributed to getting enblend-enfuse where it is now.
The current solution, while not claiming to be perfect, enables GIMP
users of
multi layered documents to access their TIFFs directly - unlike
Photoshop
users who need to run their PSD through an extra step like your
script [0].
Users of PSD files would surely deem as incomplete any software that
ignores
Photoshop layers other than the background layer. Similarly, users
of GIMP
deemed enblend-enfuse incomplete and improved it.
Can it be further improved? of course. Nobody claims perfection.
Workarounds
and patches are always welcome and *if the existing / suggested ones
are not
reasonable for you, you are free to contribute alternatives*.
This should have been an option, not the default behavior in order to
keep compatibility and for ease of use. Or at least there should be a
parameter to deliberately choose the page.
Processing PSD layers is the default behavior of most modern
applications so
why should the default for TIFF layers be different?
Would you suggest that in order to keep backward compatibility and
*"ease of
use"* any application importing PSD files should default to import the
background layer only?
On the last sentence of the statement I agree: a parameter to
deliberately
choose the page would be a neat improvement. Those who need it can
work on
it. A good starting point is to expand on the syntax of the command
line and
of the response file [1]. How would you identify which layers to
use and
which to ignore? Next would be implementation, starting around line
1587 of
[2]. Patches welcome.
In my opinion enfuse 4 got far too complicated for most users. I
recommend using version 3.2 instead and in most cases this solves
problems. Same applies to enblend...
If staying behind works for you, it is a reasonable and legitimate
alternative
for you. Good for you. You can even fix 3.2 issues such as the
horizontal
lines artifacts which in my experience are gone from 4.x
What has worked well in the past is not necessarily the best
solution for the
future. It is a legitimate personal choice to stay behind. It is
not a
legitimate choice to force everybody else to stay behind with you.
Version 3.2 still lives in the repo [3]. You have write access to
the repo.
Nobody prevents you from branching out and improving on 3.2 if you
think so
negatively of 4.0. Anybody is free to branch out there (or anywhere
else) and
continue 3.2 development, fix 3.2 bugs, improve 3.2 any way they see
fit if
they don't think that 4.x was the right way to go. So far all
contributing
users have been adding to 4.x, an act that speaks for itself.
The added complexity of dealing with layers is not an enblend-enfuse
problem.
It is a garbage-in garbage-out problem that is solved upstream by
adequately
controlling the output of the upstream software and/or specifying
the input to
enfuse.
This discussion reminds me of another recent negative complaint/
suggestion in
a completely different setting [4]. It is easy for a *consumer* to
argue
against higher security for a web-based app in the name of *"ease of
use"*.
Tell that to the admin who has to "easily" sort out all the spam
after an
account has been compromised. The positive, forward looking
solution in that
case would be to implement OpenID login [5], and a *contributing
user* could
just mention that or provide a patch against the web app code if the
source of
that app is available to be patched.
Yuv
[0] http://www.erik-krause.de/ttt/index.htm#Photoshop%20Actions
[1] http://enblend.sourceforge.net/enfuse.doc/enfuse_4.0.0.xhtml/Response-
Files.xhtml#Response-Files
[2]
http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/file/77fbc2c95fb5/src/enfuse.cc
[3] http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/rev/b159234a5d59
[4] http://groups.google.com/group/krpano/msg/5904056e7c81a8b2
[5] http://openid.net/
--
You received this message because you are subscribed to the Google Groups "Hugin and
other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
