merthsoft wrote:
Yeah, always picks the first.
Sounds good, that's how SourceCoder works too. Smile
Alright, so I've fixed a couple of bugs. It turns out the saving of the images wasn't quite working right, now it should be. I've gotten rid of the dependency of VB.NET stuff, so everything should work with Mono now. I've also made it so that the Image Editor doesn't have an import anymore, just an open, and it'll do what it needs to depending on the type. Right now all it can open is .8xi, .bmp, .png, and .jp(e)g files.

As always, here's the link:
http://merthsoft.com/Tokens.zip
It seems like gif would be a reasonable thing to be able to open, given the palettiness of it, and the small color range available to calculators.
elfprince13 wrote:
It seems like gif would be a reasonable thing to be able to open, given the palettiness of it, and the small color range available to calculators.
True story; I think it makes more sense than moderately-lossy JPEG.
There's no reason not support them both.
merthsoft wrote:
There's no reason not support them both.
I suppose. It would have taken two extra lines of code to support JPEG in SourceCoder, but I chose not to because I was afraid of complaints or confusions from people not realize that WYSIWYG doesn't hold true when you're dealing with converting a JPEG image.
First a suggestion, an option to save it for Archive or RAM instead of editing properties to do that.

Second, never use .jpg for exporting images, it messes it up with artifacts, such a bad idea in my very true honest opinion.
We were (at least elfprince and I were) talking only about importing. For exporting it'll just be .bmp. As for converting it when you open it, the code is all the same there no matter the type (if loading a .gif works the same way as the rest, it's about 4 characters more to make it work). It just draws it to the screen and tells you to pick the region you want to import.

Edit: Ok, it supports importing .gifs now. Easy.
merthsoft wrote:
We were (at least elfprince and I were) talking only about importing. For exporting it'll just be .bmp. As for converting it when you open it, the code is all the same there no matter the type (if loading a .gif works the same way as the rest, it's about 4 characters more to make it work). It just draws it to the screen and tells you to pick the region you want to import.

Edit: Ok, it supports importing .gifs now. Easy.


Ahh, how would you even attempt importing .jpg's, considering the artifacts it usually has.
Easy, just like I import anything else:

Code:
using (Bitmap a = new Bitmap(f.OpenFile())) {
   CropImageDialog cid = new CropImageDialog(a);
   cid.ShowDialog();
   p = cid.outMap;
   canvas.Invalidate();
}
That's the code that handles importing all the types. I don't see why having some artifacts would really be that huge of a deal.
merthsoft wrote:
Easy, just like I import anything else:

Code:
using (Bitmap a = new Bitmap(f.OpenFile())) {
   CropImageDialog cid = new CropImageDialog(a);
   cid.ShowDialog();
   p = cid.outMap;
   canvas.Invalidate();
}
That's the code that handles importing all the types. I don't see why having some artifacts would really be that huge of a deal.


Think of it as having a HEX string that is slightly off, causing the image to look slightly off. If that makes any sense.
Dude, I understand the concept of artifacting. Probably to much greater depth than you. What I'm saying is, that doesn't prevent it from opening the file, just like ANY OTHER image editor does. Try it yourself. It'll open it, no problem, bring up the crop window, no problem, and do the algorithm to turn it black and white (for each pixel, take the average of the colors, if it's closer to white, make it white, otherwise make it black), no problem. There's nothing magical in the way that jpegs are stored that makes that any different than anything else.
merthsoft wrote:
Dude, I understand the concept of artifacting. Probably to much greater depth than you. What I'm saying is, that doesn't prevent it from opening the file, just like ANY OTHER image editor does. Try it yourself. It'll open it, no problem, bring up the crop window, no problem, and do the algorithm to turn it black and white (for each pixel, take the average of the colors, if it's closer to white, make it white, otherwise make it black), no problem. There's nothing magical in the way that jpegs are stored that makes that any different than anything else.


I am sure you know more then me, and I know it opens perfectly. I just figured that if some of the artifacts were closer to the opposite color then you wanted, then it would display the opposite, that is what I was getting at...
Sorry if I sorta ticked you off.
Of course that's possible, but that doesn't mean I shouldn't support it.
merthsoft wrote:
Of course that's possible, but that doesn't mean I shouldn't support it.


If I said you shouldn't, I didn't mean to, I was just asking how you would do that. Although, out of curiosity, is there a simple way you could implement a way to "choose" the percentage of the average of the colors so that you can sorta control where the threshold of what is converted to black and what is to white so there is a level of control.
Just a thought throwing out that, nothing more.
Sure, that would be handy. In case your background isn't quite light enough, it will still treat it as that. Though I plan on using a better (edge-detecting) algorithm for the conversion. It'd be easy enough to support both conversion algorithms.
Thresholding is fairly easy to implement, but for black-and-white, I don't feel like it's really necessary. For fine-tuning grayscale conversions, it can help, but I don't think that Merthsoft is planning on implementing that in the near future.
I think it would be useful, even for black and white. There have been some images that I've tested with where the background was just barely enough to be turned to black, but was, and I'd've preferred it not to have made it black.
merthsoft wrote:
Easy, just like I import anything else:

Code:
using (Bitmap a = new Bitmap(f.OpenFile())) {
   CropImageDialog cid = new CropImageDialog(a);
   cid.ShowDialog();
   p = cid.outMap;
   canvas.Invalidate();
}
That's the code that handles importing all the types. I don't see why having some artifacts would really be that huge of a deal.
If f is a FileInfo, it looks like you have a file handle leak there (you open the file but never close it). The Bitmap constructor can take a file name, so new Bitmap(f.FullName) should do the trick.
f is an OpenFileDialog thingie. I suppose I should still be doing f.FullName or whatever its equivalent is.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 7, 8, 9 ... 30, 31, 32  Next
» View previous topic :: View next topic  
Page 8 of 32
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement