+++ Erin Lynch [04-03-01 20:18 -0800]:
Hi Wooks,
Just wanted to let you know that we're thinking about using Therion to trace contours and then writing a script to convert from Therion to survex legs.
Interesting idea. If you need this then maybe Therion should incorporate something like it more directly, although I'm not sure how exactly...
It should be doable, but we're having a few problems with our installation of Therion. The biggest one is that if you zoom in on a big map the whole thing just becomes unfeasibly slow. Dunks thinks it's probably making a bitmap (or something) of the entire image at high res, which is why it's so slow. Any ideas?
Yep - that's right, in fact there is more than one copy. I found the same problem. (on a 64MB machine attemting to zoom to 200% on a 4MB scan makes the whole thing disapear in a puff of smoke). Complaining to the Therion list elicited this explanation:
200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA buffer = 40MB = 60% of RAM. This may be a problem, especially on some operating systems.
The problem is that tcl's functions are used for the image management. tcl stores images internally as full RGB, so making them b/w or greyscale doesn't save any RAM, and it doesn't do anything clever like image-manipulation programs to only expand the visible tile. Something could probably be done to improve this but it's not trivial. This is a tradeoff of using a quick-prototyping language for the GUI rather than doing it the hard way. For the tme being you need to work with either a machine with loads of RAM or smaller images. Some work to see if TCL's handing can be improved in this regard would also be a good idea. I agree it's a serious problem, stacho doesn't seem entirely convinced yet.
The other problem is that the lines, control points and handles are all a bit too chunky to be useable. Any idea what magic rune we need to change in order to make them a bit smaller?
Nope - ask the list - they are _really_ helpful. (the ctrl modified lets you place points very close to other points which helps with the 'can't zoom' problem). cc:ed to Therion list Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
For the tme being you need to work with either a machine with loads of RAM or smaller images. Some work to see if TCL's handing can be improved in this regard would also be a good idea. I agree it's a serious problem, stacho doesn't seem entirely convinced yet.
No comment. You can try, if you do not believe. The only solution is writing Tcl extension in C...
The other problem is that the lines, control points and handles are all a bit too chunky to be useable. Any idea what magic rune we need to change in order to make them a bit smaller?
Will be configurable from xtherion.ini in the next release. S.
+++ Stacho Mudrak [04-03-02 16:28 +0100]:
For the tme being you need to work with either a machine with loads of RAM or smaller images. Some work to see if TCL's handing can be improved in this regard would also be a good idea. I agree it's a serious problem, stacho doesn't seem entirely convinced yet.
No comment. You can try, if you do not believe. The only solution is writing Tcl extension in C...
I didn't mean that writing it would not be difficult, I meant that the problem of not being able to zoom large images is a serious useability problem for real users (we have <10 I am aware of and two of them have complained already :-) . You suggested 'buy a bigger machine', which is OK up to a point but I'd much prefer making the software smarter. I realise that this is not easy. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Wookey wrote:
+++ Stacho Mudrak [04-03-02 16:28 +0100]:
For the tme being you need to work with either a machine with loads of RAM or smaller images. Some work to see if TCL's handing can be improved in this regard would also be a good idea. I agree it's a serious problem, stacho doesn't seem entirely convinced yet.
No comment. You can try, if you do not believe. The only solution is writing Tcl extension in C...
I didn't mean that writing it would not be difficult, I meant that the problem of not being able to zoom large images is a serious useability problem for real users (we have <10 I am aware of and two of them have complained already :-) . You suggested 'buy a bigger machine', which is OK up to a point but I'd much prefer making the software smarter. I realise that this is not easy.
On the other hand, would this be a good us of limited developer resources? The smallest machine I still use, my laptop, has 256Mb of RAM, and this is capable (just about) of handling a 10Mb gif of a >A4 scan. Admittedly, if you zoom to 200% it hits the VM system pretty hard (340Mb process size) but it is usable once you've waited for the scaling operation to finish. As time goes by, any efforts to support small memory systems will bring diminishing returns as average system sizes increase. Personally, I'd rather see effort to support other vector output formats such as SVG, which would be easier to import into other editing and publishing tools for further manipulation or inclusion in larger publications. Yours, John
+++ John Pybus [04-03-03 12:10 +0000]:
Wookey wrote:
+++ Stacho Mudrak [04-03-02 16:28 +0100]: You suggested 'buy a bigger machine', which is OK up to a point but I'd much prefer making the software smarter. I realise that this is not easy.
On the other hand, would this be a good us of limited developer resources? The smallest machine I still use, my laptop, has 256Mb of RAM,
OK, but I don't own _any_ machines with that _much_ ram (and I've got 5, excluding ARM machines and PDAs)! The only one I have access to with >256 Mb of RAM is the server here and that already jammed up against it's memory limits doing other things anyway. I can accept that my machine can't really cope with the 28000x16000 scan I tried to autotrace recently, but I think I ought to be able to zoom in on a 4MB image without it exploding (having doubled up my ram to 128MB I can now just about do that). Erin and duncan are in china and are skint - they are likely to be working with less-than-state-of-the-art equipment too.
Personally, I'd rather see effort to support other vector output formats such as SVG, which would be easier to import into other editing and publishing tools for further manipulation or inclusion in larger publications.
Fair enough, and of course Stacho can decide what he wants to do too - this is very much a 'scratch your own itch' project. I'm just asserting that the current limitations are a problem for me, and for Erin, and I think they'll bite quite a few others too. Obviously if no-one wants to actually do anything about it, then things will stay as they are, but it will affect the uptake of Therion. The other argument for better efficiency in this regard is using therion on small machines in the field, which is something I'd like to see be possible at some point, but that might require a move away from TCL anyway in the interests of efficiency, in which case this particular problem goes away/changes anyway. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
At 12:42 +0000 3.3.2004, Wookey wrote: *******************************************
OK, but I don't own _any_ machines with that _much_ ram (and I've got 5, excluding ARM machines and PDAs)! The only one I have access to with >256 Mb of RAM is the server here and that already jammed up against it's memory limits doing other things anyway.
TCL and RGB - TCL must calculate each pixel as RGB, mostly all monitors are RGB, BW monitors are exception. TCL must send RGB data to video. Wookey, I apologize myself, I know, I do quite different things on my comps (DTP, picture manipulations in Photoshop and so on.), but one of the best time saving investment in my life was to buy 1 GB (or more) RAM for each comp I use. We live in time when one may compare price of one RAM chip to price of beers drinked in one night ;))) . I remember many many times more expensive ones. Only several words from an old man :o)> Martin --
+++ Martin Sluka [04-03-06 09:48 +0100]:
At 12:42 +0000 3.3.2004, Wookey wrote: *******************************************
OK, but I don't own _any_ machines with that _much_ ram (and I've got 5, excluding ARM machines and PDAs)! The only one I have access to with >256 Mb of RAM is the server here and that already jammed up against it's memory limits doing other things anyway.
TCL and RGB - TCL must calculate each pixel as RGB, mostly all monitors are RGB, BW monitors are exception. TCL must send RGB data to video.
That's irrelevant - it's not TCL that sends the signals directly to the monitor - that's framebuffer/video drivers/X/video hardware. When working with B&W TCL could perfectly well use 1 byte or even 1bit image representations. I realise that it doesn't, but it still doesn't need to zoom all the image which is off-screen. Smart image manipulation software works in tiles to keep memory requirements sensible.
Wookey, I apologize myself, I know, I do quite different things on my comps (DTP, picture manipulations in Photoshop and so on.), but one of the best time saving investment in my life was to buy 1 GB (or more) RAM for each comp I use.
We live in time when one may compare price of one RAM chip to price of beers drinked in one night ;))) . I remember many many times more expensive ones.
That's only true if the hardware you have has the capacity for lots of RAM. My laptop can only have a max of 256 fitted, my desktop 512 the servers here 256 and 512 respectively. If you have to buy new motherboards (which means new cases - AT->ATX) new IO cards (ISA/VLBUS->PCI) and so on, then it is not simply the matter of the memory cost. I realise new hardware is relatively cheap these days but in this case (displaying a scanned image at arbitrary resolution) I don't believe the correct answer to crappy memory management in the underlying language is 'go and buy a new computer'. When you can't zoom a 4MB image to 200% on a 64MB computer with a virual memory system then the software is deeply inefficient and that should be addressed, not simply accepted. That way leads to massive software bloat. I can zoom the very same image several thousand pecent on the same machine using the GIMP, showing that it is perfectly feasible (which is obvious anyway of course). I understand that Stacho has better things to do right now than worry about TCL's crummy image-handling, but I can't accept the 'just buy a new computer' argument - we should have higher intellectual standards than that, and more to the point I don't have the money to splash around on new computers - I just bought one to play DVDs, so that's my budget for the couple of years spent... Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Wookey writes:
I understand that Stacho has better things to do right now than worry about TCL's crummy image-handling, but I can't accept the 'just buy a new computer' argument - we should have higher intellectual standards than that, and more to the point I don't have the money to splash around on new computers - I just bought one to play DVDs, so that's my budget for the couple of years spent...
I see following possible solutions: * invest a _lot_ of effort to overcome TCL's limitations. This may be only time-vaste if we would eventually reimplement XTherion from scratch -- see the next point. (It's like trying to upgrade an old car -- it's usually better and cheaper to buy a new one.) * rewrite XTherion from scratch in C++ or other non-interpreted language. This would also require great amount of work, but it could benefit from compiled and optimized code and a completely new design with all TCL-Xtherion's shiftiness in mind. We suggested some ideas for discussion a couple of weeks ago (link to http://labyrinth.speleo.sk on this list), but there was no response. If we could form a group of developers which would 1) discuss 2) implement it, we could have easy-to-use and efficient user interface. But this is possible only as a team work. * buy a better computer and use XTherion Any ideas? Martin
Hi Wookey, could you please test attached version of xtherion? I've slightly modified the image handling and it seems to be a little bit faster, when zooming large images... Please let me know, whether it has helped you. Regards, S.
We live in time when one may compare price of one RAM chip to price of beers drinked in one night ;))) . I remember many many times more expensive ones.
Indeed, buying RAM definitely is the way to improve computing performance and the time saved is well worth the money - but as Wookey says, buying RAM sometimes just isn't possible - if it's not your machine for example or is an older / laptop motherboard. I played with Therion a year or so back and like the idea, more or less drew a map before giving up and doing it by hand and tracing that in Photoshop. I've not used it since then (no time and no caves to draw!) although I've lurked here watching new developments. I've got a list of other things to do as long as my arm, but I would be prepared to spend a little bit of time helping to port XTherion to C++ (wxWindows?). It's certainly a very worthwhile project. Don't expect anything from me anytime soon though... -Matt
participants (6)
-
John Pybus -
Martin Budaj -
Martin Sluka -
Matt Ryan -
Stacho Mudrak -
Wookey