Discussion on:
View:
Show:
Check out the cool little app that goes with this technique and let us know what you think about it. Do any likely modifications jump out at you?
Sorry, but that just makes the text look blurry to me. Harder to read, though admittedly it's more obvious that there is text there. I'd prefer using a contrasting color with a solid font, or put in a watermark if it needs to be subdued.
Reminds me of a poorly designed letterhead dot someone put together--all the text was shadowed. Made you go blind within 3 lines.
Reminds me of a poorly designed letterhead dot someone put together--all the text was shadowed. Made you go blind within 3 lines.
Mavyn -
Yes, that is potentially a problem, and I have seen that as well; that is more a factor of the font face and size than anything else. A font with a lot of whitespace in each character (such as Courier at 12 pt.), and a high contrast color match up (white halo with black font) will look much better than a "thick" font with poor color selection (think "Impact 8 pt., bold, with red halo on blue text).
The image background also makes a world of difference too; an extremely "busy" background will make it appear a bit more blurry than a more blocky background.
It is more a matter of the perception of color than a technical issue. I used this technique on maps, and the results were absolutely gorgeous (I am not saying this just because I wrote it). I tried it on a picture of a lot of trees taken from a distance, and it did not look so hot. As they say, "your mileage will vary." For some images, you are right, a watermark is sometimes a better choice!
Nonetheless, I hope that you find the example code helpful; it serves as an excellent primer to image manipulation within the .Net Framework too, as well as containing minor multithreading techniques using the BackgroundWorker class.
J.Ja
Edited 9/21/2006 to correct the name at the top
Yes, that is potentially a problem, and I have seen that as well; that is more a factor of the font face and size than anything else. A font with a lot of whitespace in each character (such as Courier at 12 pt.), and a high contrast color match up (white halo with black font) will look much better than a "thick" font with poor color selection (think "Impact 8 pt., bold, with red halo on blue text).
The image background also makes a world of difference too; an extremely "busy" background will make it appear a bit more blurry than a more blocky background.
It is more a matter of the perception of color than a technical issue. I used this technique on maps, and the results were absolutely gorgeous (I am not saying this just because I wrote it). I tried it on a picture of a lot of trees taken from a distance, and it did not look so hot. As they say, "your mileage will vary." For some images, you are right, a watermark is sometimes a better choice!
Nonetheless, I hope that you find the example code helpful; it serves as an excellent primer to image manipulation within the .Net Framework too, as well as containing minor multithreading techniques using the BackgroundWorker class.
J.Ja
Edited 9/21/2006 to correct the name at the top
It requires .NET
I have had bAAAd experiences with that piece of M$ bloatware, never again
*** sigh ***
It may be a cute piece of code, but why hang a millstone around your neck?
I have had bAAAd experiences with that piece of M$ bloatware, never again
*** sigh ***
It may be a cute piece of code, but why hang a millstone around your neck?
Kiltie -
My experience has been (and I am hardly a "Microsoft shill", I have developed and enjoyed developing in languages like Pascal, C, Scheme, COBOL, Java, Perl, and a lot more outside of the Microsoft ecology) that using .Net is always a tradeoff, like any other language. .Net is incredibly easy to code in and code for due to the comprehensive nature of the .Net Framework, the excellent documentation, the quality of Visual Studio, and the variety of languages that target the .Net CLR. That being said, I agree that the .Net CLR is pretty bloated in some areas, and code is very slow to run, particularly on the first run. In addition, the .Net Framework itself cutting development time is always in competition with the lack of quality (in my mind) of VB and C# as languages. If you are writing pure logic code and not dealing with libraries, Perl (just to use one example) tends to have 10% - 1,000% less lines of code to accomplish the same task, depending upon what you are writing, compared to VB.Net, because VB.Net in and of itself is not a terribly useful language.
In this case, the tradeoff is, "am I willing to load 10 - 30 MB worth of framework and take an up front speed hit, and take a 5% - 10% performance penalty from there on out, in exchange for some possibly easier development?" I would say that for something like this, the answer is "yes." If your application is so big that the difference between .Net and native code is one where you need to throw more hardware at it, then by all means, it is cheaper to have a good C++ developer on staff than to be buying 10% or 25% or whatever percent more servers just to do it in .Net. The same could be said for Java and PHP and Ruby and Python too (of course, PHP, Ruby, and Python are not as slow as .Net or Java).
You always have to face this tradeoff. The lower level the language, the harder the code will be to write and debug (pointers rocks for performance, and stink for development!), but the end result will be faster. It all depends on your needs, and of course, your milage will vary.
J.Ja
My experience has been (and I am hardly a "Microsoft shill", I have developed and enjoyed developing in languages like Pascal, C, Scheme, COBOL, Java, Perl, and a lot more outside of the Microsoft ecology) that using .Net is always a tradeoff, like any other language. .Net is incredibly easy to code in and code for due to the comprehensive nature of the .Net Framework, the excellent documentation, the quality of Visual Studio, and the variety of languages that target the .Net CLR. That being said, I agree that the .Net CLR is pretty bloated in some areas, and code is very slow to run, particularly on the first run. In addition, the .Net Framework itself cutting development time is always in competition with the lack of quality (in my mind) of VB and C# as languages. If you are writing pure logic code and not dealing with libraries, Perl (just to use one example) tends to have 10% - 1,000% less lines of code to accomplish the same task, depending upon what you are writing, compared to VB.Net, because VB.Net in and of itself is not a terribly useful language.
In this case, the tradeoff is, "am I willing to load 10 - 30 MB worth of framework and take an up front speed hit, and take a 5% - 10% performance penalty from there on out, in exchange for some possibly easier development?" I would say that for something like this, the answer is "yes." If your application is so big that the difference between .Net and native code is one where you need to throw more hardware at it, then by all means, it is cheaper to have a good C++ developer on staff than to be buying 10% or 25% or whatever percent more servers just to do it in .Net. The same could be said for Java and PHP and Ruby and Python too (of course, PHP, Ruby, and Python are not as slow as .Net or Java).
You always have to face this tradeoff. The lower level the language, the harder the code will be to write and debug (pointers rocks for performance, and stink for development!), but the end result will be faster. It all depends on your needs, and of course, your milage will vary.
J.Ja
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
