Map comparisons for duplicates
I am putting this on the general listing in case there are others interested whom I do not know about, but this is directed specifically to Jonathan Osuch. There is a problem with map files. They work fine for coloring, and in all ways intended. The problem is in comparing for duplication. Two identical maps as far as color values and sequence goes will not show as duplicate if one of the maps has been cycled and then saved. Would it be possible to have fractint list the map file used in the par even if the par is saved with colors? This would provide a reference by name to the map used in the par. Or could fractint somehow place a stop bit (sync place holder) in the map files so they could be aligned in the editor with a key entry? The best solution would be a program which first would enter place holders within the map file so that all maps would be uniform, then run a comparison for sequence of RGB values regardless of place. In other words, if the only difference between two, or more, map files was the linear order of the same values, it would show as a duplicate. I wonder how many map files on people's drives are actually duplicates, with the only difference being sequence? Just a thought. David M Fisher sunfish@intercom.net
In article <001701c8189e$26900050$2f01a8c0@charlie>, "David M Fisher" <sunfish@intercom.net> writes:
There is a problem with map files. They work fine for coloring, and in = all ways intended. The problem is in comparing for duplication. Two = identical maps as far as color values and sequence goes will not show as = duplicate if one of the maps has been cycled and then saved. =20
You can solve this by writing a simple vbscript that cycles one map through all possible cyclings and comparing it to the other map. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
David,
There is a problem with map files. They work fine for coloring, and in all ways intended. The problem is in comparing for duplication. Two identical maps as far as color values and sequence goes will not show as duplicate if one of the maps has been cycled and then saved. Would it be possible to have fractint list the map file used in the par even if the par is saved with colors? This would provide a reference by name to the map used in the par.
Using the "recordcolors=comment" option does this as long as the colors have not been cycled. Is it possible to know that the palette has been cycled and no colors have changed? I'll have to look into this.
Or could fractint somehow place a stop bit (sync place holder) in the map files so they could be aligned in the editor with a key entry?
Possible, but difficult. I can see how to remember where the first color is, but writing this information to the map file will create a map file that can't be read by older version of Fractint. Not necessarily a big problem, but worth some thought. Jonathan
David,
There is a problem with map files. They work fine for coloring, and in all ways intended. The problem is in comparing for duplication. Two identical maps as far as color values and sequence goes will not show as duplicate if one of the maps has been cycled and then saved. Would it be possible to have fractint list the map file used in the par even if the par is saved with colors? This would provide a reference by name to the map used in the par.
Using the "recordcolors=comment" option does this as long as the colors have not been cycled. Is it possible to know that the palette has been cycled and no colors have changed? I'll have to look into this.
Using the "recordcolors=comment" option, I have gotten this to work with PARs when color cycling has been used but the palette has not been otherwise changed. The palette editor will take more work (and may not be possible to change correctly). I've also arranged it so that the original color map name is written to a saved MAP file when the palette has only been rotated. The current problem with this is that, in both cases, when these new PARs and MAP files are used, the original color MAP name disappears. Provided there are not a great number of PARs and MAPs in existance that currently have a color MAP name embedded in them, we can write code to read the color MAP name from the comment fields of the PAR or the first line of the color MAP file.
The best solution would be a program which first would enter place holders within the map file so that all maps would be uniform, then run a comparison for sequence of RGB values regardless of place.
And it would mean that all of the other applications that can use FractInt .MAP files would also need to be modified by their author's (and that is several programs).
Paul, We add PAR entries and change GIF data blocks with no regard for other applications that can use them, or older versions of Fractint. If we did, we would never be able to add new features. The method Fractint uses to read the color MAP data allows us to add text on each line after the data. We can add place holders (once we figure out how to keep track of them) after the data without causing problems for prior versions of Fractint. Jonathan
David M Fisher wrote:
The best solution would be a program which first would enter place holders within the map file so that all maps would be uniform, then run a comparison for sequence of RGB values regardless of place.
This is a really great idea!! But, as Jonathan already mentioned, it would not have any effect on the thousands of .MAP files that already exist. And with so many already available, no way to easily create a utility to update the older files, even if this was implemented today. And it would mean that all of the other applications that can use FractInt .MAP files would also need to be modified by their author's (and that is several programs). Too bad this had not been in place within FractInt at least 15 (or more) years ago.
I wonder how many map files on people's drives are actually duplicates, with the only difference being sequence?
In some instances, probably quite a few. Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
This sounded like a fun problem so I have whipped up a script which seems to do the trick. Instructions: 1) install the Python scripting language: http://www.python.org 2) copy the text below (between but not including the 'start script' and 'end script' lines) into a file and save it as 'mapmatcher.py' 3) open a command window and run 'python mapmatcher.py *.map' (You might need to specify the directory that python was installed in) It will (I think) list groups of files which differ only by rotation Good luck! ----start script--- # Usage: python mapmatcher.py *.map import sys import re rgb_re = re.compile(r'\s*(\d+)\s+(\d+)\s+(\d+)') def build_list(mapfile): colorlist = [] solid = (0,0,0,255) for line in mapfile: m = rgb_re.match(line) if m != None: (r,g,b) = (min(255, int(m.group(1))), min(255, int(m.group(2))), min(255, int(m.group(3)))) colorlist.append((r,g,b)) return colorlist def rotate_list_by(l,n): return l[n:] + l[:n] sets = {} for f in sys.argv[1:]: l = build_list(open(f)) min_list = l for i in xrange(len(l)): rotated_list = rotate_list_by(l,i) if rotated_list < min_list: min_list = rotated_list # min_list is now the canonical rotation # convert the list to a string since lists can't be used as # hash keys key = "%s" % min_list # add the filename to a hash indexed by the rotated list sets.setdefault(key, []).append(f) for (k,v) in sets.items(): if len(v) > 1: # some dups print "These files contain the same map:" print "\n".join(v) ----end script--- On Sun, 2007-10-28 at 14:43 -0500, Paul N. Lee wrote:
David M Fisher wrote:
The best solution would be a program which first would enter place holders within the map file so that all maps would be uniform, then run a comparison for sequence of RGB values regardless of place.
This is a really great idea!!
But, as Jonathan already mentioned, it would not have any effect on the thousands of .MAP files that already exist. And with so many already available, no way to easily create a utility to update the older files, even if this was implemented today. And it would mean that all of the other applications that can use FractInt .MAP files would also need to be modified by their author's (and that is several programs).
Too bad this had not been in place within FractInt at least 15 (or more) years ago.
I wonder how many map files on people's drives are actually duplicates, with the only difference being sequence?
In some instances, probably quite a few.
Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
participants (5)
-
David M Fisher -
Edwin -
Jonathan Osuch -
Paul N. Lee -
Richard