On Mon, Jan 30, 2023 at 12:23 AM Michael Koch <astroelectro...@t-online.de> wrote:
> Am 29.01.2023 um 23:36 schrieb Paul B Mahol: > > On 1/29/23, Michael Koch <astroelectro...@t-online.de> wrote: > >> Am 29.01.2023 um 23:07 schrieb Paul B Mahol: > >>> On 1/29/23, Michael Koch <astroelectro...@t-online.de> wrote: > >>>> Am 29.01.2023 um 22:05 schrieb Paul B Mahol: > >>>>> On 1/29/23, Michael Koch <astroelectro...@t-online.de> wrote: > >>>>>> Am 29.01.2023 um 19:32 schrieb Paul B Mahol: > >>>>>>> On 1/29/23, Michael Koch <astroelectro...@t-online.de> wrote: > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> if I understood the documentation correctly, the normalize filter > >>>>>>>> maps > >>>>>>>> the darkest input pixel to blackpt and the brightest input pixel > to > >>>>>>>> whitept: > >>>>>>>> darkest pixel --> blackpt > >>>>>>>> brightest pixel --> whitept > >>>>>>>> > >>>>>>>> However I need a slightly different mapping: > >>>>>>>> A black input pixel shall remain black, and the brightest input > >>>>>>>> pixel > >>>>>>>> shall become white. > >>>>>>>> black --> blackpt > >>>>>>>> brightest pixel --> whitept > >>>>>>>> > >>>>>>>> With other words: Just multiply all pixels by a suitable constant. > >>>>>>>> Don't > >>>>>>>> add or subtract anything. > >>>>>>>> Is this possible? > >>>>>>>> > >>>>>>>> Known workaround: Make sure that the input frame contains a black > >>>>>>>> pixel, > >>>>>>>> by inserting one in a corner. > >>>>>>> Try attached patch. > >>>>>> How must I set the options for the desired behaviour? > >>>>> Set first strength to reverse of second strength. > >>>>> So 1.0 and 0.0 or 0.0 and 1.0 > >>>> I did try with strength=0:strength2=1 but the output isn't as > expected. > >>>> > >>>> I'm using this input image: > >>>> http://www.astro-electronic.de/flat.png > >>>> > >>>> The pixel values are about 171 in the center and 107 in the top right > >>>> corner. > >>>> The center to corner ratio is 171 / 107 = 1.6 > >>>> > >>>> In the output image I measure 248 in the center (which is almost as > >>>> expected, probably correct because I'm measuring the average of a 7x7 > >>>> neighborhood), but I measure 122 in the top right corner. > >>>> The center to corner ratio is 248 / 122 = 2.03 > >>>> The corner is too dark. > >>>> > >>> I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left pixels > >>> (as they are darkest) and they are not changing (min values are same > >>> with and without filter run) > >>> With default parameters and just strength(2) set to your values, so > >>> the darkest pixels are left untouched. Did not checked brightest > >>> pixels output, but they should be correct too. > >> But that's not the behaviour I need. All pixels shall be multiplied by > >> the same suitable constant, so that the brightest pixel becomes white. > >> > >> Input center: 171 > >> Input corner: 107 > >> > >> constant c = 255 / 171 =1.49 > >> Output center: 171 * c = 255 > >> Output corner: 107 * c = 160 > >> > > Normalization does not do that and that functionality does not belong > > to such filter, it stretches ranges of all pixel values so they reach > > maximal possible range. > > Can't you just add an option that disables the minimum finding > algorithm, and set the minimum to zero (=black)? That would do the job. > I just did, but for whatever reason you think its incorrect. > > Let me explain why I need this kind of normalization. > Most lenses have vignetting. Especially in astronomical images, > vignetting must be corrected before any other image processing can be > done. For this purpose a flatfield image is taken with the same lens at > the same aperture, but with a uniform white screen in front of the lens. > Normally the flatfield image is exposed at roughly 50% gray level, to > avoid problems with nonlinearity near white level. The linked image is > the flatfield. > Vignetting in an astronomical image is corrected by dividing the image > by the flatfield. That can be done with the blend filter. > If I use the flatfied as-is (with roughly 50% gray level), then the > image is effectively multiplied by a factor 2. That's a problem because > bright pixels might get clipped. To minimize this problem, I want to > normalize the flatfield as close to white level as possible, before > using it. > > Michael > > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".