hedles

Hi Santu, >> want to create images with minimal file size using .net I've often wanted to do the same - basically because I keep a lot of scanned images and want to preserve my disc space. So I've done a fair bit of experimenting over the years to compare file sizes with subjectively equivalent quality. Nearly always it has come down to a choice between .jpg and .png. I haven't used OptiPNG plugin, though. I may give it a try. But simply by experimenting with the values that are presented in the PDN dialogues, I've found the following for scanned images: .jpg is nearly always the smallest option. .png is very occasionally smaller - usually, I have the impression, when the original has large blocks of identical colour - like a computer generated map, some Google maps, for example, but very often a .png can be an order of magnitude larger file size than an equivalent quality .jpg. To get optimal file size and quality one needs (obviously) to start with a picture that has an optimal number of pixels for the level of detail in the image. An A4 page of text, for example, scanned at 300 dpi, will often suffer almost no perceptible reduction in quality if you reduce it effectively to 150 dpi by reducing the image size by 50% (Image->Resize, By Percentage 50%). This, of course, reduces the number of pixels to be encoded down to one quarter 'right off the bat'. I commonly do this and then reduce the .jpg image Quality down to 25%. Any smaller than 25% seems to start introducing an intrusive blur around text making it more difficult/tiring to read. For this kind of image this usually seems to me to be about optimum (150 dpi .jpg at 25% quality). If you reduce the dpi much more than that, then the blur begins to hit at a much higher quality setting, so that what you gain, in having less pixels to encode, is more than lost in quality or in having to encode the .jpg at a less 'lossy' setting. For photographic images - depending upon the subject, you can often get away with a lower .jpg quality setting without much perceptible quality loss. It depends if you want to be able to print out the picture or view it or the screen. Typically you'll need a much higher quality if you want to produce a reasonable looking printed image. The brain seems to let you get away with a lot more on a screen before it shouts. If you do some experiments and come up with different values, I'd be interested to known what you find.

Rick, Thanks for your reply. Sorry, I did go on a bit. I just found that more and more explanations were needed as I thought around how the tool would work and what contingencies might arise. If you can read only from "My suggestion is for an new Transform Tool" down to the paragraph labelled Z., that gives the essentials of how I see the Tool operating. The rest is just footnotes. What I am trying to achieve: The essential problem is aligning two pictures - or rather two parts of the same picture (often including text) - that have been scanned separately and at minutely differing angles, so that one needs a rotation - usually of only tenths of a degree (or they don't line up properly all over) as well as a vector shift into place. I got into using Layers->Rotate/Zoom to achieve the rotations because mouse movements didn't provide fine enough control with rotations using RMB with Move Selected Pixels. It's not so much a question of lack of a rotate lollipop (if I understand correctly what you mean by that), simply that mouse movement doesn't cut the mustard, whereas precision control down to 100ths of a degree does. The problem is that it usually takes many trials to get the rotation spot on and that takes a lot of time - especially on my very old desktop computer which is maxed out at 384MB! (I know. I need a new computer!) What has hit me - over and over again - is that if only I could define a rotation, not by the numerical size of the angle, but by actually mapping where two pixels were each to start from and to end up, then the rotation would be correct first time, every time - and any shifting required would be achieved in the same operation. Then I realised that (unless one was very careful - or lucky! - in the selection of the two pixels and their destinations) this transform would most likely need to include a scaling as well as the rotation and the shift. Well that was all to the good, if the pixels ended up mapping correctly from picture to picture. From there the idea morphed into a generalised morphing tool, which maps any number of pixels each onto a destination point, and lets the maths apply any scaling and stretching (rubber sheet geometry) that was needed. I'll see if I can get together an example or two to post. Thanks for listening.

Background and reason for request: I frequently find myself 'stitching' together parts of a picture that I cannot scan in one operation on my scanner. It often takes 'forever' to align a new part of the picture to the growing montage. The technique I use is to add the new part of the picture as a new layer, adjust its opacity so that I can see through to the layer below, then keep making successive trial/partial adjustments (Shifts (move selected pixels), and Rotations (Layer Rotate/Zoom) and sometimes also scalings) until I achieve an alignment that I am happy with, before re-maximising the opacity, possibly trimming off part of the overlaps and then merging the new layer down to the existing picture. If there is a better/quicker technique for achieving this then I would welcome enlightenment! If it were possible to adjust the position (and possibly scale) of a layer/selection by selecting pairs of locations - first the source pixel to be moved, followed by its destination - then having the program perform this in one operation without having to drag or step (with the arrow keys) the layer/selection, it would enormously speed the desired transform. Failing that, or anyway . . . My suggestion is for a new Transform Tool that works as follows: 1. With a selection (which might be a whole layer), choose the Transform Tool. A small dialogue box appears labelled "Transform" with a "Transform" button and a "Cancel" button. 2. Depressing the Ctrl key the user clicks on the first source pixel, which is then highlighted by a nub. (The source nub can be relocated at this point, by repeating the operation.) 3. Depressing the Alt key the user clicks on the destination for the first pixel which is then highlighted by a second nub. (The destination nub can be moved at this point, by repeating the operation.) An arrow appears between the two nubs representing the vector from the source pixel to its destination. (At any point after an arrow has appeared, it can be a. moved (without change of orientation) by i dragging it from between the nubs, or ii selecting it with a left (double?)-click and using the arrow keys to move it one pixel at time; b. adjusted by i dragging either of the nubs to a new location, or ii selecting one of the nubs with a left (double?)-click and using the arrow keys to move it one pixel at time; c. deleted (by right-clicking on it?); d. undeleted (if performed before any other operation since it's deletion), by right-clicking again (with the shift key depressed?) ) X. If the "Transform" button is clicked (or the Enter key is pressed) after just one source-destination pair is defined, then the pixels selected to be moved shift just like a move operation without any rotation or scaling. The operation is complete: the Transform dialogue exits. If the "Transform" button is not clicked at this point, . . . 4. A second pair of source and destination pixels may be selected in a repetition of steps 2. and 3. Y. If the "Transform" button is clicked (or the Enter key is pressed) at this point then the selection is transformed so that the two source pixels are relocated to their respective destinations, applying, to the whole selection, any rotation or scaling necessary to achieve this. The operation is complete: the Transform dialogue exits. If the "Transform" button is not clicked at this point, . . . 5... Further pairs of source and destination pixels may be selected. Z. The "Transform" button is clicked (or the Enter key is pressed) and the selection is 'morphed' so that all the source pixels are relocated to their respective destinations, applying, to the whole selection, any rotation, scaling and stretching necessary to achieve this. It should not be necessary for a source pixel to be a pixel within the current selection. It could be a 'virtual source pixel' and mapped onto a virtual destination, but this vector would contribute to the transform generated just as if the current selection filled the whole canvas - however, only the area of the current layer within the current selection would be affected by the transform. In any case where a transform carries pixels at the boundary of the current selection into the interior of the selection, one would have to take a view on (or provide an options to select) whether, a. the boundary itself is 'morphed' by the transformation so that the selection changes shape under the transformation and, if so, whether pixels carried from the selection boundary are i 'torn' from the boundary (producing an area of transparency in the transformed layer between the old boundary location and the new boundary location), or ii 'stretched' from the old boundary to it's destination (producing a sequence of pixels the same colour as the stretched pixel), or iii the gap between the old boundary and the new boundary of the selection is filled by pixels that have 'escaped' from inside the old selection and remain in their original locations (thus producing an area where some pixels which have been mapped onto and represented in a new position within the new selection boundary, are also mapped onto and represented in their original position within the original selection, but outside the morphed selection boundary), or, b. the selection boundary remains unaffected by the transformation and, if so, whether pixels carried from the selection boundary are i 'torn' from the selection boundary (producing an area of transparency in the transformed layer between the selection boundary and the new location of the torn pixel), or ii 'stretched' from the selection boundary to it's destination (producing a sequence of pixels the same colour as the stretched pixel), or iii the gap between the selection boundary and the new position of the pixels carried from the boundary is filled by pixels that have been 'imported' by the transformation from outside the selection (thus producing an area where some pixels which are still represented (in their original positions - outside the selection), are also mapped onto and represented in an area within the selection), Note that: Once the selection is deselected following the transformation, the visual effect of a.i above would be indistinguishable from b.i, likewise a.ii and b.ii, but a.iii would produce a different result than b.iii. The Click of the "Transform" button ("Transform Pixels") and the defining of the transform vectors ("Define Transform") ought to be distinct operations in the history window. This would permit a trial operation to be quickly and easily adjusted if it did not quite achieve the desired effect, by undoing the Transform Pixels operation and thus leaving the user with all the previously defined transform vectors ready to adjust. It might also be useful for the Transform Tool to keep a history of (at least one) transform(s) so that (this)these could be selected for reapplication to another selection. If only one transform were kept in the history, then another button, "Retrieve Last Transform" would be useful in the Transform dialogue box, which would leave the user ready to adjust, if desired, the vectors of the last transform before clicking the "Transform" button. If many, then a dropdown listbox would be useful, that were used to select transforms by name, blank when the tool is invoked so that the user can either go ahead and start defining transform vectors, or can select a previous transform from the dropdown list by name. Unless otherwise entered, a default name would be created (starting with "1", "2" etc.) when the "Transform" button is clicked. To create a copy of an existing transform to work with, any time the original is selected just type a new name in the dropdown selection box and press the Enter key; Or whatever is in the dropdown selection box when the "Transform" button is clicked will be the name of the new transform. To rename a transform create a copy, change it's name, press Enter and then delete the original. To delete a stored transform, highlight it in the dropdown list and hit the delete key. (An undoable operation?) Should transforms be saved in a PDN file? . . . saveable in some other file? Again, if there already exists a plugin or some such that provides something like this functionality, I would be pleased to be enlightened.

Background & reason for request: When working with selections - particularly when adding multiple Magic Wand selections to build the selection required - it can be difficult to see clearly (from the shading and outlines which show the current selection) what is selected already and what isn't - particularly at some zoom levels and depending upon the colour(s) of the pixels that you are working with (blue-greys, for example). My suggestion, therefore, is that in any of the Selection tools, while you are holding down either of the modifier keys Ctrl or Alt (which would modify the Selection Mode of any further selection to Add or Subtract mode), all currently selected pixels should be temporarily highlighted - overridden by a single colour (say, your current primary colour?) with the shading (and outlines?) that normally depict the currently selected pixels removed. This would make it easy to visually confirm exactly what pixels are currently selected. Perhaps the removal of outlines ought to depend upon the magnification that is currently being used: at high magnifications where each pixel is depicted by a relatively large screen area and the outline can be easily distinguished from the interior of each pixel, then outlines (perhaps of your current secondary colour?) might help to define the selected area, but where pixels are very small it might be best to remove them. Also, as a visual indicator/reminder of the modification which the modifier key will make to the effect of the next selection - and one that is slightly larger than the minuscule plus or minus sign that appears in the mouse pointer - would it be easy to temporarily override the Selection Mode symbol showing in the tool selection toolbar, with the symbol for the modified effect, whenever the modifier key is depressed? . . . Not forgetting that this symbol ought to change again if the Right Mouse Button is used instead of the Left. If the above is easy, then, in the Magic Wand tool, could the Flood Mode symbol in the tool selection toolbar be similarly temporarily overridden with the Global Flood Mode symbol, when the shift key is used to override Contiguous Flood Mode?

Why is it that when I open a multi-page .TIF document, I can only see the first page? This behaviour is common with MS Paint, but MS Windows Picture and Fax viewer shows all the pages.

In another post in the troubleshooting category, I recently wrote What I am trying to do is to add road names to a street map. The nature of the task is such that 1. I need to cover as much area as is feasible in each map/file 2. I need to get in quite a lot of detail on the maps 3. the final map files need to be small enough to easily transmit by e-mail Obviously, there is something of a trade-off between these three objectives. One of the results is that the text I write the street names in has to be a fairly small point size - around 8 pt text is what I am using. That, in itself is no problem, but because roads don't all come obligingly East to West, i.e. horizontal on the map, I need to be able to write the text at any random angle. The snag is, when I use the Layer rotate/zoom tool, the pixels in the text get 'blended'(? = smoothed out by adding grey pixels at the edges) and because of the small point size, this makes the text almost unreadable- joining letters together and filling in loops etc. I've tried using various adjustments and effects (e.g. the Levels adjustment and the sharpen effect) to tidy up the result but it is a very long process to get an acceptable result and I usually end up editing the output on a pixel by pixel basis. Is there any simple way either to write text (in pure black) at predefined an angle or to stop the blending effect as an object (the text) is rotated? Or can anyone suggest a better way of doing this? Ideally, what I'd like is the ability to be able to write text at any angle or, better still, along any predefined curve (roads are not alway straight!). Would anybody else find such a plugin of use? I don't have a clue how to go about writing one right now. At present, I'm actually finding it quicker (but still too time-consuming), easier and producing a better (but still far from a good) result to create the text in MS Excel (text in any cell can be written at any angle with single degree increments), then to capture the output from the screen as a .jpg, import this into PDN and then merge it down onto the map! Thanks for any advice. BTW I've had a search through most of the plugins that are published here but I haven't seen anything that I think might help.

All seems to be working much according to the documentation in RC1. Thanks.

Thanks for the clarification, Rick. I'll download RC1.

OK. I seem to have found a bit of a pattern. Adjusting the input sliders DOES have an effect AFTER I have already rotated the text. Before I rotate the text it has no visible effect at all.

Thanks for PDN. It is a really great program! I have just started to explore some effects and adjustments. I found the levels adjustment, yesterday and it seemed to do almost exactly what I needed. But today, it doesn't seem to do anything! All I am trying to do is to set the input black point to a higher value so that I can adjust text I have written to be (almost) completely black. Today whatever I do with the input levels controls it has no effect on the image. (Adjusting the output levels, however, does have an effect.) I am using v3.30 Beta 2 (build 3.30.2993.35482). I note in topic Malfunction of Levels Adjustment, viewtopic.php?f=10&t=23215&start=0&st=0&sk=t&sd=a&hilit=levels, that Rick Brewster wrote: regarding the problem in which the sliders did not move when the spin button was used.I don't know if by "next update" Rick meant beta 2, but, if so, it still doesn't seem to be working for me. BTW, the reason I needed to use the levels adjustment was to darken the text after it had been rotated, because it tends to blur when you do this and is nothing like so readable. Is there any way to write text at an angle in the first place? (Has to be any number of degrees, not just 15 deg increments to be any use for my application.) Also is there any way to keep text completely black, both when you write it and when you rotate it?