чт, 18 июл. 2024 г., 23:44 Andrea paz via Cin :
> > The CinGG-20230131-x86_64.AppImage name will remain the same, but just
> will now be the multibit version. The
> CinGG-20230131-x86_64-multibit.AppImage will no longer exist. I am not
> going to bother creating an 8-bit appimage as it just seem
Andrea, sorry for the confusion. See below.
2- Maybe I didn't understand correctly. Do you intend to rename all
> the 2023/24 appimages, removing the word multibit, and deleting the
> 8-bit ones? Will only the "older-distros" be left untouched? And the
> "i386" versions are all 8-bit? I will cha
> The CinGG-20230131-x86_64.AppImage name will remain the same, but just will
> now be the multibit version. The CinGG-20230131-x86_64-multibit.AppImage
> will no longer exist. I am not going to bother creating an 8-bit appimage as
> it just seems unnecessary. I will just leave
> CinGG-20230
Andrea, a few answers below. This just seems confusing, but we should have
done this initially when Andrew-R supplied the patch.
1- how to do if you want to compile the 8-bit version?
>
I would change the section "Multibit build for x265-8/10/12-bit" to note
how to compile the 8-bit only version.
I will change the manual.
A few questions:
1- how to do if you want to compile the 8-bit version?
2- Do the appimages reverse their names? multibit --> new std; old std
--> 8-bit?
3- Will the einhander repository continue to have only the std version
(which will be the multibit from now on)?
--
Ci
I looked at
https://opencolorio.readthedocs.io/en/latest/guides/developing/usage_examples.html
and well, few calls for basic colorspace transform in c++ is not very bad,
but of course even with this easy way I still not quite understand where we
(cinelerra's) should put this call? At (ffmpeg) dec
6 matches
Mail list logo
