- Cin - Cinelerra-GG Mailing Lists

Upd: More findings about openEXR and libtiff
by Andrew Randrianasulu 16 Mar '20

16 Mar '20

While my b44 patch for openEXR works, it produces nearly same 32Mb big images as uncompressed tiff.. (for rgba-float project. - correspond to documentation I cited! "Channels of type UINT or FLOAT are not compressed." so, no use in cinelerra currently? (HALF = half-float, 16-bit fp per component, IIRC) there are LOSSY subtypes of compression, DWAA/DWAB - but they are mostly for proxies and final renders where "small compression is acceptable" but they require some more parameters (compression ratio), so not for this night And my hacking on TIFFTAG_PHOTOMETRIC was *wrong* .... resulted image was treated as monochrome/1bit in GIMP .. :/ so, this hunk can be dropped. sorry. ---------- Пересланное сообщение ---------- Тема: More findings about openEXR and libtiff Дата: Понедельник 16 марта 2020 Отправитель: Andrew Randrianasulu <randrianasulu(a)gmail.com> Получатель: "Cinelerra.GG" <cin(a)lists.cinelerra-gg.org> So, I digged deeper. First, gimp source says: https://github.com/GNOME/gimp/blob/mainline/plug-ins/file-tiff/file-tiff-lo… else if (extra == 0 && ((photomet == PHOTOMETRIC_RGB && spp > 3) || /* All other color space expect 1 channel (grayscale, * palette, mask). */ (photomet != PHOTOMETRIC_RGB && spp > 1))) { /* ExtraSamples field not set, yet we have more channels than * the PhotometricInterpretation field suggests. * This should not happen as the spec clearly says "This field * must be present if there are extra samples". So the files * can be considered non-conformant. * Let's ask what to do with the channel. */ extra_message = _("Non-conformant TIFF: extra channels without 'ExtraSamples' field.") https://www.awaresystems.be/imaging/tiff/tifftags/photometricinterpretation… TIFF Tag PhotometricInterpretation IFD Image Code 262 (hex 0x0106) Name PhotometricInterpretation LibTiff name TIFFTAG_PHOTOMETRIC Type SHORT Count 1 Default None Description The color space of the image data. The specification considers these values baseline: 0 = WhiteIsZero. For bilevel and grayscale images: 0 is imaged as white. 1 = BlackIsZero. For bilevel and grayscale images: 0 is imaged as black. ------>>>>>----- 2 = RGB. RGB value of (0,0,0) represents black, and (255,255,255) represents white, assuming 8-bit components. The components are stored in the indicated order: first Red, then Green, then Blue. ------<<<<<----- 3 = Palette color. In this model, a color is described with a single component. The value of the component is used as an index into the red, green and blue curves in the ColorMap field to retrieve an RGB triplet that defines the color. When PhotometricInterpretation=3 is used, ColorMap must be present and SamplesPerPixel must be 1. 4 = Transparency Mask. This means that the image is used to define an irregularly shaped region of another image in the same TIFF file. SamplesPerPixel and BitsPerSample must be 1. PackBits compression is recommended. The 1-bits define the interior of the region; the 0-bits define the exterior of the region. These values are considered an extension: 5 = Seperated, usually CMYK. 6 = YCbCr 8 = CIE L*a*b* (see also specification supplements 1 and 2) 9 = CIE L*a*b*, alternate encoding also known as ICC L*a*b* (see also specification supplements 1 and 2) The TIFF-F specification (RFC 2301) defines: 10 = CIE L*a*b*, alternate encoding also known as ITU L*a*b*, defined in ITU-T Rec. T.42, used in the TIFF-F and TIFF-FX standard (RFC 2301). The Decode tag, if present, holds information about this particular CIE L*a*b* encoding. The DNG specification adds these definitions: 32803 = CFA (Color Filter Array) 34892 = LinearRaw LibTiff defines mostly the same values, and adds support for Pixar LogL and LogLuv encoding: PHOTOMETRIC_MINISWHITE = 0; PHOTOMETRIC_MINISBLACK = 1; PHOTOMETRIC_RGB = 2; PHOTOMETRIC_PALETTE = 3; PHOTOMETRIC_MASK = 4; PHOTOMETRIC_SEPARATED = 5; PHOTOMETRIC_YCBCR = 6; PHOTOMETRIC_CIELAB = 8; PHOTOMETRIC_ICCLAB = 9; PHOTOMETRIC_ITULAB = 10; PHOTOMETRIC_LOGL = 32844; PHOTOMETRIC_LOGLUV = 32845; So, *I think* tiff exporter shouldn't use this tag on alpha/32-bit per channel images .... if(frame->get_color_model() == BC_RGB888) // PHOTOMETRIC RGB only valid for 8-bit RGB TIFFSetField(stream, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB); currently recompiling Cin with this change .... probably additional tag needed for alpha samples ... so, not final Next into openEXR! https://en.wikipedia.org/wiki/OpenEXR B44 This form of compression is lossy for half data and stores 32-bit data uncompressed. It maintains a fixed compression size of either 2.28:1 or 4.57:1 and is designed for realtime playback. B44 compresses uniformly regardless of image content. [10] B44A An extension to B44 where areas of flat color are further compressed, such as alpha channels. Mmm.. realtime playback! https://rainboxlab.org/downloads/documents/EXR_Data_Compression.pdf says basically same thing about B44/B44A, with slightly more tech details. Added, currently compiles (see draft patch, made in analogy with my tiff patch) OpenEXR lib multithreading topic: https://lists.nongnu.org/archive/html/openexr-devel/2009-11/msg00001.html --quote--- When threading is enabled in the library, multiple scanline blocks or tiles are processed concurrently. A scanline block is 32 lines for PIZ compression. Threading doesn't kick in unless each writePixels() call supplies multiple blocks' worth of pixels. For best threading performance, write the entire image with a single writePixels() call. See also Section 7.2 of http://www.openexr.com/ReadingAndWritingImageFiles.pdf. ----quote end--- from this file ... -----****---- Multithreaded I/O The IlmImf library supports multithreaded file input and output where the library creates its own worker threads that are independent of the application program's threads. When an application thread calls readPixels(), readTiles(), writePixels() or writeTiles() to read or write multiple scan lines or tiles at once, the library's worker threads process the tiles or scanlines in parallel. During startup, the application program must enable multithreading by calling function setGlobalThreadCount(). This tells the IlmImf library how many worker threads it should create. (As a special case, setting the number of worker threads to zero reverts to single-threaded operation; reading and writing image files happens entirely in the application thread that calls the IlmImf library.) Multithreaded I/O, Multithreaded Application Program Function setGlobalThreadCount() creates a global pool of worker threads inside the IlmImf library. If an application program has multiple threads, and those threads read or write several OpenEXR files at the same time, then the worker threads must be shared among the application threads. By default each file will attempt to use the entire worker thread pool for itself. If two files are read or written simultaneously by two application threads, then it is possible that all worker threads perform I/O on behalf of one of the files, while I/O for the other file is stalled. In order to avoid this situation, the constructors for input and output file objects take an optional numThreads argument. This gives the application program more control over how many threads will be kept busy reading or writing a particular file. -----****------ sounds like something to try, using available within Cin variable about cpu count. -------------------------------------------------------

1 0

More findings about openEXR and libtiff
by Andrew Randrianasulu 16 Mar '20

16 Mar '20

So, I digged deeper. First, gimp source says: https://github.com/GNOME/gimp/blob/mainline/plug-ins/file-tiff/file-tiff-lo… else if (extra == 0 && ((photomet == PHOTOMETRIC_RGB && spp > 3) || /* All other color space expect 1 channel (grayscale, * palette, mask). */ (photomet != PHOTOMETRIC_RGB && spp > 1))) { /* ExtraSamples field not set, yet we have more channels than * the PhotometricInterpretation field suggests. * This should not happen as the spec clearly says "This field * must be present if there are extra samples". So the files * can be considered non-conformant. * Let's ask what to do with the channel. */ extra_message = _("Non-conformant TIFF: extra channels without 'ExtraSamples' field.") https://www.awaresystems.be/imaging/tiff/tifftags/photometricinterpretation… TIFF Tag PhotometricInterpretation IFD Image Code 262 (hex 0x0106) Name PhotometricInterpretation LibTiff name TIFFTAG_PHOTOMETRIC Type SHORT Count 1 Default None Description The color space of the image data. The specification considers these values baseline: 0 = WhiteIsZero. For bilevel and grayscale images: 0 is imaged as white. 1 = BlackIsZero. For bilevel and grayscale images: 0 is imaged as black. ------>>>>>----- 2 = RGB. RGB value of (0,0,0) represents black, and (255,255,255) represents white, assuming 8-bit components. The components are stored in the indicated order: first Red, then Green, then Blue. ------<<<<<----- 3 = Palette color. In this model, a color is described with a single component. The value of the component is used as an index into the red, green and blue curves in the ColorMap field to retrieve an RGB triplet that defines the color. When PhotometricInterpretation=3 is used, ColorMap must be present and SamplesPerPixel must be 1. 4 = Transparency Mask. This means that the image is used to define an irregularly shaped region of another image in the same TIFF file. SamplesPerPixel and BitsPerSample must be 1. PackBits compression is recommended. The 1-bits define the interior of the region; the 0-bits define the exterior of the region. These values are considered an extension: 5 = Seperated, usually CMYK. 6 = YCbCr 8 = CIE L*a*b* (see also specification supplements 1 and 2) 9 = CIE L*a*b*, alternate encoding also known as ICC L*a*b* (see also specification supplements 1 and 2) The TIFF-F specification (RFC 2301) defines: 10 = CIE L*a*b*, alternate encoding also known as ITU L*a*b*, defined in ITU-T Rec. T.42, used in the TIFF-F and TIFF-FX standard (RFC 2301). The Decode tag, if present, holds information about this particular CIE L*a*b* encoding. The DNG specification adds these definitions: 32803 = CFA (Color Filter Array) 34892 = LinearRaw LibTiff defines mostly the same values, and adds support for Pixar LogL and LogLuv encoding: PHOTOMETRIC_MINISWHITE = 0; PHOTOMETRIC_MINISBLACK = 1; PHOTOMETRIC_RGB = 2; PHOTOMETRIC_PALETTE = 3; PHOTOMETRIC_MASK = 4; PHOTOMETRIC_SEPARATED = 5; PHOTOMETRIC_YCBCR = 6; PHOTOMETRIC_CIELAB = 8; PHOTOMETRIC_ICCLAB = 9; PHOTOMETRIC_ITULAB = 10; PHOTOMETRIC_LOGL = 32844; PHOTOMETRIC_LOGLUV = 32845; So, *I think* tiff exporter shouldn't use this tag on alpha/32-bit per channel images .... if(frame->get_color_model() == BC_RGB888) // PHOTOMETRIC RGB only valid for 8-bit RGB TIFFSetField(stream, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB); currently recompiling Cin with this change .... probably additional tag needed for alpha samples ... so, not final Next into openEXR! https://en.wikipedia.org/wiki/OpenEXR B44 This form of compression is lossy for half data and stores 32-bit data uncompressed. It maintains a fixed compression size of either 2.28:1 or 4.57:1 and is designed for realtime playback. B44 compresses uniformly regardless of image content. [10] B44A An extension to B44 where areas of flat color are further compressed, such as alpha channels. Mmm.. realtime playback! https://rainboxlab.org/downloads/documents/EXR_Data_Compression.pdf says basically same thing about B44/B44A, with slightly more tech details. Added, currently compiles (see draft patch, made in analogy with my tiff patch) OpenEXR lib multithreading topic: https://lists.nongnu.org/archive/html/openexr-devel/2009-11/msg00001.html --quote--- When threading is enabled in the library, multiple scanline blocks or tiles are processed concurrently. A scanline block is 32 lines for PIZ compression. Threading doesn't kick in unless each writePixels() call supplies multiple blocks' worth of pixels. For best threading performance, write the entire image with a single writePixels() call. See also Section 7.2 of http://www.openexr.com/ReadingAndWritingImageFiles.pdf. ----quote end--- from this file ... -----****---- Multithreaded I/O The IlmImf library supports multithreaded file input and output where the library creates its own worker threads that are independent of the application program's threads. When an application thread calls readPixels(), readTiles(), writePixels() or writeTiles() to read or write multiple scan lines or tiles at once, the library's worker threads process the tiles or scanlines in parallel. During startup, the application program must enable multithreading by calling function setGlobalThreadCount(). This tells the IlmImf library how many worker threads it should create. (As a special case, setting the number of worker threads to zero reverts to single-threaded operation; reading and writing image files happens entirely in the application thread that calls the IlmImf library.) Multithreaded I/O, Multithreaded Application Program Function setGlobalThreadCount() creates a global pool of worker threads inside the IlmImf library. If an application program has multiple threads, and those threads read or write several OpenEXR files at the same time, then the worker threads must be shared among the application threads. By default each file will attempt to use the entire worker thread pool for itself. If two files are read or written simultaneously by two application threads, then it is possible that all worker threads perform I/O on behalf of one of the files, while I/O for the other file is stalled. In order to avoid this situation, the constructors for input and output file objects take an optional numThreads argument. This gives the application program more control over how many threads will be kept busy reading or writing a particular file. -----****------ sounds like something to try, using available within Cin variable about cpu count.

1 0

OGG validation?
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

I recall some strangeness with recently re-added OGG/theora output. I found this comment in old CinCV repo: https://repo.or.cz/cinelerra_cv/ct.git/commit/5d7c9bfd9dbfa3c4ae673a8c8b3d3… "r636: j^'s (j(a)v2v.cc) patch to mux ogg in a way compilant with specification y - makes oggz-validate happy and probably some players also" I followed app name and landed here: https://www.xiph.org/oggz/ Oggz Oggz comprises liboggz and the tool oggz, which provides commands to inspect, edit and validate Ogg files. The oggz-chop tool can also be used to serve time ranges of Ogg media over HTTP by any web server that supports CGI. liboggz is a C library for reading and writing Ogg files and streams. It offers various improvements over the reference libogg, including support for seeking, validation and timestamp interpretation. Download The latest version is 1.1.1, released Apr 29 2010. http://git.xiph.org/?p=liboggz.git;a=shortlog git has some improvements over it .... I hope it will helpful in catching those strange errors about not marked keyframes ...

2 2

vmodule.c and caching of decoded video?
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

Question: I was looking at old CinCV repo and found there this commit: https://repo.or.cz/cinelerra_cv/ct.git/commit/1be2d5c765349982fa1d9b72bdcaa… r743: Enable caching of frames even when not rendering static frames diff --git a/cinelerra/vmodule.C b/cinelerra/vmodule.C index 65efb0a..841fb40 100644 (file) --- a/cinelerra/vmodule.C +++ b/cinelerra/vmodule.C @@ -235,12 +235,12 @@ SET_TRACE // file -> temp // Cache for single frame only - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(1); SET_TRACE result = source->read_frame((*input)); SET_TRACE - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(0); //printf("VModule::import_frame 1 %lld %f\n", input_position, frame_rate); @@ -306,10 +306,10 @@ SET_TRACE { //printf("VModule::import_frame 30 %p\n", output); // Cache single frames only - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(1); result = source->read_frame(output); - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(0); //printf("VModule::import_frame 40\n"); } cehtehs branch of CinelerraCV in modern CinGG same function done a bit differently, but still only enables caching of single frames. Why? https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerr… 292 int use_cache = renderengine && 293 renderengine->command->single_frame(); search for more instances of use_cache .... Of course there might be some bug somewhere preventing such usage - but I really like to see this commented, then ... Ah, it was disabled again in https://repo.or.cz/cinelerra_cv/ct.git/commit/c8d7b9183ac263d540ccbc15b125f… (part of big 2.1 merge) I wonder what will hapen if I enable this .. :} Something else to try .... As far as I understand, anync decoding by itself also disabled in CinGG, looking at same module? But even normal decoding still may leave few frames around, and Cin may reuse them, for example for backward playback, no? Having some clarification about what each mode was supposed to do at the top of file will be great .... Unfortunately, I don't understand Cin enough for making those top comments.. I think. This idea obviously can be low priority - just add new module comment each time you edited said module ..so, after some time thwy all will contain brief description of their functions and quircks/historical artifacts, I think PS; I spend a lot of time trying to debug this bc2000 playback crash - so yes, threading is not as simple in impl as I made it on (virtual) paper .. :/

3 2

Today's GIT checkin includes 18 new Shape Wipe video transitions
by Phyllis Smith 15 Mar '20

15 Mar '20

Rafa created 15 new Shape Wipe video transitions + 3 Cinelerra new shape wipes. Some are pretty cool and I like Rare Spiral and Star. The other big thing is BT #375 for the first bug which is Open EDL level backups which I will explain in that BT once I get around to it. Phyllis/GG

5 5

filetiff patch
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

I tried few more compression schemas from libtiff 4.0.10 tiff.h: #define TIFFTAG_COMPRESSION 259 /* data compression technique */ #define COMPRESSION_NONE 1 /* dump mode */ #define COMPRESSION_CCITTRLE 2 /* CCITT modified Huffman RLE */ #define COMPRESSION_CCITTFAX3 3 /* CCITT Group 3 fax encoding */ #define COMPRESSION_CCITT_T4 3 /* CCITT T.4 (TIFF 6 name) */ #define COMPRESSION_CCITTFAX4 4 /* CCITT Group 4 fax encoding */ #define COMPRESSION_CCITT_T6 4 /* CCITT T.6 (TIFF 6 name) */ #define COMPRESSION_LZW 5 /* Lempel-Ziv & Welch */ #define COMPRESSION_OJPEG 6 /* !6.0 JPEG */ #define COMPRESSION_JPEG 7 /* %JPEG DCT compression */ #define COMPRESSION_T85 9 /* !TIFF/FX T.85 JBIG compression */ #define COMPRESSION_T43 10 /* !TIFF/FX T.43 colour by layered JBIG compression */ #define COMPRESSION_NEXT 32766 /* NeXT 2-bit RLE */ #define COMPRESSION_CCITTRLEW 32771 /* #1 w/ word alignment */ #define COMPRESSION_PACKBITS 32773 /* Macintosh RLE */ #define COMPRESSION_THUNDERSCAN 32809 /* ThunderScan RLE */ /* codes 32895-32898 are reserved for ANSI IT8 TIFF/IT <dkelly(a)apago.com) */ #define COMPRESSION_IT8CTPAD 32895 /* IT8 CT w/padding */ #define COMPRESSION_IT8LW 32896 /* IT8 Linework RLE */ #define COMPRESSION_IT8MP 32897 /* IT8 Monochrome picture */ #define COMPRESSION_IT8BL 32898 /* IT8 Binary line art */ /* compression codes 32908-32911 are reserved for Pixar */ #define COMPRESSION_PIXARFILM 32908 /* Pixar companded 10bit LZW */ #define COMPRESSION_PIXARLOG 32909 /* Pixar companded 11bit ZIP */ #define COMPRESSION_DEFLATE 32946 /* Deflate compression */ #define COMPRESSION_ADOBE_DEFLATE 8 /* Deflate compression, as recognized by Adobe */ /* compression code 32947 is reserved for Oceana Matrix <dev(a)oceana.com> */ #define COMPRESSION_DCS 32947 /* Kodak DCS encoding */ #define COMPRESSION_JBIG 34661 /* ISO JBIG */ #define COMPRESSION_SGILOG 34676 /* SGI Log Luminance RLE */ #define COMPRESSION_SGILOG24 34677 /* SGI Log 24-bit packed */ #define COMPRESSION_JP2000 34712 /* Leadtools JPEG2000 */ #define COMPRESSION_LERC 34887 /* ESRI Lerc codec: https://github.com/Esri/lerc */ /* compression codes 34887-34889 are reserved for ESRI */ #define COMPRESSION_LZMA 34925 /* LZMA2 */ #define COMPRESSION_ZSTD 50000 /* ZSTD: WARNING not registered in Adobe-maintained registry */ #define COMPRESSION_WEBP 50001 /* WEBP: WARNING not registered in Adobe-maintained registry */ Sadly, only deflate worked with 32-bit floating point session. Others complained like FileTIFF: Compression scheme 32908 scanline encoding is not implemented. Also, GIMP complained a bit, but allow me to open image anyway: tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. bps: 32 load_contiguous bytes_per_pixel: 16, format: 16 Probably for other compression schemas differet, non-scanline method of calling libtiff must be used? Also, a bit of nipicking (?) but Cinelerra doesn' show single-frame rendering correctly in stats: ** rendered 0 frames in 14.170 secs, 0.000 fps Render::render_single: Session finished. ** rendered 355 frames in 249.619 secs, 1.422 fps Render::render_single: Session finished. ** rendered 0 frames in 3.640 secs, 0.000 fps Shouldn't it be 1 frame, at least?

1 0

Wordpress website
by Olivier Humbert 14 Mar '20

14 Mar '20

Hi there. That was a long time I didn't received any notification from the cin-gg wordpress (probably around 2 or 3 months). Then, I logged in to check by myself if there was really no new translation update to do. I found some and did those, so French translation is back to 100% there. Just leaving this email here because something looks wrong with the notification system. Also, I'd encourage other language translators to logged in and check s well if that's a while they didn't receveid a notifcation too. Hope that helps. Olivier -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK

3 9

HAP codec, VC2 (dirac) encoder in ffmpeg tests
by Andrew Randrianasulu 14 Mar '20

14 Mar '20

Hello! Sorry if I push too many mails with questionable ideas, but ... I recently was reading phoronix, Michael put up this article: https://www.phoronix.com/scan.php?page=news_item&px=New-High-Quality-GPU-Co… "Written by Michael Larabel in Standards on 9 March 2020 at 09:50 AM EDT. 20 Comments STANDARDS -- Compression experts Rich Geldreich and Stephanie Hurlburt with their Binomial consulting firm are about to release a high-quality open-source compression codec for GPUs." This made me think, because I already saw something along those lines.... https://vdmx.vidvox.net/blog/hap --quote-- When should I use Hap? Will my hardware support Hap? For most realtime video projects, traditional CPU-based codecs such as Photo-JPEG or the Apple Intermediate Codec offer a reasonable tradeoff between image quality, CPU use and file size. However, when you need to play back a lot of movies at once — particularly if they are high-res — the CPU load may exceed the limits of your processors. These situations are where highly optimized codecs (like Hap) are most useful. On the Mac you will need to be running 10.6.8 or later, on PC Vista or newer — you don't need a super-fast computer, but you do need a fast drive for playback (preferably an SSD). --quote end--- basically, high-datarate codec based on DXT compression + libsnappy. In theory ffmpeg should be able to encode it, if compiled with such library, I compiled system ffmpeg with this option: -- --enable-libsnappy but CinGG's copy of ffmpeg still compiles with default, no. On next rebuild I'll try this option. At least I can encode such file with ffmpeg -i ~/0005.avi -c:v hap -c:a copy /dev/shm/HAP.mov and result viewable in CinGG (but not OpenGL accelerated, iiuc) command line from https://gist.github.com/dlublin/e4585b872dd136ae88b2aa51a6a89aac ("Encoding to Hap from the command line using FFmpeg") But then I tried vc2 encoder, in both qt and mkv containers, and while CinGG compiled with ffmpeg git was able to open this file, it failed with both old ffplay and new (as in, compiled few days ago with recent ffmpeg) mpalyer :/ So, probably not very useful ... I also tried to switch various format options, but for both qt and mkv Cin was saying: no format named: mkv so, may be some mapping between Cin internal "formats" and ffmpeg still off.

1 0

OpenEXR encoding is not multithreaded?
by Andrew Randrianasulu 14 Mar '20

14 Mar '20

Hello again! I had this qestion about why I can't see OpenEXR as choise in 'background render' format chooser. Now I have answer.... I tried to composite 2 x 1920x1080 images (project format RGBA-float) Speed while just previewing was up to 5.5 fps (on full speed.) Now, rendering 10 seconds of such video took 7 min 17 sec when I choose OpenEXR, include alpha, compression pxr24. (into tmpfs, full speed usually more than 500Mb/s) Each file took around 2.4 Mb. Definitely not realtime. Of course, even perfect multithreading on 4-way machine like I have will not make it even closer to realtime - but I think it will make such output format still more useful. If frame-level multithreading in OpenEXR encoder as done by CinGG can be implemented relatively trivially - it will be great for such speed addict as me :} I mean, like creating pool of image buffers in encoder itself, with n = num_of_cpus, but not more than, say total_buf_size than 1/2 ram. Then call OpenEXR compressor on each buffer. Then wait until one buffer become ready, write it, load buffer with new image. Repeat untill all images are compressed. Of course there is question about ordering ..or not? If OpenEXR actually 'sequence' of images, like I choose - each file can be written independently, even? If image order somewhat important - equip each buffer with serial number, and then reuse timestamp info from core? Also, on question of GPU precision ... Extended-Precision Floating-Point Numbers for GPU Computation from Andrew Thall, Alma College Abstract addition " [Addendum (July 2009): the presence of IEEE compliant double-precision hardware in modern GPUs from NVidia and other manufacturers has reduced the need for these techniques. The double-precision capabilities can be accessed using CUDA or other GPGPU software, but are not (as of this writing) exposed in the graphics pipeline for use in Cg-based shader code. Shader writers or those still using a graphics API for their numerical computing may still ﬁnd the methods described herein to be of interest.]" " Testing accuracy and precision of hardware systems is problem- atic; for a survey see Cuyt et al [23]. The Paranoia system [24], developed by Kahan in the early 1980s, was the inspiration for GPU Paranoia by Hillesland and Lastra [25], a software system for characterizing the ﬂoating point behavior of GPU hardware. GPU Paranoia provides a test-suite estimating ﬂoating point arithmetic error in the basic function, as well as char- acterizing apparent number of guard digits and correctness of rounding modes. Recent GPU hardware has shown considerable improvement over earlier. For the purposes of extended-precision computation, 32-bit ﬂoats are required. For Nvidia GPUs, the 6800 series and above were the ﬁrst to have sufﬁcient precision and IEEE compliance for extended-precision numerical work; the 7800/7900/7950 series has better IEEE compliance, allowing all but the transcendental functions to be computed; for computa- tions involving Taylor series, rather than self-correcting Newton- Raphson iterations, the superior round-off behavior and guard- digits of the 8800 series are necessary." ---quote end--- paper: http://andrewthall.org/papers/df64_qf128.pdf But I guess if Natron is happy with OpenGL - then Cinelerra also can be ....

1 0

New libdav1d, ICC profile support in ffm[eg git
by Andrew Randrianasulu 13 Mar '20

13 Mar '20

Fresh news! https://www.phoronix.com/scan.php?page=news_item&px=Dav1d-0.6-AV1-Benchmarks ---quote--- But where things really got interesting for the Intel/AMD processors was the much faster 10-bit decoding of AV1 content with dav1d 0.6.0 for both Intel and AMD. Very significant gains in this case. ---quote end--- In ffmpeg we can see https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/05d27f342be28cf92f3c9470e70… API: add AV_PKT_DATA_ICC_PROFILE to AVPacketSideDataType and next few patches .... comment in avcodec.h says: ---quote-- + * ICC profile data consisting of an opaque octet buffer following the + * format described by ISO 15076-1. + */ + AV_PKT_DATA_ICC_PROFILE, --end of quote---- pdf itself is huge, but hopefully other libs already have something? http://www.color.org/icc_specs2.xalter v4 ICC Specification This version is technically identical to ISO 15076-1:2010, which is available from ISO. This is the most widely used version, first published in 2001. Specification ICC.1:2010-12 (Profile version 4.3.0.0) Image technology colour management - Architecture, profile format, and data structure http://www.color.org/specification/ICC1v43_2010-12.pdf Strange enough, but website littlecms.com doesn't work for me .... Anyway, hopefully no-one need to *print* films right now, so it all will be about monitors and files.. I may misunderstand something, but whole point of color management is to get same color on slightly different devices? So, if you work with Monitor A and you have color profile for your monitor, you can store this profile somewhere in image and now video file, and then on load supported player/editor will auto-correct things, relative to another (monitor B) output device, so you can work on colors across few monitors in different locations, say. I may misunderstand this, never feel special need for such fine-tuning of colors.

2 1