Differences between Image, Texture, Sprite and RenderTarget?

[Raptor88]

I'm on the verge of, but not quite grasping the differences between Image, Texture and Sprite.  I've read through the SFML 2.0 documentation/classes and here's my understanding so far.

Image:
loadFromFile:  Loads an image from the hard drive into normal ram.
Image residing in normal ram allows it to be manipulated freely.

Texture:
loadFromFile:  Loads an image from the hard drive directly into graphics card ram.
Image residing in graphics card ram requires preparing mods first and then loading them into graphics card ram.

Sprite:
sf::Sprite is a drawable class that allows to easily display a texture (or a part of it) on a render target.
Sprite does not hold the texture but only a reference to the texture.
All SFML references for Sprite in the sf::Sprite description refer to "Texture" but not "Image".

QUESTIONS:
1.  How does Sprite relate to an "Image"? 
2.  Does an image have to be loaded into graphics card ram first and then a Sprite can refer to it?
3.  What is the "render target" in the sprite description?  Googling indicates that a RenderTarget is the "back buffer" in the graphics card that's not currently being displayed.  But isn't "Texture" already the image in the "back buffer" in the graphics card ram?

Sorry for the noob questions but I've been unable to fully understand the above after much researching.  Hope someone can explain it in lay language.

Thanks,
Raptor

[eXpl0it3r]

An sf::Image is class that holds image information on the memory of your CPU (your PC's 'core') and has the ability to load different image formats from the disk. It's also here where you can manipulate the image information directly.

An sf::Texture is class that holds image information on the memory of your GPU (your graphics card's 'core') and makes use of sf::Image's ability to load different image formats and copies the image information from the sf::Image to itself (i.e. sf::Texture does not load the image itself, it only provides an interface to do so).

sf::Image and sf::Texture are both 'containers' for image information, but they can't get drawn to the render target directly. That's where sf::Sprite comes into play, but since the sf::Image is in the CPU's memory and thus the way to the GPU (graphics card) is long, sf::Sprite can only make direct use of a sf::Texture, thus when you want to use sf::Image's information you'll have to copy it to a sf::Texture, which can be quite a heavy (in time) task.

sf::Sprite is class that can draw a rectangle of a sf::Texture to a render target. It can also transform it in the 2D space (translate, rotate and scale).

Now for the sf::RenderTarget is just a target one can render sprites, vertex array, shapes etc. to. There are two classes that are defined as sf::RenderTarget: sf::RenderWindow and sf::RenderTexture. Both act very similar and can also be handled very similar. The major difference is that sf::RenderWindow gets directly displayed on the screen (that's what you get to see), whereas the sf::RenderTexture stays hidden on the GPU's memory and you can get the rendering as a texture and draw it to the screen.
If you're interested in the process behind this, then you may want to search for 'double buffering' and similar keywords.

I hope I could clarify some things.

[Raptor88]

An sf::Image is class that holds image information on the memory of your CPU (your PC's 'core') and has the ability to load different image formats from the disk. It's also here where you can manipulate the image information directly.

An sf::Texture is class that holds image information on the memory of your GPU (your graphics card's 'core') and makes use of sf::Image's ability to load different image formats and copies the image information from the sf::Image to itself (i.e. sf::Texture does not load the image itself, it only provides an interface to do so).

sf::Image and sf::Texture are both 'containers' for image information, but they can't get drawn to the render target directly. That's where sf::Sprite comes into play, but since the sf::Image is in the CPU's memory and thus the way to the GPU (graphics card) is long, sf::Sprite can only make direct use of a sf::Texture, thus when you want to use sf::Image's information you'll have to copy it to a sf::Texture, which can be quite a heavy (in time) task.

sf::Sprite is class that can draw a rectangle of a sf::Texture to a render target. It can also transform it in the 2D space (translate, rotate and scale).

Now for the sf::RenderTarget is just a target one can render sprites, vertex array, shapes etc. to. There are two classes that are defined as sf::RenderTarget: sf::RenderWindow and sf::RenderTexture. Both act very similar and can also be handled very similar. The major difference is that sf::RenderWindow gets directly displayed on the screen (that's what you get to see), whereas the sf::RenderTexture stays hidden on the GPU's memory and you can get the rendering as a texture and draw it to the screen.
If you're interested in the process behind this, then you may want to search for 'double buffering' and similar keywords.

I hope I could clarify some things.

I'm digesting what you wrote while referring to the SFML 2.0 documentation.  Thanks for your input!
If anyone else has explanations to add, please do so as the more explanations the better.

Thanks,
Raptor

[lrx]

n sf::Image is class that holds image information on the memory of your CPU....

Wouldn't that be cache?

[eXpl0it3r]

n sf::Image is class that holds image information on the memory of your CPU....

Wouldn't that be cache?

My description was very rough and I've actually not much knowledge of how SFML itself is implemented, I also used the term 'memory of your CPU' to make the difference clear between CPU and GPU.
As for the cache, one can not fully predict what the architecture the application will run on do with the information, but the cache has other functionality than to store information for a longer time and with its limited size, it wouldn't make sense.

[lrx]

n sf::Image is class that holds image information on the memory of your CPU....

Wouldn't that be cache?

My description was very rough and I've actually not much knowledge of how SFML itself is implemented, I also used the term 'memory of your CPU' to make the difference clear between CPU and GPU.
As for the cache, one can not fully predict what the architecture the application will run on do with the information, but the cache has other functionality than to store information for a longer time and with its limited size, it wouldn't make sense.

Sorry, I just felt it could be misleading for someone with little knowledge as your description indicated cache, which we know is not used as user accessible  storage memory, but somebody else could not know that.

[eXpl0it3r]

Well the RAM is still the memory of the CPU, there's nothing wrong with that description.
Memory and cache are two completely different worlds (in theory and hardware).

Sorry, I just felt it could be misleading for someone with little knowledge...

I then don't think that such a person would think of the cache or understand what the difference is between RAM and cache in a way that he would confused.

[Laurent]

Well the RAM is still the memory of the CPU, there's nothing wrong with that description.
Memory and cache are two completely different worlds (in theory and hardware).

He was talking about the small memory that is embedded on the processor, which is called "cache". That's why your description could be confusing.

[eXpl0it3r]

He was talking about the small memory that is embedded on the processor, which is called "cache". That's why your description could be confusing.

I know, I was was just arguing that one usually doesn't talk about memory when referring to the cache, but I see it could be confusing for some people.