• minini (unregistered) in reply to kastein

    actually, not too bad. ok, they could have used something better than xml, but recording the series of coordinates is a good thing to do, since the way the signature is written contains additional information. just like for most handwrite recognition systems that use stylus or other pens, they use the direction of drawing too

  • Ryan (unregistered) in reply to ContraCorners
    ContraCorners:
    >> And not the "everyday" things like the gargantuan ladles that carry hundreds of tons of molten steel...

    It took me a second to realize that didn't say gargantuan ladies.

    Must remember to have coffee before reading.

    You noticed :-}

  • KP (unregistered) in reply to Grimoire
    Grimoire:
    This sounds like the app I worked on at my previous job. We bought a company that made remote inspection software, and it was full of crap like this. It sounds *exactly* like Echo by Infowave (previously Telispark). The guy who wrote the original did some crazy stuff like storing strokes of the signature instead of storing the binary bitmap.

    I would not at all be surprised if this was Telispark...

    The bitmap alone is not enough for forensic investigation to determine if it was more likely a valid signature or a forgery. Storing the stroke information (ie. timing) allows you to simulate the process of creating the signature, and compare that against other signatures (presumably stored in a database), or newly captured signatures from a verifiable signator. (and better if it captured time, pressure and location)

    In any case the whole signature pad thing is probably useless because my signature never looks the same twice on those things, and doesn't remotely resemble my signature on paper. I'm not sure that if I were given the challenge to verify that any two of my signatures from the grocery store were signed by the same hand that it would be possible to state that they were with any degree of certainty.

    Anyone aware of a legal challenge that verified the forensic examinability of electronic signatures?

  • noob (unregistered) in reply to kastein
    kastein:
    Another steel mill story? wow... and my senior project was related to this (the steel mill stuff, not the signature handling XMLAOTD (XML Abuse Of The Day)).

    Note: my senior project mostly caught fire. Thermal runaway in motor drivers is my worst nightmare.

    During my senior project, I had a pleasant dream that was going very nicely until it was interrupted by everything going black and me seeing the words "segmentation fault" and then waking up. Coincidentally, I had spent a little too much time debugging the previous day...

  • Sam (unregistered)

    Surely a simple way to reduce file-size here would be, ah, gzip/<insert preferred compression software here>? A quick test suggests that reduces file size by a factor of 30 on a 1250 "bit" file.

  • (cs)

    To everyone saying the original dev wrote the XML stupidly - am I seriously the only person who noticed that the dev didn't write the XML-generation code himself? He used a built-in function of a built-in class (DataTable).

    Granted, there are better ways to put the data in a transmittable format, but don't blame him for the stupidity of the XML :P

  • Naked Jaybird (unregistered) in reply to Neil
    Neil:
    anon:
    Fahrenheit? Speak SI, dammit!
    Sports Illustrated?
    I imagine the swimsuit issue of SI loses some of its sexiness when transmitted in bmp2xml format.
  • configurator (unregistered) 
    <Signature>
  <Pixel>
    <X>
      15
    </X>
    <Y>
      20
    </Y>
    <State>
      1
    </State>
  </Pixel>
  ...
</Signature>
    Duh!
  • (cs) in reply to Dave D Drawer
    Dave D Drawer:
    No, no, no, if you want to waste bytes, put your X Y data in VRML! 
    #VRML V2.0 utf8

Shape {
 appearance Appearance {
  material Material {
   emissiveColor 0.8 0.8 0.8
  }
 }
 geometry PointSet {
  coord Coordinate {
   point [
    3 17 0
   ]
  }
 }
}


NavigationInfo {
 type [ "EXAMINE", "FLY", "WALK", "ANY" ]
 speed 1.0
}
    Thankfully I think VRML is obscure enough that not even the worst "consultants" would try to include it in their architecture for any business app. although I am surprised that no one implemented it in the OMWTF contest. Would have made for an interesting calculator.
  • caper (unregistered)

    Seems to me that the developers who think Java is good for everything also think that XML is good for everything. And they are so absorbed in that notion that they have no knowledge of JSON, YAML, etc.

  • Irish Girl (unregistered)

    Total comment bytes: 30137 Comment bytes regarding gargantuan ladies: 3138 Payload: 89.6%

    Better than the original example, obviously, but it's still clear that some of you boys really need to get out more.

  • Alex (unregistered)

    The bitmap was then printed, put on a wooden table...

  • XMLKing (unregistered)

    290kB? Are you nuts, when it could be a mere 3 kB?!!!

    Ah, the 80's. When 290kB was a significant chunk of change when it came to hard disk space. When it could take a significant amount of time to transfer across the network.

    Today, it's 1/50th of a cent of hard disk space. It goes across a 100Mbit network faster than you can blink your eyes. And someone thought it was a WTF that you might, say, want to actually record the signing process rather than just the bitmap of the signature, and do it in a way which is endian-independent and platform agnostic.

    Oh well, can't win 'em all, I suppose.

  • Paula (unregistered)
    <comment> <first>1</first> </comment> <comment> <second>2</second> </comment>
  • nick (unregistered)

    The real WTF is that they used trivial-to-fake bitmaps instead of impossible-to-fake smartcards for their digital signatures.

  • David (unregistered)

    This is actually not that crazy. It is quite common for signature capture devices to store sigs as vectors - a sequence of lines. Perhaps they were just transmitting the input as generated by the device. I have done very similar things for my projects, although obviously not using XML.

  • (cs) in reply to nick
    nick:
    The real WTF is that they used trivial-to-fake bitmaps instead of impossible-to-fake smartcards for their digital signatures.
    Please tell me you're just trolling. Impossible to fake? Please.

    What's easier to fake: A smartcard copy that can be mass-produced, or a signature that has to be trained?

    (Answer: A signature image/picture that can be inserted into any document)

  • (cs) in reply to Big Bertha
    Big Bertha:
    Jim Lard:
    I mis-read "gargantuan ladles" in the first paragraph as "gargantuan ladies". Then got all excited when it started talking about the "hot strip mill"...
    I'm a gargantuan lady, you insensitive clod!
    Nothing insensitive about it at all.
  • Josh (unregistered) in reply to Darren

    You proposed exactly as I did. Yes, I am the guy who submitted this WTF. We were migrating web applications from one environment to another, en masse, over a 3 month period (so you'll have to forgive me if I can't remember all the details here).

    I don't recall exactly what the individual numbers did (I think they were x*y notation, and the numbers cited were made up, obviously... I didn't grab a sample). But I decided to Base64 encode the binary data... cut the payload down by 90% I believe.

    And yes, the final result WAS a jpeg image. I was debating about changing it, but barely had enough time to implement the base64 fix before I had to move on to the next app. I could have made a career of fixing WTFs that I found in those apps, but I'm glad I didn't. I've since moved on to more interesting things.

  • (cs) in reply to ContraCorners
    ContraCorners:
    >> And not the "everyday" things like the gargantuan ladles that carry hundreds of tons of molten steel...

    It took me a second to realize that didn't say gargantuan ladies.

    Must remember to have coffee before reading.

    I had to read it a few times.

  • nick (unregistered)

    Keybounce, surely you are a troll or you are simply ignorant of public key technology.

    "What's easier to fake: A smartcard copy that can be mass-produced, or a signature that has to be trained?"

    A signature is far easier to fake than a smartcard. A smartcard generates a private key when it is initialized. Anybody can see your signature and copy it. Nobody can see your private key to copy it. They could steal your card--but that attack is mitigated by revocation.

  • Not THAT Alex (unregistered)

    I can understand gargantuan ladies may be strong, but isn't carrying tons of molten steel a little too much?

  • bah (unregistered)

    XML.

    The fatal spore with the funny name.

  • the amazing null (unregistered) in reply to Man of Steel
    Man of Steel:
    Kazan:
    Man of Steel:
    Ummm, that's not X Y data. At best it might be the value of each consecutive pixel, with the X Y coordinates implied. But, you said it wasn't a color image.

    I call BS. Or confusion, which is close enough to the same thing.

    you can address an X-Y space with consecutive numbers if you map it correctly

    N = the value given Sx = Width Sy = Height Origin = topleft.

    X = int(N / Sx) Y = N % Sx

    IIRC.. i tried to remember that real fast.. might be in error.

    The examples given, 87 and 127, don't contain enough bits to encode X and Y in a single number, unless the resulting bitmap is very small. Well I suppose X could have been 0 in both cases and the signature line went from Y=87 to Y=127 but that seems improbable for a signature capture.

    it is possible that any unnamed pixel is assumed to be white and the named ones are black. what we are seeing in the sample may be the dots of two "i" charaters, or a dot and some accidental poking of the screen. it is likely not x and y data, but as someone else said, it may be a one-dimensional projection of the two-dimensional space used in the pane. labeling every pixel would have been a still worse waste of space. if your universe (in this case, the color space) has two values and they are mutually exclusive, everything that is not one is the other. just pick the value suspected to be the minority componenet and only label the parts of the space conforming to that criteria.

    the original programmer could have been aware that his solution was bad but that sending twice as many integers to represent the pixel location was worse so he linearized it all like this. it is not "good" but it is "better"

  • Fedaykin (unregistered)

    Hmm. While uxing XML was silly, this is not a WTF.

    The system worked and it was easy to determine how it was done (even if it was done inefficiently) and thus would be easy to modify.

    This is decent code.

  • (cs)

    I don't get it. It would have been much simpler to just print out the bitmap, place it on a wooden table, take a photo, fax it to the central office, scan the fax, convert the tiff to XML, and store the XML in the database.

  • Herohtar (unregistered) in reply to Man of Steel
    Man of Steel:
    Kazan:
    you can address an X-Y space with consecutive numbers if you map it correctly

    N = the value given Sx = Width Sy = Height Origin = topleft.

    X = int(N / Sx) Y = N % Sx

    IIRC.. i tried to remember that real fast.. might be in error.

    The examples given, 87 and 127, don't contain enough bits to encode X and Y in a single number, unless the resulting bitmap is very small. Well I suppose X could have been 0 in both cases and the signature line went from Y=87 to Y=127 but that seems improbable for a signature capture.
    The "number of bits" in the values has nothing to do with being able to encode the position. Kazan got the equations backward (Y gets a value > 100 for the second point) but he is right. Using the values given in the post you get:

    X = 87 % 300 = 87, Y = int(87 / 300) = 0 X = 127 % 300 = 127, Y = int(127/300) = 0

    So we have points at (87, 0) and (127, 0). However, as you mentioned, it seems unlikely to have that sequence of points for a signature.

    Neil:
    ContraCorners:
    >> And not the "everyday" things like the gargantuan ladles that carry hundreds of tons of molten steel...

    It took me a second to realize that didn't say gargantuan ladies.

    Must remember to have coffee before reading.

    Hah! You did better than me. I thought it said ladies until I read your comment. :P
    Me too...

  • Bluesman (unregistered)

    If there were gargantuan ladies present, shouldn't they be using XXL instead of XML?

  • (cs)

    We don't know it, but Rube Goldberg is the patron saint of programming.

  • (cs) in reply to Not THAT Alex
    Not THAT Alex:
    I can understand gargantuan ladies may be strong, but isn't carrying tons of molten steel a little too much?
    I think the "molten" part refers to the site I previously quoted, while "steel" probably just refers to their ability to put up with us men.
  • Wolfraider (unregistered) in reply to Prometheus
    Prometheus:
    <Comment> <comment> I ain't first </comment> </Comment>

    I think a lot of us in the wee hours of the morning misread that as "ladies" Me included.

    wee hours in the morning???? Its almost quitting time and I still read that as ladies

  • (cs)

    Alex, it would be funny if you intentionally put in misspellings like gargantuan ladies, and then had the page subtly update with the correct spelling x seconds later. You could do it with an animated gif pretending to be the first paragraph of text.

    "Damn, I thought for sure it said gargantuan ladies and I was going to write a great comment but thank God I reread it before I posted because damn if that doesn't say ladles after all. Hmm, why can't I scrape the words? Aha!"

  • asdf (unregistered) in reply to Beldar the Phantom Replier
    Beldar the Phantom Replier:
    Dinnerbone:
    Oh god, 273 == -273. The universe goes boom.

    That makes perfect sense iff 273 == i

    -i != i, (-i = 1/i)

    0 = -0, and that's the only complex number where it works

  • (cs) in reply to asdf
    asdf:
    Beldar the Phantom Replier:
    Dinnerbone:
    Oh god, 273 == -273. The universe goes boom.

    That makes perfect sense iff 273 == i

    -i != i, (-i = 1/i)

    0 = -0, and that's the only complex number where it works

    To generalize: In a group, there is a unique identity element e. And each element x has a unique inverse under the group operation, symbolically written x * (x^(-1)) = e. e is its own inverse, since e * e = e.

  • Sh (unregistered) in reply to Heron
    Heron:
    To everyone saying the original dev wrote the XML stupidly - am I seriously the only person who noticed that the dev didn't write the XML-generation code himself? He used a built-in function of a built-in class (DataTable).

    Granted, there are better ways to put the data in a transmittable format, but don't blame him for the stupidity of the XML :P

    Nope, still has the blame. If he had used a byte array instead of a dataset, .Net would have encoded the whole lot using a Base64 encoding representation; considerably smaller.

    If you didn't know this was how a datatable would be encoded into XML, well, yeah, your fault.

    (Nowadays, I'd probably use a byte array and the Windows Communication Foundation binary encodings - taking SOAP and XML out of the picture entirely. But I'm guessing this predates WCF.)

  • (cs) in reply to minini
    minini:
    actually, not too bad. ok, they could have used something better than xml, but recording the series of coordinates is a good thing to do, since the way the signature is written contains additional information. just like for most handwrite recognition systems that use stylus or other pens, they use the direction of drawing too

    I don't think anyone is questioning storing the pixel order. The WTF is the stupid XML notation. First off, it didn't really need to be XML. But since it was XML a smaller (and more correct) form of XML could have been used. One example: <signature> <point value = 87/> <point value = 111/> </signature>

    There was not need for the double sig element, especially since the interior element is NOT a signature, but just a single point. Not to mention the other numberous ways to encode the data (base64, csv, json, etc)

    As far as the dev being dumb, yeah the dev was dumb. You can add attributes to the datatable to tell it to use a better form of outputing the results.

  • Fortrinn (unregistered) in reply to XML Blasta
    XML Blasta:
    The basic rule of XML is "XML is like violence. If it isn't solving your problem yet, you're not using enough of it."

    Can I use that as my sig?

  • Shaft (unregistered)

    I worked on a similar project years ago. As I recall the data source contained packed coordinates. I think an entire signature was less than 800 bytes of coordinates.

    Wrote a C program to: Create blank bitmap in a predetermined size Unpack the coordinates Scale the coordinates to fit in your bitmap Plot each set of coordinates, drawing a line between them. For good measure, shade the lines so it is visible. Send them to be loaded in batch as blobs on the database.

  • NutDriverLefty (unregistered) in reply to Shaft
    Shaft:
    Wrote a C program to: Create blank bitmap in a predetermined size Unpack the coordinates Scale the coordinates to fit in your bitmap Plot each set of coordinates, drawing a line between them. For good measure, shade the lines so it is visible. Send them to be loaded in batch as blobs on the database.

    You coulda just used 'dot'.

  • foxyshadis (unregistered) in reply to Chelloveck
    Chelloveck:
    evilspoons:
    At any rate, just stick the damn thing in as a PNG or a GIF or something. I don't think JPEG is very efficient in monochrome (although I could be wrong).

    You're not wrong. JPEG is really freakin' awful for monochrome images. It's also pretty bad at any line-art like a cartoon or logo, color or mono. JPEG compresses smooth color gradients, not sharp transitions. Encoding a line drawing as JPEG gives it all sorts of really nasty compression artifacts.

    JPEG would be the worst possible image format for a monochrome signature. With the possible exception of XML, of course.

    JPEG's monochrome encoding is called JBIG. It's based on CCITT fax encodings, similar to LZW-packed TIFF, and has no dct-coding to make it blurry and noisy.

  • bigbird (unregistered) in reply to ContraCorners
    ContraCorners:
    >> And not the "everyday" things like the gargantuan ladles that carry hundreds of tons of molten steel...

    It took me a second to realize that didn't say gargantuan ladies.

    Must remember to have coffee before reading.

    I didn't realise it didn't say ladies until I read your comment!

  • AraxoN (unregistered) in reply to OzPeter
    OzPeter:
    In a similar vein I worked on a job where we wanted to punt around large amounts of numerical data from a Hot Strip Mill setup program to a logging system.

    We proposed an ASN.1 solution that would minimise the data volume and was easily extensible if you wanted to add more data to the log.

    But did they go with that?? Nope .. they ended up with an XML solution which multiplied the dataset size by a huge amount and if you wanted to change the dataset you had to edit and recompile the setup program.

    Dude, ASN.1 file format is even more horrible than XML.

  • Your Name * (unregistered)

    Sounds like a temporary hack. There's nothing more permanent than that.

  • (cs)

    TRWTF is that almost every single person who has posted "better" encodings of the data has actually posted invalid XML.

    Protip: attribute values must be quoted. <pixel x=0 y=4/> is not XML. The valid way to write this is <pixel x="0" y="4"/>.

    But I guess it's asking a bit much to expect commenters on TDWTF to, you know, have the faintest understanding of the things they're pretending to be experts on.

  • SteG. (unregistered) in reply to ContraCorners

    Until i read your comment i only saw 'ladies' too!. :)

  • FishBasketGordo (unregistered) in reply to ContraCorners
    ContraCorners:
    >> And not the "everyday" things like the gargantuan ladles that carry hundreds of tons of molten steel...

    It took me a second to realize that didn't say gargantuan ladies.

    Must remember to have coffee before reading.

    I'm glad I'm not the only one who thought that.

  • (cs) in reply to Iago
    Iago:
    I guess it's asking a bit much to expect commenters on TDWTF to, you know, have the faintest understanding of the things they're pretending to be experts on.
    I did notice that you are a commenter on TDWTF too, so I won't be asking too much of you.
  • (cs) in reply to BentFranklin
    BentFranklin:
    Alex, it would be funny if you intentionally put in misspellings like gargantuan ladies, and then had the page subtly update with the correct spelling x seconds later. You could do it with an animated gif pretending to be the first paragraph of text.

    "Damn, I thought for sure it said gargantuan ladies and I was going to write a great comment but thank God I reread it before I posted because damn if that doesn't say ladles after all. Hmm, why can't I scrape the words? Aha!"

    I don't know if it was intentional, but I love the delicious appropriateness of your suggestion. Who couldn't resist implementing this joke using a dodgy, not-fit-for-purpose bitmap rather than some easy *ML

    +25 internets.

  • Hoodaticus (unregistered)

    Don't you see? This way they can use xslt to transform it into a bitmap!

    Template select="/"

    LOL

    / template

  • (cs) in reply to DES
    DES:
    I don't get it. It would have been much simpler to just print out the bitmap, *engrave* it on a wooden table, take a photo, fax it to the central office, scan the fax, convert the tiff to XML, and store the XML in the database.
    FTFY

Leave a comment on “Interesting Bitmap”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article