[Cin] Colour profiles in photo

Andrew Randrianasulu randrianasulu at gmail.com
Sun Aug 7 06:42:25 CEST 2022


сб, 6 авг. 2022 г., 16:16 Einar Rünkaru <einarrunkaru at gmail.com>:

>
>
> On 06/08/2022 07:41, Andrew Randrianasulu wrote:
> >
> >
> > пт, 5 авг. 2022 г., 20:05 Einar Rünkaru <einarrunkaru at gmail.com
> > <mailto:einarrunkaru at gmail.com>>:
> >
> >
> >
> >     On 05/08/2022 08:08, Andrew Randrianasulu wrote:
> >      >
> >      >
> >      > чт, 4 авг. 2022 г., 14:36 Andrew Randrianasulu
> >     <randrianasulu at gmail.com <mailto:randrianasulu at gmail.com>
> >      > <mailto:randrianasulu at gmail.com <mailto:randrianasulu at gmail.com
> >>>:
> >      >
> >      >
> >     https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html
> >     <https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html>
> >      >
> >       <
> https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html <
> https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html>>
> >      >
> >      >
> >      >     It seems not all icc profiles are the same ...
> >
> >     Conversion from one profile to another may be done different ways.
> >
> >
> > Well, I was amazed by existence of unbounded mode (where values can be
> > less than zero or more than 1.0) but I guess Cinelerra not ready for
> this )
>
> Values can overflow or underflow inside certanin conversion. The output
> of this conversion should be inside margins of this format.
>
>
> >
> >
> > Also, littecms pdf documentation in doc folder says you can use same
> > buffer for input and output as long as its organization remain the same
> ...
> >
> > ---
> > Scanline overlap
> >
> > It is safe to use same block for input and output, but only if the input
> > and output are coded
> > in same format. For example, you can safely use only one buffer for RGB
> > to RGB but you
> > cannot use same buffer for RGB as input and CMYK as output.
> >
> > ---
> >
> Of course when the size of pixel in bytes does not change. This is the
> most effective solution.
> >
> >
> >      >
> >      > I also was reading ninedegreesbelow.com
> >     <http://ninedegreesbelow.com> <http://ninedegreesbelow.com
> >     <http://ninedegreesbelow.com>>
> >      > articles on color spaces and it seems some of our trouble with
> blend
> >      > modes with text and fades caused by (missing?) linearization, see
> >      >
> >      >
> >
> https://ninedegreesbelow.com/photography/test-for-linear-processing.html
> >     <
> https://ninedegreesbelow.com/photography/test-for-linear-processing.html>
> >
> >      >
> >     <
> https://ninedegreesbelow.com/photography/test-for-linear-processing.html
> >     <
> https://ninedegreesbelow.com/photography/test-for-linear-processing.html>>
> >      >
> >      > I did some hack for normal blend mode using code from
> >     stackoverflow and
> >      > code posted in our bugzilla
> >      >
> >      > See
> >      > https://www.cinelerra-gg.org/bugtracker/view.php?id=559
> >     <https://www.cinelerra-gg.org/bugtracker/view.php?id=559>
> >      > <https://www.cinelerra-gg.org/bugtracker/view.php?id=559
> >     <https://www.cinelerra-gg.org/bugtracker/view.php?id=559>>
> >
> >     There are broken links - not very useful.
> >
> >
> >
> > Sorry, most likely gmail client on Android not very like copy pasted
> > links....
> >
> No, the links in the ticket did not open. Without these it was very hard
> to understand what the problem was
> >
> >     If I understand right, the problem is related to alpha. When you mix
> >     one
> >     frame with frame with shaped alpha, the second frame "cuts" itself
> into
> >     the first. The result may be unexpected.
> >      >
> >      > So, in theory this (fast) linearization step should be added to
> all
> >      > modes, or at image-reading stage only?
> >
> >     My idea is that video/image loading converts to internal format
> >     including linearization. What is mode?
> >
> >
> > If I look at right place native png reader outputs into rgb(a)8 or
> > rgb(a)16 ..
> >
> > int FilePNG::colormodel_supported(int colormodel)
> > {
> >          if( colormodel == BC_RGB888 || colormodel == BC_RGBA8888 )
> >                  return colormodel;
> >          if( colormodel == BC_RGB161616 && native_cmodel == BC_RGBA161616
> >                  return colormodel;
> >          if( native_cmodel >= 0 )
> >                  return native_cmodel;
> >          int use_16bit = BC_CModels::is_float(colormodel) ||
> >                   BC_CModels::calculate_max(colormodel) > 255 ? 1 : 0;
> >          return BC_CModels::has_alpha(colormodel) ?
> >                  (use_16bit ? BC_RGBA16161616 : BC_RGBA8888) :
> >                  (use_16bit ? BC_RGB161616 : BC_RGB888);
> > }
> >
> > No specific icc handling ...
>
> The icc handlig has to be done when the execution reaches this place.
> >
> > I guess ffmpeg png reader also was dropping icc profile info until very
> > recently ....
>
> Yes - this was ignored.
>
> >
> >      >
> >      > Also, good way to put lcms transform code in our rgb2rgb function
> >      > (somewhere in guicast? ..but in cingg some of this code
> >     python-generated
> >      > and I do not know python at all ..), just with additional
> parameters
> >      > like pointer to in and out profiles? If any of them null then
> >     just not
> >      > execute transform call ...
> >      >
> >     I don't know python too.
> >
> >
> >
> > I think I found point where new function can be inserted for display:
> >
> > vdevicex11
> >
> > In function
> > VDeviceX11::write_buffer(VFrame *output_channels, EDL *edl)
> >
> > // printf("VDeviceX11::write_buffer %d output_channels=%p\n", __LINE__,
> > output_channels);
> > // printf("VDeviceX11::write_buffer %d input color_model=%d output
> > color_model=%d\n",
> > // __LINE__, output_channels->get_color_model(),
> bitmap->get_color_model());
> >                  if( bitmap->hardware_scaling() ) {
> >
> > BC_CModels::transfer(bitmap->get_row_pointers(),
> > output_channels->get_rows(), 0, 0, 0,
> >                                  output_channels->get_y(),
> > output_channels->get_u(), output_channels->get_v(),
> >                                  0, 0, output_channels->get_w(),
> > output_channels->get_h(),
> >                                  0, 0, bitmap->get_w(), bitmap->get_h(),
> >                                  output_channels->get_color_model(),
> > bitmap->get_color_model(),
> >                                  -1, output_channels->get_w(),
> > bitmap->get_w());
> >                  }
> >                  else {
> >
> > BC_CModels::transfer(bitmap->get_row_pointers(),
> > output_channels->get_rows(), 0, 0, 0,
> >                                  output_channels->get_y(),
> > output_channels->get_u(), output_channels->get_v(),
> >                                  (int)output_x1, (int)output_y1,
> > (int)(output_x2 - output_x1), (int)(output_y2 - out
> >                                  0, 0, (int)(canvas_x2 - canvas_x1),
> > (int)(canvas_y2 - canvas_y1),
> >                                  output_channels->get_color_model(),
> > bitmap->get_color_model(),
> >                                  -1, output_channels->get_w(),
> > bitmap->get_w());
> >                  }
> >
> > So bitmap->get_row_pointers() can be used as buffer argument for cms*
> > functions?
>
> Icc profile should be added as a new parameter. You cant reuse
> get_row_pointers() for it.
>

Yes, I was talking about image buffer to pass to transform function ....




> The right place for adding icc profile is color conversion routines.
> Caller tell what profile should be used (no profile, some predefined or
> some custom profile).
>
> >
> > I ignore direct mode above for now ...
> >
> > For initial experiments even just hardcoded path to monitor profile
> > should be enough to see difference and experience speed lost?
> >
> > And for encoding this profile into media/file 'asset' structure must be
> > altered first to hold icc profile type from lcms2.h and then encoder
> > functions should look if there attached profile and pass it to
> > libacvodec/libavformat ...
>
> Asset should not hold the profile. Profile is inside the original file,
> in decoder parameters or in encoder parameters.
>

Ok ....

>
>
> >
> >      >
> >      >
> >      >     Input side hopefully already covered by ffmpeg.git patches
> (input
> >      >     image format icc profile only should matter at decompressing
> into
> >      >     some pixel array? Because further processing will alter those
> >     pixels
> >      >     ...or I am wrong and input media profiles must be somewhat
> >     combined
> >      >     during track  compositing?)
> >      >
> >
> >     You have to select the best internal format or you have to change and
> >     test 6 x N paths in every effect. N is in hundreds.
> >
> >
> >
> > But then is there any sense in making profile-based transfer functions
> > to be available for rest of cinelerra, like in cingg's case
> > guicast/bcxfer.C place? (Where BC_CModels::transfer currently defined )
> >
> Yes, as I said above.
>
> Einar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220807/94b3f977/attachment.htm>


More information about the Cin mailing list