#105785 - 2003-10-10 09:01 PM
KiXgolf: PxMagic
|
Sealeopard
KiX Master
Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
|
=============
The Challenge
=============
You are to create the PxMagic UDF Collection. This UDF Collection will read and display image files.
The challenge will be run as a private coding challenge from Friday, October 10, 3pm EST to Sunday, October 19, 9am EST. A second public coding phase will start on Sunday, October 19 and end on Sunday, October 26, 3pm EST. Specifics are provided in section "Specification" and "Inputs & Outputs". For the general KiXgolf rules, please refer to section "General Rules".
A download is available at http://people.bu.edu/jenmeyer/kixtart/kixgolf_pxmagic.zip
=============
Specification
=============
The PxMagic UDF has the following prototype
code:
Function PxMagic($)
EndFunction
The function PxMagic() relies on the two UDFs PxMRead() and PxMDisplay().
The function PxMRead() is used to read the image file provided to the function PxMagic as variable $.
The function PxMDisplay() is used to display the image file read via PxMRead in an appropriate way such that all colors are presented with their correct value based on the intensity value provided in the corresponding PxM file if the PxM file supports the intensity value (PGM, PPM). Otherwise, the image is to be displayed as a black-and-white image (PBM).
Important: PxMDisplay will need to display the finished image for 10 seconds before another image is being displayed.
All functionality of the UDFs must be contained within the FUNCTION/ENDFUNCTION commands. You are not allowed to call code located outside the mentioned three UDFs.
=============
Inputs & Outputs
=============
The PxMagic() UDF has a single input variable, providing the full path/file-name to the image file that needs to be read and displayed. It returns 0 for successful execution or alternatively an appropriate error code.
Input and output parameters for the other two UDFs PxMread() and PxMDisplay() are at the discretion of the coder.
================
PxM File Details
================
A PxM file can be one of the following files:
- PBM - Portable BitMap
- PGM - Portable GreyMap
- PPM - Portable PixMap
Thought he basic structure of all three formats is similar, there are some differences in order to accomodate different color palettes within the limitations of ASCII-based text files. Binary PxM file formats are not being considered as part of this KiXgolf challenge. For detailed information on PxM file formats, please see http://astronomy.swin.edu.au/~pbourke/dataformats/ppm/.
==========
PBM Format
==========
PBM is the portable bitmap format, a lowest common denominator monochrome file format. It was originally designed to make it reasonable to mail bitmaps between different types of machines. Now it serves as the common language of a large family of bitmap conversion filters. The definition is as follows:
A "magic number" for identifying the file type. A PBM file's magic number is the two characters "P1".
Whitespace (blanks, TABs, CRs, LFs).
A width, formatted as ASCII characters in decimal.
Whitespace.
A height, again in ASCII decimal.
Whitespace.
Width * height bits, each either '1' or '0', starting at the top-left corner of the bitmap, proceeding in normal English reading order.
The character '1' means black, '0' means white. Whitespace in the bits section is ignored. Characters from a "#" to the next end-of-line are ignored (comments). No line should be longer than 70 characters.
There is also a variant on the format. This variant is different in the following ways:
The "magic number" is "P4" instead of "P1".
The bits are stored eight per byte, high bit first low bit last.
No whitespace is allowed in the bits section, and only a single character of whitespace (typically a newline) is allowed after the height.
The files are eight times smaller and many times faster to read and write.
EXAMPLE:
code:
P1
# feep.pbm
24 7
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0
0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0
0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 1 0
0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0
0 1 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PBM files are:
ASCII or BINARY
black and white
2D
No compression
1 image
==========
PGM Format
==========
PGM is the portable gray map format. It is a simple grayscale image description. The definition is as follows:
A "magic number" for identifying the file type. A PGM file's magic number is the two characters "P2".
Whitespace (blanks, TABs, CRs, LFs).
A width, formatted as ASCII characters in decimal.
Whitespace.
A height, again in ASCII decimal.
Whitespace.
The maximum gray value, again in ASCII decimal.
Whitespace.
Width * height gray values, each in ASCII decimal, between 0 and the specified maximum value, separated by whitespace, starting at the top- left corner of the graymap, proceeding in normal English reading order. A value of 0 means black, and the maximum value means white.
Characters from a "#" to the next end-of-line are ignored (comments). No line should be longer than 70 characters.
There is also a variant on the format. This variant is different in the following ways:
The "magic number" is "P5" instead of "P2".
The gray values are stored as plain bytes, instead of ASCII decimal.
No whitespace is allowed in the grays section, and only a single character of whitespace (typically a newline) is allowed after the MAXVAL.
The files are smaller and many times faster to read and write. Note that this raw format can only be used for MAXVAL less than or equal to 255.
EXAMPLE:
code:
P2
# feep.pgm
24 7
15
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 3 3 3 3 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 15 0
0 3 3 3 0 0 0 7 7 7 0 0 0 11 11 11 0 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 0 0
0 3 0 0 0 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PGM files are:
ASCII or BINARY
Gray
2D
No compression
1 image
==========
PPM Format
==========
PPM is the portable pixel map format. It is a simple RGB color image description. The definition is as follows:
A "magic number" for identifying the file type. A PPM file's magic number is the two characters "P3".
Whitespace (blanks, TABs, CRs, LFs).
A width, formatted as ASCII characters in decimal.
Whitespace.
A height, again in ASCII decimal.
Whitespace.
The maximum color-component value, again in ASCII decimal.
Whitespace.
Width * height pixels, each three ASCII decimal values between 0 and the specified maximum value, starting at the top-left corner of the pixmap, proceeding in normal English reading order. The three values for each pixel represent red, green, and blue, respectively; a value of 0 means that color is off, and the maximum value means that color is maxed out.
Characters from a "#" to the next end-of-line are ignored (comments). No line should be longer than 70 characters.
There is also a variant on the format. This variant is different in the following ways:
The "magic number" is "P6" instead of "P3".
The pixel values are stored as plain bytes, instead of ASCII decimal.
No whitespace is allowed in the pixel section, and only a single character of whitespace (typically a newline) is allowed after the MAXVAL.
The files are smaller and many times faster to read and write. Note that this raw format can only be used for MAXVAL less than or equal to 255.
EXAMPLE:
code:
P3
# feep.ppm
4 4
15
0 0 0 0 0 0 0 0 0 15 0 15
0 0 0 0 15 7 0 0 0 0 0 0
0 0 0 0 0 0 0 15 7 0 0 0
15 0 15 0 0 0 0 0 0 0 0 0
PPM files are:
ASCII or BINARY
RGB color
2D
No compression
1 image
=======
Scoring
=======
You must read and correctly display all eight images provided in the test suite. The referee will test all submitted code by visual inspection of the displayed images. The final KiXgolf score is the sum of the KiXgolf scores of the three UDFs.
=============
General rules
=============
- The UDF must be written as one or more lines.
- The UDF is expected to finish in a reasonable time, e.g. if it gets started when the challenge opens, it's expected to be finished by the time the challenge closes even on a somewhat slow computer. The UDF has to be valid during the period that the challenge runs.
- You can submit scores as often as you want until the deadline, there's no reason to wait until the last minute for a score submission. In fact, other people want to see the score to beat. So don't be a spoilsport by hoarding your score. Submit early and often.
- The UDF may only use the KiXtart/KiXforms commands/functions/macros, no other code fragments are allowed. COM-calls that are part part of a standard default Windows installation are allowed.
- Calls to other executables, as long as they are part of a standard default Windows installation are allowed.
- The use of the KiXforms DLL is also permitted as the KiXforms DLL can now be considered an integral part of KiXtart scripting.
- The UDF should be self-contained (except for any I/O mentioned in the challenge). In particular, you may not do things like fetching extra data from a remote site.
- You may assume ASCII as character set.
- You are not allowed to use additional code that is external to the PxMagic UDF Collection. All code must be contained within the PxMagic UDF Collection.
When posting KiXtart Golf Scores, please include the KIXGOLF_PXMAGIC.TXT file that is created in the script directory. It contains some basic information about the computer that the script is run on and the resulting scores.
========
Deadlines
========
Private coding starts Friday, October 10, 3pm EST
Private coding ends Sunday, October 19, 9am EST
Public coding start Sunday, October 19, 9am EST
Public coding ends Sunday, October 26, 3pm EST
============
Test program
============
A test program is provided to help screen entries and to provide the Golf Score.
Any program that passes the test program can be submitted. If you are surprised that your solution passed the test program, please submit it anyway! That will help me identify bugs in the test program.
================================================================
KiXtart GOLF - How To Play
================================================================
Most importantly, anybody can play, no age restrictions, no penalties, no handicap!
The object in "real" golf is to hit the ball in the hole in the fewest strokes. The object in KiXtart Golf is to get from input (tee) to target (hole) in the fewest keystrokes.
Example: How many positive elements are in array $a?
Array $a could be of structure $a=[1, 2 ,-3, 4, -5, -7, 8, 9]
One approach:
code:
for $b=0 to ubound($a)
if $a[$b]>0
$c=$c+1
endif
next
for a score of 45.
Another solution is:
code:
DO
$b=$b+1
if $a[$b]>0
$c=$c+1
endif
UNTIL $b>(UBOUND($a)+1)
for a score of 53.
Better approach: Code sample 1
================================================================
KiXtart GOLF - The Rules
================================================================
1) The goal of KiXtart Golf is to score the lowest strokes.
2) Strokes are all characters in a piece of code except whitespace characters, unless the whitespace character is necessary for the line of code to work. Therefore, carriage returns and line feeds do not count or spaces in between the '=' sign when assigning variables, e.g. '$a = $b' scores 5.
3) Code can be constructed any way you like, as long as it is syntactically correct with KiXtart.
4) The final solution MUST pass all test scripts that accompagny the KiXtart golf challenge.
5) The use of '$' as a variable is allowed.
6) In case of questions about a particular way to count the KiXtart Golf Challenge organizer has the last call.
7) During the private coding phase, no code is allowed to be posted. Violations result in disqualification of said player.
8) During the public coding phase, code should be posted, reused, and borrowed from other players.
9) The test script contains the official KiXgolf scoring engine
================================================================
KiXtart GOLF - The Duration of the Competition
================================================================
1) Private coding phase: From date/time of posting the tournament challenge to Sunday, October 19, 9am EST (BBS+6 time)
2) Public coding phase: From Sunday, October 19, 9am EST (BBS+6 time) to Sunday, October 26, 3pm EST (BBS+6 time)
3) Final results: Sunday, October 26, 3pm EST (BBS+6 time)
You will need the complete package from http://people.bu.edu/jenmeyer/kixtart/kixgolf_pxmagic.zip.
_________________________
There are two types of vessels, submarines and targets.
|
|
Top
|
|
|
|
|
#105796 - 2003-10-11 04:26 AM
Re: KiXgolf: PxMagic
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
Jens, I like to solve problems and provide what sometimes I think are good scripting solutions. But I have to say I don't know a flipp'in thing about about images like how to display, convert or anything else other than pointy-clicky in IE.
Crikey! Not sure if I will be able to provide competition this go around but I will probably learn more about this stuff than I ever wanted to know.
|
|
Top
|
|
|
|
|
#105800 - 2003-10-12 07:09 AM
Re: KiXgolf: PxMagic
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11624
Loc: CA
|
Jens,
Maybe I'm wrong, but I thought the main idea of the Golf challenge was to see how small someone could code a given task, not figure out how to make a task work.
I'd love to participate, but I guess I'll have to wait till there is posted code.
I believe you if you say it can be done, but I have no idea how to have a native Windows app display the image. All the apps I know of open it as a text file not an image file or just won't open it period.
I've found a lot of code to convert the files to GIF/JPG using C but they don't seem too easy to convert to KiX.
Not sure what knowing the image colors has to do with the task. What good is knowing that each row is a list of colors and the header tells you the size, etc. Since most native apps want either BMP/TIFF/GIF/JPG I still don't know how to convert it to another format. I've seen the C code to do it, but it does not look that easy.
Maybe you could somehow use KF to display the given colors, but not sure if the image would really display correctly.
So... I'll just wait till someone show how to do it and then see how small I can code it. Maybe I can place 8 out of 8 players ![[Eek!]](images/icons/shocked.gif)
|
|
Top
|
|
|
|
|
#105801 - 2003-10-12 03:26 PM
Re: KiXgolf: PxMagic
|
Sealeopard
KiX Master
Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
|
I think you're overcomplicating things, especially with regards to converting into GIF/JPG or other file formats.
I'll insert my comments below without giving away too much. UDF 1 should be really simple, just read in the text file. UDF 2 is a little bit more complicated as it can involve the use of KiXforms or a second way. The second way is non-obvious but has a "doh!"-factor ![[Big Grin]](images/icons/grin.gif)
quote:
Maybe I'm wrong, but I thought the main idea of the Golf challenge was to see how small someone could code a given task, not figure out how to make a task work.
Task 1 is to read the text file into KiXtart. You already know it's an image file containing RGB colors for each point/pixel of the image. An image is a Width x Height array of pixels, with each pixel having a distinct RGB color, e.g. the row 1 column 1 pixel has an RGB color of &H000000, thus it's a white pixel.
quote:
I'd love to participate, but I guess I'll have to wait till there is posted code.
I'm sure you'll get your own code going for this ![[Smile]](images/icons/smile.gif)
quote:
I believe you if you say it can be done, but I have no idea how to have a native Windows app display the image. All the apps I know of open it as a text file not an image file or just won't open it period.
Yes, there is no way I am aware of that Windows apps can display the PxM files formats natively. However, one can use certain markup languages to create a display that contains colors. Also, these colors can be positioned on a per-pixel basis using certain markup language tags and the colors can be defined, e.g. as RGB colors.
quote:
I've found a lot of code to convert the files to GIF/JPG using C but they don't seem too easy to convert to KiX.
GIF/JPG file formats can contain the NUL character, thus they are not suitable for KiXtart.
quote:
Not sure what knowing the image colors has to do with the task. What good is knowing that each row is a list of colors and the header tells you the size, etc. Since most native apps want either BMP/TIFF/GIF/JPG I still don't know how to convert it to another format. I've seen the C code to do it, but it does not look that easy.
Why not use Excel to display an image? Just open Excel, select A1 and B2 and set the background color to black. Select A2 and B1, and set the background color to white. Result: A checkerboard image, especially if you make the cells equally sized squares ![[Wink]](images/icons/wink.gif)
quote:
Maybe you could somehow use KF to display the given colors, but not sure if the image would really display correctly.
If KiXforms can display colors and the color points/lines/circles are all equally sized, then the image should accurately represent the image, shouldn't it?
quote:
So... I'll just wait till someone show how to do it and then see how small I can code it. Maybe I can place 8 out of 8 players
I'm sure everybody will come up with something. Just remember to not overcomplicate things. And as this is more about coding than analyzing the tasks, I think it's fair if I give some help with regards to the way to solve the problems.
_________________________
There are two types of vessels, submarines and targets.
|
|
Top
|
|
|
|
Moderator: Arend_, Allen, Jochen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Mart
|
1 registered
(Allen)
and 496 anonymous users online.
|
|
|
![[Confused]](images/icons/confused.gif){kind=icon}
