I see where you are coming from, though profiling isn't really the right term here. FPGAs aren't programmed in the same sense as a computer is. You describe what hardware is required using code, then synthesize it using the toolchain from the specific vendor whose FPGA you are targeting. You then get a synthesis report that will tell you the resource utilisation of the design. FPGA hardware doesn't change dynamically - that is to say, you know the exact resource usage at compile time and so you don't really "profile" it.
Furthermore, do you mean FPGA, or FPGA SoC - the two are different. Some FPGAs have an embedded hard-processor (SoC). Others don't. If you are planning on trying to do this in software on an embedded (soft or hard) processor in the FPGA vs. dedicated logic, the answer is very different.
To add to Simons answer, it is virtually impossible to say what resources any given design will use simply because it depends not only on the design, but also many other factors such as the specific family if FPGA you are using, what portion of the FPGA you are using, and the clock speeds you are running at. In fact you can change one line of code which is seemingly inconsequential, and when you then recompile the entire arrangement of the design and resource utilisation can change dramatically due in part to synthesis optimisations.
For FPGA designs, generally what you do is start designing the logic and algorithms that you plan to use first. Pick a vendor (e.g. Altera, Xilinx, etc.) and start doing test compiles of parts of your design. To begin with you can pick any family of FPGA, it's just to get an idea of how much in the way of resources are required on various different FPGA families (you can try more than one).
Once you have some idea of what is required, you can then look at special function requirements. You will need LVDS SERDES blocks and PLLs for your camera interface, so look at what speeds each family supports. Also if you are doing lots of multiplication and DSP stuff which it seems like you are, you want to look at families which have an abundance of DSP resources (hardware multipliers, etc.).
Once you have an idea of which family you are going to go for, start designing your code further around that family. Do more test compiles with larger and larger chunks of your design. This will give you a rough estimate of the resource requirements you will need in your final design, and you can then settle on a specific FPGA - the larger they are, the more expensive the are, so you don't really want to be going with one which has hundreds of times more resources than you require, but equally you don't want to go for one too small for the design to fit.
Ideally you want to aim for an FPGA that your design will use about 70% of or less. The resource usage goes up as you use more and more of the design due to logic duplication to meet timing and also routing congestion (too much stuff trying to fit into too small of a space). Why 70%? well that's just a rough guess - sometimes even if you are only using a tiny fraction of the resources, you can run into problems if all of those resources are trying to be in the same place in the design (due to timing requirements, etc.) resulting in much higher peak utilisation.