Oct 13, 2023, 22:31 by vittorio.giov...@gmail.com: > On Fri, Oct 13, 2023 at 3:19 PM Michael Niedermayer <mich...@niedermayer.cc> > wrote: > >> Hi everyone >> >> I propose using 15k$ from SPI for funding sws cleanup work. >> this is substantially less than what people belive this needs (see IRC >> logs from yesterday or so) >> So it really is more a small price for a good deed and not proper payment. >> This of course is only available to competent developers. (exact rules or >> how thats determined >> would still need to be decided unless its a clear case) >> Also the exact outcome and goal would need to be discussed by the >> community and whoever >> does the work. >> But some goals would probably be to make sws >> * pleasent to work with >> * similar speed or faster >> * proper multithreading >> * proper full colorspace convertion not ignoring gamma, primaries, ... >> * clean / understandable modular design (maybe everything can be a >> "Filter" inside sws >> that get build into a chain) >> >> Proper payment (50k$ maybe) would be too much in relation to what SPI has >> ATM (150k$) >> >> Above all, this is just my oppinion, the actual SPI funding also would >> need to >> be approved by the community. This can happen after a specific volunteer >> comes forth >> or before, whichever way the community prefers. >> > > Hi Michael, > I don't mean to rain on your parade, but I think there are better image > libraries that are more accurate, faster, and can implement proper > tonemapping than sws -- zimg, and libplacebo are the prime examples. I > believe it would make more sense to integrate one of them in sws as a > backend (and fallback) so that the api doesn't change, or, if we absolutely > need no external deps, then write an entirely new library, but 15k$ work > for "cleanup" on a library noone consciously wants to use seems wasteful > IMO. >
I agree, I'd rather see this money being spent to give libplacebo a software path and having swscale link against it. We can talk about importing the project as a whole separately - I don't think it's necessary, though. zimg would need far too much work, IMO. But I don't mind being wrong here. I wouldn't object to writing a new library or improving swscale either - but I do think this has to be done with a plan we could agree on. As I said yesterday, it is easy to make a mistake. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
