Re: [FFmpeg-user] Question about "normalize" filter
On Mon, Jan 30, 2023 at 12:23 AM Michael Koch wrote: > Am 29.01.2023 um 23:36 schrieb Paul B Mahol: > > On 1/29/23, Michael Koch wrote: > >> Am 29.01.2023 um 23:07 schrieb Paul B Mahol: > >>> On 1/29/23, Michael Koch wrote: > Am 29.01.2023 um 22:05 schrieb Paul B Mahol: > > On 1/29/23, Michael Koch wrote: > >> Am 29.01.2023 um 19:32 schrieb Paul B Mahol: > >>> On 1/29/23, Michael Koch 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".
Re: [FFmpeg-user] Question about including FFmpeg source codes.
On 1/29/2023 10:03 PM, 김기돈 [메타버스엔터테인먼트] wrote: Q1) Since I'm just using the libav libraries that are included in FFmpeg, do I still need to distribute the source code of FFmpeg? (all of the libav* libraries? lbavcodec, libavformat, libavfilter, etc) The license and livense FAQ should explain that, but my understanding is that you only need to distribute the source code for the parts you distribute in binary form. However you need to look at specific parts for the license types. For instance, libavfilter has parts that are GPL in addition to those that are LGPL. Q2) If I have to distribute all the source codes, then can I upload them to my personal repository and share the link? As long as you -do- make them available, you should be compliant. The LGPL 2.1 license says "You must make sure that they, too, receive or can get the source code." If you have not actually read the LGPL, please do so. It's pretty clear. z! ___ 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] Question about including FFmpeg source codes.
Hi, I have two questions while I am following the license compliance checklist. In the checklist, number 3, it says *"Distribute the source code of FFmpeg, no matter if you modified it or not."* Q1) Since I'm just using the libav libraries that are included in FFmpeg, do I still need to distribute the source code of FFmpeg? Q2) If I have to distribute all the source codes, then can I upload them to my personal repository and share the link? Thank you for your help and have a great day. Sincerely, Charlie -- Netmarble Confidential *이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다. *This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately. ___ 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".
Re: [FFmpeg-user] Generating HLS chunks on demand
Hi Vincent Thank you so much for reporting the details of your journey. There seems to be something with the TS muxer that makes it hard to split a media into rigorously same-length segments. I remember that in the first tests I made before answering your first email in this thread, I tried to use -ss and -t params with both ts and mp4 output formats. The ts segments were seemingly random length whereas the mp4 seemed strictly of the same length. Concomitantly, it seems that HLS is now officially compatible with mp4 segments. See https://en.wikipedia.org/wiki/HTTP_Live_Streaming#Using_fragmented_MP4 . Could that be a way out? Also, care to share the ffprobe command-line or other tool you're using to extract a compact string of video frame types (e.g. "IBBBPPBBPBPB") from a media? Best, Cyril Le ven. 27 janv. 2023 à 06:51, Vincent Deconinck a écrit : > Sorry, I got my tests mixed-up in the previous email :-( > > The command > ffmpeg -ss 0 -i source.ts -c:v libx264 -b:v 1000k -c:a aac -b:a 128k > -x264opts "keyint=25:min-keyint=25:no-scenecut" -t 4 -f mpegts > mpegts_fixed-0.ts > creates a TS with *no missing frames*: > mpegts_fixed-0.ts: > IBBBPPBBPBPBPPBPBPPBPBBPP > IPPBBBPBBPBBBPBBBPBPBBBPP > IBBBPBBBPBBBPBBBPBBBPBBBP > IBBPBPBBBPBBBPBBPBBPBBBPP > > but yet a playlist including that segment (and subsequent segments created > the same way) is not playable. > > So I think the splicing is now correct, but somehow the generated TS is not > compatible with an HLS playback. > > For comparison, the first segment produced by the following command: > ffmpeg -i source.ts -c:v libx264 -b:v 1000k -c:a aac -b:a 128k -x264opts > "keyint=25:min-keyint=25:no-scenecut" -f hls -hls_time 4 -hls_playlist_type > vod hls_fixed.m3u8 > has the exact same gop structure: > hls_fixed0.ts: > IBBBPPBBPBPBPPBPBPPBPBBPP > IPPBBBPBBPBBBPBBBPBPBBBPP > IBBBPBBBPBBBPBBBPBBBPBBBP > IBBPBPBBBPBBBPBBPBBPBBBPP > But when included in a m3u8 playlist, it plays flawlessly. > > The files themselves are different (different size) and a simple ffprobe on > both returns: > Input #0, mpegts, from 'mpegts_fixed-0.ts': > Duration: 00:00:04.02, start: 1.458667, bitrate: 1178 kb/s > Program 1 > Metadata: > service_name: Service01 > service_provider: FFmpeg > Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), > yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn > Stream #0:1[0x101](fra): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 > Hz, stereo, fltp, 130 kb/s > > Input #0, mpegts, from 'hls_fixed0.ts': > Duration: 00:00:04.02, start: 1.458667, bitrate: 1128 kb/s > Program 1 > Metadata: > service_name: Service01 > service_provider: FFmpeg > Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), > yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn > Stream #0:1[0x101](fra): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 > Hz, stereo, fltp, 130 kb/s > > Apart from the bitrate, I see no difference. > > So I believe the difference lies in the hls muxer details, but I have no > idea how to get a single slice using the hls muxer. > > Any idea ? > > Kind regards, > > Vincent > > On Fri, Jan 27, 2023 at 1:38 PM Vincent Deconinck > wrote: > > > Hi all, > > > > I tried analyzing the differences between the ts files generated "all at > > once" (using the hls muxer) and the ones generetad individually using > -ss, > > -t and the mpegts muxer. > > I extracted the gop structure of the first ts segment using ffprobe then > > reformated it in IBBP format, and here are the results > > -f hls (works): > > IBBBPPBBPBPBPPBPBPPBPBBPP > > IPPBBBPBBPBBBPBBBPBPBBBPP > > IBBBPBBBPBBBPBBBPBBBPBBBP > > IBBPBPBBBPBBBPBBPBBPBBBPP > > -ss -t -f mpegts (does not work): > > IBBBPPBBPBPBPPBPBPPBPBBPP > > IPPBBBPBBPBBBPBBBPBPBBBPP > > IBBBPBBBPBBBPBBBPBBBPBBBP > > IBBPBPBBBPBBBPBBPBBP > > (and that's it !) > > > > In other words, the structure looks ok but 5 frames seem to be missing > > from the second segment ! No wonder it looks choppy... > > And indeed, I had overlooked that a simple ffprobe on the non-working > > segment shows a duration of 00:00:03.82 while the working one has a > > duration of 00:00:04.02 (don't know where the 0.02 comes from). > > > > So it seems it all boils down to frame accurate splicing indeed. > > Any help in that regard would be greatly appreciated... > > > > KR, > > > > Vincent > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Vincent Deconinck > > wrote: > > > >> Hi, > >> > >> OK, I made some progress, so replying to self : > >> > >> So although I'm forcing keyframes, the durations are actually not 4 > >>> seconds (the EXT-X-TARGETDURATION field even says 5) > >>> Is there another way to force all segments to be exactly the same > >>> duration ? > >>> > >> > >> After a bit of reading, the -g option only forces the *maximum* interval > >> between keyframes, but the scene detection can trigger the creation of > >>
Re: [FFmpeg-user] Question about "normalize" filter
Am 29.01.2023 um 23:36 schrieb Paul B Mahol: On 1/29/23, Michael Koch wrote: Am 29.01.2023 um 23:07 schrieb Paul B Mahol: On 1/29/23, Michael Koch wrote: Am 29.01.2023 um 22:05 schrieb Paul B Mahol: On 1/29/23, Michael Koch wrote: Am 29.01.2023 um 19:32 schrieb Paul B Mahol: On 1/29/23, Michael Koch 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. 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".
Re: [FFmpeg-user] Question about "normalize" filter
On 1/29/23, Michael Koch wrote: > Am 29.01.2023 um 23:07 schrieb Paul B Mahol: >> On 1/29/23, Michael Koch wrote: >>> Am 29.01.2023 um 22:05 schrieb Paul B Mahol: On 1/29/23, Michael Koch wrote: > Am 29.01.2023 um 19:32 schrieb Paul B Mahol: >> On 1/29/23, Michael Koch 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. ___ 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".
Re: [FFmpeg-user] Question about "normalize" filter
Am 29.01.2023 um 23:07 schrieb Paul B Mahol: On 1/29/23, Michael Koch wrote: Am 29.01.2023 um 22:05 schrieb Paul B Mahol: On 1/29/23, Michael Koch wrote: Am 29.01.2023 um 19:32 schrieb Paul B Mahol: On 1/29/23, Michael Koch 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 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".
Re: [FFmpeg-user] Question about "normalize" filter
On 1/29/23, Michael Koch wrote: > Am 29.01.2023 um 22:05 schrieb Paul B Mahol: >> On 1/29/23, Michael Koch wrote: >>> Am 29.01.2023 um 19:32 schrieb Paul B Mahol: On 1/29/23, Michael Koch 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. ___ 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".
Re: [FFmpeg-user] Question about "normalize" filter
Am 29.01.2023 um 22:05 schrieb Paul B Mahol: On 1/29/23, Michael Koch wrote: Am 29.01.2023 um 19:32 schrieb Paul B Mahol: On 1/29/23, Michael Koch 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. 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".
Re: [FFmpeg-user] Question about "normalize" filter
On 1/29/23, Michael Koch wrote: > Am 29.01.2023 um 19:32 schrieb Paul B Mahol: >> On 1/29/23, Michael Koch 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 > > Micheal > > ___ > 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".
Re: [FFmpeg-user] Question about "normalize" filter
Am 29.01.2023 um 19:32 schrieb Paul B Mahol: On 1/29/23, Michael Koch 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? Micheal ___ 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".
Re: [FFmpeg-user] Question about "normalize" filter
On 1/29/23, Michael Koch 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.
>
> 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".
>
diff --git a/libavfilter/vf_normalize.c b/libavfilter/vf_normalize.c
index 43ed3c67b3..91499bd009 100644
--- a/libavfilter/vf_normalize.c
+++ b/libavfilter/vf_normalize.c
@@ -101,7 +101,9 @@ typedef struct NormalizeContext {
uint8_t whitept[4];
int smoothing;
float independence;
+float independence2;
float strength;
+float strength2;
uint8_t co[4]; // Offsets to R,G,B,A bytes respectively in each pixel
int depth;
@@ -132,6 +134,8 @@ static const AVOption normalize_options[] = {
{ "smoothing", "amount of temporal smoothing of the input range, to reduce flicker", OFFSET(smoothing), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX/8, FLAGS },
{ "independence", "proportion of independent to linked channel normalization", OFFSET(independence), AV_OPT_TYPE_FLOAT, {.dbl=1.0}, 0.0, 1.0, FLAGSR },
{ "strength", "strength of filter, from no effect to full normalization", OFFSET(strength), AV_OPT_TYPE_FLOAT, {.dbl=1.0}, 0.0, 1.0, FLAGSR },
+{ "independence2", "proportion of independent to linked channel normalization, for brightest input", OFFSET(independence2), AV_OPT_TYPE_FLOAT, {.dbl=-1.0}, -1.0, 1.0, FLAGSR },
+{ "strength2", "strength of filter, from no effect to full normalization, for brightest input", OFFSET(strength2), AV_OPT_TYPE_FLOAT, {.dbl=-1.0}, -1.0, 1.0, FLAGSR },
{ NULL }
};
@@ -335,22 +339,30 @@ static void normalize(NormalizeContext *s, AVFrame *in, AVFrame *out)
// Now, process each channel to determine the input and output range and
// build the lookup tables.
for (c = 0; c < 3; c++) {
+float strength[2], independence[2];
int in_val;
+
+strength[0] = s->strength;
+strength[1] = s->strength2 >= 0.f ? s->strength2 : s->strength;
+
+independence[0] = s->independence;
+independence[1] = s->independence2 >= 0.f ? s->independence2 : s->independence;
+
// Adjust the input range for this channel [min.smoothed,max.smoothed]
// by mixing in the correct proportion of the linked normalization
// input range [rgb_min_smoothed,rgb_max_smoothed].
-min[c].smoothed = (min[c].smoothed * s->independence)
-+ (rgb_min_smoothed * (1.0f - s->independence));
-max[c].smoothed = (max[c].smoothed * s->independence)
-+ (rgb_max_smoothed * (1.0f - s->independence));
+min[c].smoothed = (min[c].smoothed * independence[0])
++ (rgb_min_smoothed * (1.0f - independence[0]));
+max[c].smoothed = (max[c].smoothed * independence[1])
++ (rgb_max_smoothed * (1.0f - independence[1]));
// Calculate the output range [min.out,max.out] as a ratio of the full-
// strength output range [blackpt,whitept] and the original input range
// [min.in,max.in], based on the user-specified filter strength.
-min[c].out = (s->sblackpt[c] *s->strength)
- + (min[c].in * (1.0f - s->strength));
-max[c].out = (s->swhitept[c] *s->strength)
- + (max[c].in * (1.0f - s->strength));
+min[c].out = (s->sblackpt[c] *strength[0])
+ + (min[c].in * (1.0f - strength[0]));
+max[c].out = (s->swhitept[c] *strength[1])
+ + (max[c].in * (1.0f - strength[1]));
// Now, build a lookup table which linearly maps the adjusted input range
// [min.smoothed,max.smoothed] to the output range [min.out,max.out].
___
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] Question about "normalize" filter
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. 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".
