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/
signature.asc
Description: This is a digitally signed message part.
