|
OK. I will wait with increased trepidation.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Can you plse give me your emailid so that i can discuss some more with u.I want to keep our discussions secret.
|
|
|
|
|
Just post a message for me here with hidden text. 
|
|
|
|
|
LOL.
This is the funniest thread I have ever read.
Did anyone notice the hidden poem?
|
|
|
|
|
Pallab_GT wrote: .I mean hiding the data in a text file without changing the file size even by a single byte and you wont see a single replacement/change/distortion in any of the letters of the file.As far as reading the file is concerned...the file will remain 100% unchanged even after hiding the data in it.
Ok so lets break your claim into this:
1) hiding the data in a text file without changing the file size even by a single byte
2) you wont see a single replacement/change/distortion in any of the letters of the file
3) As far as reading the file is concerned...the file will remain 100% unchanged even after hiding the data in it.
No problem with 1).
I see problem in 2): "you wont see" and "letters of the file" and 3) "As far as reading the file is concerned...the file will remain 100% unchanged"
"Text files are sequences of readable characters such as letters, digits, punctuation, or whitespace; and control characters such as section boundaries, rendering instructions for different languages, line feeds and carriage returns. Embedded information such as font information, hyperlinks, or inline images do not appear in text files, though references to them can be included within (such as HTML elements or metadata)."
(http://en.wikipedia.org/wiki/Text_file[^])
If you replace letter with different letters that *looks* same in some font, file is far from unchanged. Sure, person looking at it in notepad or whotever might not notice, but as far as reading the file for text editor, that is a difference. Sorry but if this is your idea it's close to using white font on white background
[ My Blog] "Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|
|
dnh wrote: it's close to using white font on white background
awww... that doesn't work????!!!???? Next thing you know you will tell me the Easter Bunny and Santa Claus are trickery too! 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
No Sir,thats not my idea.I am again claiming that "You wont see any change/replacement/distortion in any of the readable/printable characters in the carrier text file" after hiding the data and the the text file will remain 100% unchanged as far as reading the file is concerned.
|
|
|
|
|
The sneakest (well, not the sneakest - the sneakest way is to write a filesystem driver that modifies the information presented to the OS) way that I know of doing something like this is to use an alternate file/data stream.
This effectively hides data from the "naked eye", and its takes a little know-how to get at the streams.
Have a look here: http://www.heysoft.de/Frames/f_faq_ads_en.htm[^] for more information.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Can linked list be sorted in O(n) time? If yes, how? Thanks in advance!
|
|
|
|
|
Yes it can, but you need a parallel-processing system with n processors to do it:
1. Traverse the linked list and put the ith data item in a register in the ith processor.
2. On even time steps, compare the number in each even-numbered processor with its next-highest odd processor. If the two processors' numbers are out of order, swap them.
3. On odd time steps, compare the number in each odd-numbered processor with its next-highest even processor. If the two processors' numbers are out of order, swap them.
Step 1 is O(n). Steps 2 and 3 will repeat a maximum of n-1 times before the list is sorted, so are therefore also O(n). Therefore the total running time of the algorithm is O(n).
|
|
|
|
|
Hi,
any algorithm can do it in zero time with a single processor with infinite speed.
That is O(1), or should I say O(0)?
No need for parallel processing whatsoever. 
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Not in a general way, no.
If you can map your objects uniquely to the natural numbers [0 .. n), then you can do it in O(n) with a storage complexity of S(n). Create an array the size of your list. Iterate through the list, and put each object in its corresponding slot in the array. Then iterate through the array, and rebuild your list.
This places a really bad constraint on your contained objects of course. But that's one price to pay for trying to do the impossible.  (It has been proven that you cannot come up with a general sorting algorithm faster than n log n)
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Hi,
I've an image processing problem that I would appreciate any suggestion on how to tackle (ideally in c#):
Problem: I have a series of still images of circular discs (think audio CDs) captured from a video camera. Every time a disc passes the camera a still image is captured. The discs images contain text and graphics, the content can be considered random. When the discs are captured by the camera they are in a random orientation. I’m looking for an algorithm that will automatically rotate the image so that it is ‘aligned’ i.e. the majority of text (if any) is horizontal.
Any suggestions of what to try?
Thanks
|
|
|
|
|
Are the discs some solid color otherwise? Perhaps you could try drawing parallel lines through the image at ~15 degree increments from 0 to 165 degrees. Then compare the number of color changes along those lines. The fewer color changes, the more aligned your image. You could also try finding the center of the disc, then draw circles beginning from the outside. Once you hit something of a different color on opposite sides of the disk, you can compute the angle between them and rotate according to that. You may also want to try bluring the image to begin with, to make any lettering make a stripe of some color on the disk. Perhaps another idea is to pick a common rotationally asymmetric letter, such as 'e' since you know the language on the CD's, and try to find it on the disk. Compare the rotation of the letter to what you expect, and rotate the disk accordingly. These are just some of the approaches that I thought of sitting here, but I have never personally done much image processing. Good luck,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Using Audio CDs as an example the discs generally contain some text and some graphics... But the content is virtually random. I think one approach would be to separate the text from the image, work out the orientation of each string on the disc, then rotate the disc image so that the majority of the text is correctly aligned…
So maybe the question is: how do you identify text within an image?
Thanks for your thoughts…
|
|
|
|
|
There are actually two problems: Recognizing the alignment of an image, and rotating the image.
Recognizing the alignment depends on the image's features; it can't be done for random content.
For rotation there are a number of options. The simplest is to use the .NET rotation transform. A sophisticated algorithm that doesn't lose or distort pixels is described in a US patent by Thomas Sterling.
A common straightforward approach is to go through each pixel in the destination image, rotate in the reverse direction, and take the pixel at this location in the source image. This approach allows you to optionally blend with neighboring pixels for antialiasing.
Another approach that works well for binary images is to identify lines of consecutive pixels that are the same color in the source image's scan lines, then rotate these lines and draw them into the destination image. If the rotation takes a coordinate "far" from an integer value, a second line can be drawn to patch gaps that appear due to aliasing.
|
|
|
|
|
I happened accross the Levenshtein algorithm to find the fewest number of changes that can be made to go from one file to another, but I can't figure out how to find the PATH that resulted in that number without taking up O(n*m) memory. Is there some way to find the path WHILE you perform the algorithm? The way I am doing it now is to store the entire n*m array, then find the solution, then traverse the array from end to beginning to find a shortest path. Is there a way, using either another algorithm or by using the modification to Levenshtein where it only takes O(n) memory, where a least-cost change path can be found? Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
First you need to define "Binary". Is this a Binary object module with variable length instruction sizes and relative jump offset addressing, or is it a table of numeric data of fixed length?
Dave Augustine
|
|
|
|
|
I have two "files", which I know are made up of some number of bytes. I want to create a difference file that defines the fewest (or near fewest) changes required to convert one "file" into the other. By "file", I mean some finite stream of bytes. I don't know the format, and don't care. All I know is that one "file" was a previous version of the other, so the difference between them should be negligent. However, it could be a bitmap, a word document, a wmv, etc. I did NOT mean two executable files, although after reading your post I see how you came to that conclusion. Any ideas? Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
I don't understand the bit about "converting one file into the other". You already have both of the files. I seem to think that you want to keep only one file, and just the difference file to create the other one, just to conserve space. With software, the base is usually kept and differences are collected and then applied in a batch to create the new base. With binary files, however, you probably want to keep the current version and only have the differences to get back the original. This is like the U**X SED for binary, and in reverse.
If this is to be a generic solution for any such archiving, then the solution would probably be different than if it were for one specific file format, or maybe several different solutions depending on the file.
Tell me more about the files.
Dave Augustine.
|
|
|
|
|
Jeff,
I hate to double post, but why don't we move this discussion to another thread of yours because they are so similar. I just responded to your thread about finding maximum substrings. It was at the end of August and the beginning of September last year.
Dave
|
|
|
|
|
Yes, they are similar problems in that I am looking for similarities between two inputs. However, they both require quite different solutions. For example, when finding the longest matching substring, we can stop searching when we cut the potential matches down to the longest current match. Also, the applications are completely different. I was using the longest matching substring algorithm to find matches in strings that were usually smaller than 256 characters. I wrote an algorithm that I thought would be efficient in ONLY finding such a solution. To extend my current solution to find all matching substrings would truely bloat the algorithm, making it very much less efficient than the "dumb" method of doing this. Therefore, the other solution is not usable in this case because I need to find how to modify a string (of bytes) from A to B, and in my case A and B could be very large (say 4 GB) files, so I cannot use an algorithm that requires n^2 memory (such as the levenshtein algorithm that I currently have coded, which takes about 10 minutes for two 15 KB files due to paging the n^2 table in and out of RAM/Cache). However, I CAN afford n^2 time because I am planning on writing this to be a background process to archive old versions of files. These are the reasons why this is a separate post. Thanks in advance for any additional help,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Jeff,
Give me a couple of hours to work up the documentation on how to the the MaxStrings function to do a binary file difference. My code is already modified to support this, only the program needs to be changed to read two files instead of only one file for test case string pairs. I may be able to get that done as well. A good test case will be to compare the .EXE files from the first version with the second version.
Dave.
|
|
|
|
|
I have just completed my version to compare two files. I had created a program that just did the MaxSubstring function, and used the source and EXE as the files to compare against with the new file compare version of the files. It compares 161527 bytes to 57897 bytes (161KB to 58KB the source code files) in 1.079 seconds producing a difference file of 13KB. The .EXE comparisons were 41015 bytes to 36916 bytes (41KB to 36KB the .exe files) in .906 seconds producing a 15KB difference file. The algorithm could still stand some tweeking because my debug version (slower but outputs lots of data) shows some sections that consist of many replications of match 1 byte, 1 byte different, match 1 byte... Just addressing each of the differences (file locations and sizes) requires much more file space than the changes themselves. The algorithm is based on my version of the MaxSubstring function. To verify the result, I created another function that took the base file, applied the difference file, reconstructed the second file, and then did a file compare to verify that they were accurate. Are you still interested in the algorithm?
Dave Augustine
|
|
|
|
|
Yeah, I am definitely still interested! I have just been working on this as a side project in my spare time to try and learn a new algorithm/approach. Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
