On Fri, Mar 12, 2010 at 1:05 AM, [email protected] <[email protected]> wrote:
>> The following are the basic features you need for a fax system: >> >> 1) manual start/stop >> 2) auto start/stop (switchable option) > > "Theoretically", it starts automatically when an APT start sequence is > detected. I do not know how to enhance the process at the moent. Maybe a > better filter. The APT frequency has some margin, but if it is too large, it > starts decoding each time 300 hz is detected in noise. So, the method > should be refined. You must have a mode where the automatic start/stop detection is disabled. Otherwise, some fax reception will falsely trigger starts and ends, particularly when the signal is weak. I agree that it is worth improving the automatic detection, but no matter how good that is, it will not remove the need for a fully manual mode. Particularly in this case, because your arrangement for horizontal alignment and skew is so perfectly implemented -- this fax system can receive any signal, no matter how weak and faded, as long as we can disable the automatic features. >> 3) auto home to top (switchable option) > > If the end of an image is detected, it is saved in a file (Whose name > contains the date/time and the frequency, by default in the directory > $HOME/.fldigi/images just like MFSK image files), and the image is emptied. I understand, but this action must be switchable to disabled. Otherwise, the image is erased from the display, and this is often (usually, in fact) not desirable. > I am thinking about automatic unslanting but first would > like to make basic things work. Honestly, the way you've implemented the slant, there is no need for an auto mode. This is the best unslant mechanism I've ever seen in a fax program (also the best horizontal align.) If you were to do anything here, if timer resolution allows it, it would be to add one more decimal place to the LPM widget, as the available precision can't quite get the image perfectly straight. Very close, but not correct. If this can't be improved, I can live with it. > So I prioritized the idea of manually > fine-tuning it in order to have a vertical image. I understand this could be > put in question. Nope. :) Please don't change this. As far as I'm concerned, you've arrived at the optimum UI for slant and horizontal alignment. And I've used a *lot* of fax software, not to mention having written a lot of it. > If LPM=120 which seems to be the most common cases, the width in pixels is > 904. For 120 LPM at IOC 576, use 1808 pixels / line. That will fix the round/egg issue. Here are two images received yesterday, scaled to 1808 horizontally... http://fyngyrz.com/wf1.png http://fyngyrz.com/wf2.png So either sample at 2x the rate, or just duplicate the sample so the image is twice as wide if doubling the sample rate is impractical. Another option is to discard every other incoming line, but this is undesirable as it loses significant details. > I can certainly add zoom in/ zoom out buttons. Is it what you mean ? Yes. Often, during reception, it is convenient to see only a small version of what is coming in. When the image is done, that's the time to enlarge the window and scale the received fax to 1:1. Larger than 1:1, say 2:1, is nice, but not a must. Smaller is highly desirable, though. >> 6) line mode (threshold the signal to b/w at 1900 hz) > OK. >> 7) grey mode - linear grey levels from black (1500 hz) to white (2300 hz) > OK. This is the current mode, no ? Yes. I was althgough thinking about applying > image enhagcement filters on -the-fly, but hesitated because this can be > done with image editing tools such as Gimp or Photoshop, and chose initially > to focus on pure "radio fax" features. Yes, I'd definitely vote to avoid this. Let the image come in as-is, and filter it later. Although I think filters from the community are highly desirable. Just a C code model that can be linked in, no XML or other complicated mechanisms. Just add a "filter" menu, hand us a pointer to the image data, define the XY resolution and pixel size and packing, and we'll do the rest. >> 8) reception to memory so display is never a restricting factor on >> resolution or sample rate > > There is not limit on the height of images: I just add a hard-limit of 10000 > lines because no reasonable fax should have this size (Most are about 1300 > lines). When this size is reached, an image file is saved and the image > cleared. My concern here is that during reception, if you move or resize the window, black areas appear in the image that never seem to be refreshed. Perhaps the data is there and this is a display code issue. >>> From there, a plug-in system for image processing operators would be >>> wonderful. > > Yes, I was thinking about adding xml-rpc calls. Ouch. Well, my vote is no XML, thank you very much. Really, all we need is a pointer and five chunks of data, and we can process the image without any further complications: a pointer to image base x resolution y resolution data size (word, byte, nybble) data packing (two nybbles/byte, etc.) packing order: I recommend (presuming nybbles in bytes): struct fimage: { word *image; // NULL if invalid, otherwise points to image in RAM. long xwidth; // ex 1808 long ywidth; // ex 1200 long pixelbits; // ex 4 long pixelsperword; // ex 4 long packingorder; // 0.W.X.Y (unused)(LR or RL within word)(LR or RL within line)(TB or BT within image) // packingorder ex in hex: 0000: (unused)(LR)(LR)(TB) [this is natural bigendian ordering) } >>> The displayed images and the file captures are stretched in the vertical >>> dimension. Circles appear quite egg-shaped. This may be more related to >>> the >>> station I was receiving than the program itself, but it would be cool if >>> there were some way to compensate for that. > > This is right, I will work on this. Again, I wished at first stage to focus > on pure fax features Just change horizontal sample rate to 1808 and it will fix itself. :) --Ben AA7AS _______________________________________________ fldigi-alpha mailing list [email protected] https://lists.berlios.de/mailman/listinfo/fldigi-alpha
