Queries and comments on 0.2.17
m.b at speleo.sk
Mon Feb 16 09:29:16 CET 2004
> I have put a picture of a screen shot of the scrap join and the resulting
> PDF image online to illustrate how one scrap cuts off parts of the other at
> the join - how should this be done to produce a satisfactory effect?
You may use `-clip off' option for all objects which shouldn't be clipped by the scrap border. However, it would be best to choose places for scrap joins where the passage is as simple as possible -- this saves a lot of work on defining IDs and joins for each object lying on the scrap join line.
> Therion generates an error. 'invalid object name', but some more research on
> the various options shows that I get:
> join farside at river farside2 at river
> works OK (except that it joins one (the south) wall of farside2 to a nearby
> column (the nearest wall) which is just wrong.
> join farsidewest1 at farside.river farsidewest2.farside2 at river
> Gives 'survey farside.river does not exist' - which is right but I mean
> scrap farside within survey river - have I got the syntax wrong?
Scraps don't create own namespace -- only surveys do. So
join farside at river farside2 at river
is a variant of join which joins two scraps, and
join farsidewest1 at farside.river farsidewest2.farside2 at river
join farsidewest1 at river farsidewest2 at river
>> >If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm >file)
>> >Is this expected?
>> 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.
> OK. So there is a need for original scans to be quite small, or lower colour
> depth (I have to scan greyscale because my scanner/software does not work
> properly in b/w). Now I'll reduce the colour depth of all the images and
> maybe chop them up for therion editing, because zoom is important and it's
> _very_ slow to load. I also just bought 128MB more ram, which should help.
I'm afraid TclTk uses RGB model internally, so it converts even b/w images into RGB anyway.
I've been using XTherion on Athlon 2000 with 512 MB RAM. It works quite well and fast with more 100 dpi scans in one file (about 1000*500 pixels each) @ 200% zoom.
> And because it takes 2-3mins to load again I don't like unloading and
> loading it each time to make an edit. Smaller scans will help, as will more
> memory, but there does need to be a better way if drawing a survey is to
> take less than 100 years :-)
We are fully aware of the fact, that XTherion and espacially TclTk language is not ideal. It would be nice to make a completely new interface (which may be devoloped parallel with therion and xtherion), but it would require a lot of help from other programmers, too. We've put some ideas on
More information about the Therion