11 replies to this topic

[Pushapjit]

I've a picture, I want to edit the picture at pixel level. I wanna know that can we develop the code using DirectX for picture editing.

[Reedbeta]

Why would you want to use DirectX? If you can load the bitmap into memory you can edit pixels just by changing the bytes.

[Goz]

Would be dead quick for doing "filters", re-sizing and tranforms ...

[Vilem Otte]

Why not, filters would be much faster using D3D. But!!!!
It'll not run anywhere! If PC hasn't GPU, that supports DirectX - or doesn't support minimal shader model required for that. So it's much better to just edit using standart CPU instructions - well better for people with "office" or low-end computers (if you wanna run it fast, realtime and everywhere - use assembly language - it'll be fastest, much much more faster than object oriented languague, althrough DirectX would be in realtime too, cause it's using GPU). I'd like to see editor with Direct3D acceleration, it'd be fastest (much more than photoshop or gimp) and i'd really like to try it. But it's your choice, not mine. Just can say...... go for it!

[starstutter]

I can definitley see why you would want that option for the more complex filters and larger images that take forever in oridinary systems, but it might get very tricky dealing with texels in the pixel shaders. It would be very easy to lower the quality or have it come out slightly different in an undesirable way.

The only way I can really think of what you are wanting is to re-render the texture as a fullscreen quad, but again, it would be very tough to keep it from changing the image in other ways you don't want.

If you can pull it off, it's a very good idea and a great option for mid-high range pc's, but it needs to remain an option, so it can run on lower end hardware.

[monjardin]

What's wrong with Microsoft Paint?

[starstutter]

monjardin said:

What's wrong with Microsoft Paint?

all your base are belong to that guy....

[genetransfer]

Quote

all your base are belong....

lol , that always makes me laugh.

[kusma]

Vilem Otte said:

use assembly language - it'll be fastest, much much more faster than object oriented languague

Yes, assembly automatically makes any code run fast. It's not like compilers are smart enough to use assembly themselves either. And most programmer are way better than the compiler at keeping track of the latest CPUs optimizing rules.

Yeah, spot the sarcasm above. As a smart man once said, "Your compiler can generate better code in milliseconds than you can write in hours". I'm not saying assembly has no uses, I'm saying you shouldn't automatically assume assembly has anything to do with what you need to be doing to get performance up. In most cases you'd be dead wrong.

[Reedbeta]

kusma is mostly right; that said, most compilers still aren't that great at generating SIMD instructions (SSE on x86 processors), or they don't generate them at all. You can still get a lot of performance improvement by recoding math-heavy routines in assembly using SIMD instructions to exploit data parallelism. This is particularly useful for graphics routines like filters, which are so easy to parallelize that they're called "embarassingly" parallel.

[rouncer]

You can, I do it all the time (make my own graphics editors), use d3d - direct
draw sucks in general and isnt supported anymore.

Its awesome practice to write your own media making programs, but your
right in the deep end in d3d, im putting it on my little brother at the moment
and hes having a tricky time with it.

If you make your own graphics program... you dont even need to buy a pro
one, because they are easy to write.

The first thing you should try is not just replacing pixels, add and subtract
them thats a real good effect.
(theres lots more too, you could discover for yourself)

[kusma]

Reedbeta said:

You can still get a lot of performance improvement by recoding math-heavy routines in assembly using SIMD instructions to exploit data parallelism.

This is still something that shouldn't be done blindly, it should only be based on accurate profiling. And in most cases you can find some other higher-level optimization that greatly reduce the need for SIMD-parallelization. After all, maintaining assembly-code is a bloody pain in the ass.