- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
People writing this kind of code is probably the reason why disk caching was invented.
Admin
Where's the wooden table? That image processing code is missing a wooden table…
Admin
Been there, done that and know exactly the reason for the dance with the MemoryStream in the last section: .NET silently and automatically backs image memory with the original disk image - thus leading to the embarrassing case of not being able to delete the original working image from disk unless one can break the chain with a MemoryStream.
Admin
No polaroid step either, nor has he embedded it into Microsoft word.
Admin
Tiny observation in passing, a sort of criticism of young Master @snoofle perhaps, or maybe of the original submitter: Imgbyte.Length is not necessarily the same thing as the physical file size required to store the image, especially as the image is extracted into a .jpg file...
Admin
That would be a good place to use a MemoryStream, but since the ExtractImage function receives a path, perhaps it was easier to do it this way than to modify ExtractImage to receive a stream.
I think it's not the case this time (though it's a WTF in itself). It saves the image on disk, and returns the image as saved - one option is to read it back from file, with an IO penalty, and the other is to write it into a MemoryStream and read from there. If you're more IO bound than CPU bound, it might be advantageous to reprocess the image.
I don't think there's a need for calling
Bitmap(Image image)here, but there might be some sharing violation problems with the image somewhere else.Admin
TRWTF are images. Most documents and web pages have too many of them.
Admin
Yes. ASCII-art is far easier to work with.
Admin
It’s also easier to merge without using locking. :fire:
Admin
Today I learned that "ingenuity" can be used as a concrete noun. Or at least, that some people will insist on doing so.
Admin
Oh shoot! I always thought the proper word was "ingenuitum" (since it was a single piece of ingenuity)
Admin
That actually sounds sketchy as fuck,
Admin
Back around 2001 or so, I encountered a bug in an image processing product of ours: It used up all my GDI memory. This provoked a great deal of interest from the owning team, because the bug had been observed, but had not been able to be reproduced...and I reported that I could reproduce it.
The problem was traced to a failure to return a Windows GDI bitmap handle to the O.S. The handle was obtained by the library and handed back, but the release was overlooked.
One of the developers was sitting by my desk, snipping out code, compiling new versions, and giving them to me to run. I would then fire up the app, go into the magnifying glass, and move it around (which was how the bug was demonstrated). Practice helped: I got to where I could go from starting the app to out of GDI memory in three-four seconds.
Talk about your memory leaks: Nothing faster than leaking whole bitmaps at the rate of dozens per second..
Admin
It depends on what they're doing — converting to monochrome would be a legitimate transform — who the copyright owner is and whether the person doing it (if not the owner) has permission.
Admin
Hi ! I'm the original submitter and I will answer some questions you might have. Just so you know, almost all code written by these developers could be submitted to the site. It would just be too huge to do so.
Is it normal to be proud to be on such an awesome website, and also very sad ?
Nope, these developers are just bad. You sir, are indeed correct. However, it was only used in arbitrary manner (don't bother to process files smaller than X bytes), so I felt safe to change it. Good try, but no. ExtractImage was just writing the bytes to the file. And yes, it was just called here. Nowhere else. Our client software generates a PDF that we will print on our giant printers (giant as in "several meters long"). Depending on the product, and on the printer it will be sent on, we might want to do post-processing (color adjustment) on the images. The client software should not have to bother with that, so it's processed on the server. The customer sends us their products to be printed. We do some automatic image color improvements before printing.Admin
ExtractImage() is not exactly a WTF if the Image Processing Library is known to choke when it see garbage in the end. (Many image hosting websites, especially the non-MVC .NET ones, forgot to skip Rendering the page when emitting the file, so a bunch of unneeded garbage appear at the end of file. And for ProcessImage(), except the unnecessary "using new Bitmap" part, others are just pretty standard code to convert the image to JPG to extract the bytes from JPEG encoded image.
Admin
TRWTF is the author saying the
BitMapwas passed by reference where norefparameters are usedAdmin
.NET by default loads the images (in BitmapImage) on demand, which locks the source file. If you set the CacheOption property to OnLoad, they get loaded immediately. In that case the source file is not locked.
Admin
I can't picture why someone would do this
<!-- http://instantrimshot.com -->