I know it was done in the past but now because everything is done in high level languages i can't find any info on how to use, manipulate or create images in assembly. I have been searching online for days so if anyone knows a good website or book to read then i would truly appreciate it.
Posted on 2013-02-20 19:04:39 by Snake4eva
This is a website I found that kinda helps.
http://showmedo.com/videotutorials/video?fromSeriesID=320&name=3200020
Posted on 2013-02-20 19:23:10 by Snake4eva
Can anyone tell me the relationships of the dimensions of an image (250 x 375) with the physical screen resolution. And how can an image of say (1020 x 768) be displayed on  a screen with physical/pixel dimensions of 640 x 480.
Posted on 2013-02-21 17:55:19 by Snake4eva
You just resize the image by resampling the pixel data.
Posted on 2013-02-22 04:07:10 by Scali
How do you preserve the original number of pixel information while reducing the screen resolution and thus get a better picture quality. Also can anyone write a sample jpeg decoder algorithm in a high level language or otherwise or just the an algorithm for computing Discrete cosine transform. 
Posted on 2013-02-22 08:11:44 by Snake4eva
...not sure if trolling or stupid...

No offense, but either you are trying to play a bad joke on us, or you are just in WAY WAY WAY over your head.
How do you preserve the original pixel information? Well obviously by preserving the original pixel information... as in, you keep the source data around while making a resized copy.

Can anyone write a sample JPEG decoder? Sure... But as I already said, it is a very complicated file format, taking quite a number of steps. It's useless to just paste code here, because you're obviously not ready for image processing at a level as advanced as that.
There are various documents and open source implementations of JPEG around if you want to study the internals. But I wouldn't pick it as a first format, because as I already said, it is one of the most complicated image formats around. BMP, PCX, IFF/LBM, TGA, TIFF, those are relatively easy to begin with. Then come things like GIF and PNG (which use very conventional lossless compression techniques, similar to LZ and Huffman algorithms found in zip and such), and finally JPEG.
Posted on 2013-02-23 07:56:42 by Scali

...not sure if trolling or stupid...


Or could be ignorant of certain subjects. Nobody's born knowing this stuff, y'know...

I suspect Snake4eva may be well over his head. Some people learn to swim by jumping (or being pushed) into the deep end of the pool. Some people need to read all the documentation and understand all the details before they'll even get a toe wet.

Having said that, I agree that smaller steps would be advisable. The question may be, "what steps are appropriate?"

For sure, we're going to need to open a file and read it. (You're Windows, right Snake4eva?) Practice with a text file, print it back to be sure you've got it. What happens if the file doesn't exist or has the wrong permissions?

Then try to parse some non-text data. Any kind of header would do. Since you're interested in .jpg, try that. Forget about decompressing it, for now, but read off height and width and depth and whatever all's there. Probably a byte or more saying which compression algorithm is used (?). I think "JFIF" is a sheaf of formats, so you may need to find out that this is actually a JPEG. And find out where the compressed stuff starts. Or, since you're going to want a simpler image format for the next step, maybe start with a simpler header format. Seems to me that "height", "width", and "depth" would be pretty fundamental...

Put an image - any image from any source - on the screen. Manipulate some pixels, if you like. This is where a much simpler format than .jpg would come in handy!

Then there's the decompression algorithm... or more than one. I vaguely recall what a "cosine" is, but "discrete" and "transform", in that context, elude me at the moment. I expect wikipedia has an article on it...

That's just how I'd approach it. You can jump into the pool anyplace you like! :)

Best,
Frank

Posted on 2013-02-23 13:45:03 by fbkotler

Or could be ignorant of certain subjects. Nobody's born knowing this stuff, y'know...


Seems you are ignorant of certain memes :)

I vaguely recall what a "cosine" is, but "discrete" and "transform", in that context, elude me at the moment. I expect wikipedia has an article on it...


It's closely related to Fourier transforms (Fourier uses sums of both sine and cosine functions to approximate a function, where cosine transforms use only cosines, hence the name).
Posted on 2013-02-23 15:31:29 by Scali

Having said that, I agree that smaller steps would be advisable. The question may be, "what steps are appropriate?"


Begin by learning which questions are appropriate for human response, and which questions are appropriate for self-directed searches.

If you are asking for instructions, i.e. "how" to do something, you should be looking that information up yourself. If you don't understand the information you are reading, you have to step back and learn the fundamentals that comprise the subject matter. Protip: Internet search engines, such as Google, seem really good at handling these types of questions.

If you are asking for direction, i.e. "why" to do something or "what" to do, that is when you should consider seeking human dialogue.

So far, I have not seen a relevant "why" or "what" type question from this person... only questions that warrant lmgtfy responses, at best.

Here it is from a different perspective. I am a real person who has limited time to answer random questions from the Internet. What are you doing to convince me that I am not wasting my time and thus compel me to give a thoughtful answer? Hint: asking "spoon feed me code" type questions, or questions that have been answered here and throughout the entire Internet -- in detail -- about a billion times over, isn't very compelling ;)
Posted on 2013-02-23 17:59:33 by SpooK
First of all I am human and I apologize if I have offended anyone with my questions. I am an undergraduate student (Physics/ electronics major) currently doing DSP and my final year electronics project. I have understand the math very well Discrete fourier transform, linear algebra, abstract algebra, fourier/laplace/Z transform and all the stuff that related to doing image transformation and processing. My problem is with the coding, I don't have extensive experience with coding I have coded in C/C++, nasm, python, pascal and I know to do basic to intermediate tasks in the high level languages but only basic stuff inj assembly. I am self-taught when it comes to programming, i read a lot of my cousins book who is a computer science major but image processing is way out of his league. I have read a lot on the internet about JFIF/JPEG and i don't want anyone of you guys to spoon feed me code what I would like is just some idea of how to approach image processing because of my lack of extensive programming experience. I know that it would be easier to choose a simpler final year project and I have been told many times that I am way in over my head. Reading materials is the problem I usually spend hours reading anyways the problem is knowing the right and relevant materials to read. All i'm saying is I don't wan't your code just help with how to approach the problem because at the moment the problem is knowing how to code a given task and understanding the complex file format of jpeg. I would like my project to be extensive and thus will need to understand jpeg anyways. What I want is something like:

Posted by: fbkotler
on: Today at 18:45:03 Insert Quote

No code was given just useful advice that all I want code would be useful to analyse to try an get an understanding of the approach presented but it isn't necessary because i'll read to fill in the gaps. I am on a dual booted system that has Windows 7 pro 32-bit and Ubuntu 12.14 but doing the coding on windows. The specs of the pc are as follows:
AMD 64 Turon x2 Technology 2.0GHz, 894 MB, Toshiba Satellite. The compilers/assemblers are DEV-C++,NASM,Netbeans.
Posted on 2013-02-23 18:44:22 by Snake4eva

First of all I am human and I apologize if I have offended anyone with my questions.


I think it would be difficult to offend anyone here by simply asking questions.

Frank's last answer is the route you'd want to take. You want to model the problem top-down, and tackle it in parts.

You know you need input and output, so figure that part out first. As Frank mentioned, reading an ASCII "text" file (with known data) and printing it to the screen verbatim is a good first step.

After that, keep going through the iterations of input, transformation and output. Whenever you can, feed known input and pre-calculate what the output should be, and compare.

Since you seem to be stuck using BIOS/DOS, RBIL will be an invaluable resource, especially when it comes to changing video modes. If you can utilize VESA, or anything that provides a linear framebuffer, go for it. I would also recommend reading up various OSDev.org wiki articles.
Posted on 2013-02-23 19:46:00 by SpooK
I am not sure why you are so hung up on JPG anyway.
You say you want to do some kind of image processing. Now, commonly this follows a pattern somewhat like this:

1) Load and decode image from disk/memory/whatever
2) Do processing
3) Encode and save processed image to disk/memory/whatever

Now, JPG is only relevant for steps 1) and 3), where 2) is the thing you say you want to do.
My advice would be: don't bother about 1) and 3), just grab some library that can load and save images (I use FreeImage for my usual cross-platform image loading/saving needs... and yes, I have written my own GIF and JPG loading routines in the past).
Then steps 1) and 3) are trivial (assuming you know how to read a bit of documentation and call a handful of library functions), and you can easily support JPG and any number of other popular image formats.
Then concentrate on 2) where you will be getting the actual job done.

Again, the format used to store images on disk is completely irrelevant for the actual processing of these images. You always decode it to some easy-to-process internal format, which is usually a linear xRGB buffer in memory, as stated earlier. Which is what the library will take care of for you.
Posted on 2013-02-24 04:35:48 by Scali