|
From: | Thomas L. Scofield |
Subject: | Re: imread |
Date: | Tue, 15 Jul 2008 14:36:46 -0400 |
On Jul 14, 2008, at 4:14 PM, John W. Eaton wrote:
I'm not exactly sure what to do differently. The files on my machine are text files. I included them as attachments (email program is the Mac Mail program). At what stage would they have become binary files?
What's the reason behind these last two? Am I correct, in the case of the last one, that inclusion of oct.h pulls in config.h as well? If so, is the need for only a smaller set of declarations something that, as the principle architect of the package, you (and perhaps only a handful of others) would be able to determine efficiently, or is there some process a novice like me could use? The only documentation I've seen (Appendix A of the manual) suggests that you generally just go ahead and include oct.h when you write dynamically linked functions.
I think the same thing, but I wasn't the code's original author. To date, I've changed only about a line or so of the code. I would like to write a modified __magick_read__.cc routine for all of the handling and information-gathering of the image files themselves. I'm sure the more mundane things can be wrapped there as well, but given where I am in the knowledge of C++ these days, I'd rather not have to deal with the appropriateness of arguments to imread there. There's already a bit of argument checking in the existing imread routine, and my recollection of C++ file handling in general is that it is harder to check if files exist, etc. than the commands provided in Octave (not to mention that the commands provided in Octave are, I presume, platform independent).
I'll dig into it to see if I can determine what its purpose is. Is the issue you mention the same one discussed between Soren Hauberg and me soon after I submitted the files for review (a couple of weeks ago)? I get washed-out pictures not only with jpegs (that type of file, in the one instance I've tried, has not been particularly egregious), but also with png files (some really bad examples). But the problem only exists when I am doing things on my linux machine. Assuming nothing I've done has changed the behavior of imread drastically, I find the pictures appear like they ought when displayed using imread on my mac (there I am using the original imread from octave-forge). To understand that comment fully, I guess you need to know that the problem does not arise on either machine when I display these images with either "display" (ImageMagick command) or "gm display" (GraphicsMagick). --- Just got your message about it being imshow. Can it be the source of the problem I describe here, too? Thomas L. Scofield -------------------------------------------------------- Associate Professor Department of Mathematics and Statistics Calvin College -------------------------------------------------------- |
[Prev in Thread] | Current Thread | [Next in Thread] |