[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Pixel transforms and SIMD
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2009-01-09 3:42:40
Message-ID: 4966C7B0.9040607 () acm ! org
[Download RAW message or body]

Matthew Woehlke wrote:
> James Richard Tyrer wrote:
>> Matthew Woehlke wrote:
>>> James Richard Tyrer wrote:
>>>> Actually, photography is going to demand it. :-) Clearly image 
>>>> processing is going to demand additional hardware acceleration.
>>>> 
>>>> 
>>>> That is, how long will it take to change the gamma on a 12 
>>>> MPixel image? You need this interactive so you can decide what 
>>>> looks best.
>>> Have you ever used rawstudio? It's close enough to "real time" 
>>> that I don't find it at all problematic, and that's on a 2x2.0 
>>> GHz machine, which is getting long in the tooth by today's 
>>> standards. (And yes, the images I work with are 12 MP... 12.3 in 
>>> fact.)
>> What data type are you using for the pixels?
> 
> Does it really matter? If it's significantly faster to do an 
> operation in RGB/i8 than <insert some color space here>, I'd think 
> you'd /want/ to downscale, do it cheap, and do the "real" conversion 
> in the background. As long as you get a good idea in real-time, it's 
> not a problem if the quality-preserving operation takes a few 
> seconds.
> 
>> I doubt that any commercially available software uses an FFT based 
>> 2D filter.
> 
> I don't know what rawstudio uses (but I suspect you'd be surprised), 
> but so what? Debayerize isn't an operation you're doing frequently. 
> Besides, you seem to be essentially describing a convolution filter,
> 
A convolution filter works on data in the time domain.  An FFT based
filter works on data in the frequency domain.  As I previously said, you
use an FFT filter because it can produce a perfect response, something
that a FIR (convolution) filter can not do.

> and what I've seen of those isn't as slow as what you seem to be 
> describing.
> 
You seem to be agreeing with me that speed isn't (personally) important.
However, I am saying that the market would reject software that took
more than 5 minutes per image.

>> Personally, I would rather wait several minutes per picture to get 
>> rid of the artifacts that the privative numerical methods cause, 
>> but most people probably wouldn't like that.
> 
> Okay, so there is a "preview" mode and a "max quality" mode,

And how do you propose to generate the preview?  You couldn't generate
it using the same algorithm.  You can always generate a quick preview
by cutting the image dimensions in half but it isn't a true preview and
there is a slight phase error.

> and neither of us cares if the latter takes a minute or so. What's 
> the problem? :-)
> 
I agree.  However, would you be willing to wait more than 5 minutes for
better quality?  Perhaps not a problem for a few pictures, but what if
you have a lot of pictures to do?  What if you had over 100 images and
it was 10 minutes per image?  Clearly, there is a point in the number of
images to process or the time per image that it is too long to wait.

-- 
JRT

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]