<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 6 авг. 2022 г., 16:16 Einar Rünkaru <<a href="mailto:einarrunkaru@gmail.com">einarrunkaru@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 06/08/2022 07:41, Andrew Randrianasulu wrote:<br>
> <br>
> <br>
> пт, 5 авг. 2022 г., 20:05 Einar Rünkaru <<a href="mailto:einarrunkaru@gmail.com" target="_blank" rel="noreferrer">einarrunkaru@gmail.com</a> <br>
> <mailto:<a href="mailto:einarrunkaru@gmail.com" target="_blank" rel="noreferrer">einarrunkaru@gmail.com</a>>>:<br>
> <br>
> <br>
> <br>
> On 05/08/2022 08:08, Andrew Randrianasulu wrote:<br>
> ><br>
> ><br>
> > чт, 4 авг. 2022 г., 14:36 Andrew Randrianasulu<br>
> <<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a> <mailto:<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>><br>
> > <mailto:<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a> <mailto:<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>>>>:<br>
> ><br>
> ><br>
> <a href="https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html</a><br>
> <<a href="https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html</a>><br>
> > <br>
> <<a href="https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html</a> <<a href="https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html</a>>><br>
> ><br>
> ><br>
> > It seems not all icc profiles are the same ...<br>
> <br>
> Conversion from one profile to another may be done different ways.<br>
> <br>
> <br>
> Well, I was amazed by existence of unbounded mode (where values can be <br>
> less than zero or more than 1.0) but I guess Cinelerra not ready for this )<br>
<br>
Values can overflow or underflow inside certanin conversion. The output <br>
of this conversion should be inside margins of this format.<br>
<br>
<br>
> <br>
> <br>
> Also, littecms pdf documentation in doc folder says you can use same <br>
> buffer for input and output as long as its organization remain the same ...<br>
> <br>
> ---<br>
> Scanline overlap<br>
> <br>
> It is safe to use same block for input and output, but only if the input <br>
> and output are coded<br>
> in same format. For example, you can safely use only one buffer for RGB <br>
> to RGB but you<br>
> cannot use same buffer for RGB as input and CMYK as output.<br>
> <br>
> ---<br>
> <br>
Of course when the size of pixel in bytes does not change. This is the <br>
most effective solution.<br>
> <br>
> <br>
> ><br>
> > I also was reading <a href="http://ninedegreesbelow.com" rel="noreferrer noreferrer" target="_blank">ninedegreesbelow.com</a><br>
> <<a href="http://ninedegreesbelow.com" rel="noreferrer noreferrer" target="_blank">http://ninedegreesbelow.com</a>> <<a href="http://ninedegreesbelow.com" rel="noreferrer noreferrer" target="_blank">http://ninedegreesbelow.com</a><br>
> <<a href="http://ninedegreesbelow.com" rel="noreferrer noreferrer" target="_blank">http://ninedegreesbelow.com</a>>><br>
> > articles on color spaces and it seems some of our trouble with blend<br>
> > modes with text and fades caused by (missing?) linearization, see<br>
> ><br>
> ><br>
> <a href="https://ninedegreesbelow.com/photography/test-for-linear-processing.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/test-for-linear-processing.html</a><br>
> <<a href="https://ninedegreesbelow.com/photography/test-for-linear-processing.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/test-for-linear-processing.html</a>><br>
> <br>
> ><br>
> <<a href="https://ninedegreesbelow.com/photography/test-for-linear-processing.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/test-for-linear-processing.html</a><br>
> <<a href="https://ninedegreesbelow.com/photography/test-for-linear-processing.html" rel="noreferrer noreferrer" target="_blank">https://ninedegreesbelow.com/photography/test-for-linear-processing.html</a>>><br>
> ><br>
> > I did some hack for normal blend mode using code from<br>
> stackoverflow and<br>
> > code posted in our bugzilla<br>
> ><br>
> > See<br>
> > <a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=559" rel="noreferrer noreferrer" target="_blank">https://www.cinelerra-gg.org/bugtracker/view.php?id=559</a><br>
> <<a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=559" rel="noreferrer noreferrer" target="_blank">https://www.cinelerra-gg.org/bugtracker/view.php?id=559</a>><br>
> > <<a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=559" rel="noreferrer noreferrer" target="_blank">https://www.cinelerra-gg.org/bugtracker/view.php?id=559</a><br>
> <<a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=559" rel="noreferrer noreferrer" target="_blank">https://www.cinelerra-gg.org/bugtracker/view.php?id=559</a>>><br>
> <br>
> There are broken links - not very useful.<br>
> <br>
> <br>
> <br>
> Sorry, most likely gmail client on Android not very like copy pasted <br>
> links....<br>
> <br>
No, the links in the ticket did not open. Without these it was very hard <br>
to understand what the problem was<br>
> <br>
> If I understand right, the problem is related to alpha. When you mix<br>
> one<br>
> frame with frame with shaped alpha, the second frame "cuts" itself into<br>
> the first. The result may be unexpected.<br>
> ><br>
> > So, in theory this (fast) linearization step should be added to all<br>
> > modes, or at image-reading stage only?<br>
> <br>
> My idea is that video/image loading converts to internal format<br>
> including linearization. What is mode?<br>
> <br>
> <br>
> If I look at right place native png reader outputs into rgb(a)8 or <br>
> rgb(a)16 ..<br>
> <br>
> int FilePNG::colormodel_supported(int colormodel)<br>
> {<br>
> if( colormodel == BC_RGB888 || colormodel == BC_RGBA8888 )<br>
> return colormodel;<br>
> if( colormodel == BC_RGB161616 && native_cmodel == BC_RGBA161616<br>
> return colormodel;<br>
> if( native_cmodel >= 0 )<br>
> return native_cmodel;<br>
> int use_16bit = BC_CModels::is_float(colormodel) ||<br>
> BC_CModels::calculate_max(colormodel) > 255 ? 1 : 0;<br>
> return BC_CModels::has_alpha(colormodel) ?<br>
> (use_16bit ? BC_RGBA16161616 : BC_RGBA8888) :<br>
> (use_16bit ? BC_RGB161616 : BC_RGB888);<br>
> }<br>
> <br>
> No specific icc handling ...<br>
<br>
The icc handlig has to be done when the execution reaches this place.<br>
> <br>
> I guess ffmpeg png reader also was dropping icc profile info until very <br>
> recently ....<br>
<br>
Yes - this was ignored.<br>
<br>
> <br>
> ><br>
> > Also, good way to put lcms transform code in our rgb2rgb function<br>
> > (somewhere in guicast? ..but in cingg some of this code<br>
> python-generated<br>
> > and I do not know python at all ..), just with additional parameters<br>
> > like pointer to in and out profiles? If any of them null then<br>
> just not<br>
> > execute transform call ...<br>
> ><br>
> I don't know python too.<br>
> <br>
> <br>
> <br>
> I think I found point where new function can be inserted for display:<br>
> <br>
> vdevicex11<br>
> <br>
> In function<br>
> VDeviceX11::write_buffer(VFrame *output_channels, EDL *edl)<br>
> <br>
> // printf("VDeviceX11::write_buffer %d output_channels=%p\n", __LINE__, <br>
> output_channels);<br>
> // printf("VDeviceX11::write_buffer %d input color_model=%d output <br>
> color_model=%d\n",<br>
> // __LINE__, output_channels->get_color_model(), bitmap->get_color_model());<br>
> if( bitmap->hardware_scaling() ) {<br>
> <br>
> BC_CModels::transfer(bitmap->get_row_pointers(), <br>
> output_channels->get_rows(), 0, 0, 0,<br>
> output_channels->get_y(), <br>
> output_channels->get_u(), output_channels->get_v(),<br>
> 0, 0, output_channels->get_w(), <br>
> output_channels->get_h(),<br>
> 0, 0, bitmap->get_w(), bitmap->get_h(),<br>
> output_channels->get_color_model(), <br>
> bitmap->get_color_model(),<br>
> -1, output_channels->get_w(), <br>
> bitmap->get_w());<br>
> }<br>
> else {<br>
> <br>
> BC_CModels::transfer(bitmap->get_row_pointers(), <br>
> output_channels->get_rows(), 0, 0, 0,<br>
> output_channels->get_y(), <br>
> output_channels->get_u(), output_channels->get_v(),<br>
> (int)output_x1, (int)output_y1, <br>
> (int)(output_x2 - output_x1), (int)(output_y2 - out<br>
> 0, 0, (int)(canvas_x2 - canvas_x1), <br>
> (int)(canvas_y2 - canvas_y1),<br>
> output_channels->get_color_model(), <br>
> bitmap->get_color_model(),<br>
> -1, output_channels->get_w(), <br>
> bitmap->get_w());<br>
> }<br>
> <br>
> So bitmap->get_row_pointers() can be used as buffer argument for cms* <br>
> functions?<br>
<br>
Icc profile should be added as a new parameter. You cant reuse <br>
get_row_pointers() for it.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, I was talking about image buffer to pass to transform function ....</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The right place for adding icc profile is color conversion routines. <br>
Caller tell what profile should be used (no profile, some predefined or <br>
some custom profile).<br>
<br>
> <br>
> I ignore direct mode above for now ...<br>
> <br>
> For initial experiments even just hardcoded path to monitor profile <br>
> should be enough to see difference and experience speed lost?<br>
> <br>
> And for encoding this profile into media/file 'asset' structure must be <br>
> altered first to hold icc profile type from lcms2.h and then encoder <br>
> functions should look if there attached profile and pass it to <br>
> libacvodec/libavformat ...<br>
<br>
Asset should not hold the profile. Profile is inside the original file, <br>
in decoder parameters or in encoder parameters.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Ok ....</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> <br>
> ><br>
> ><br>
> > Input side hopefully already covered by ffmpeg.git patches (input<br>
> > image format icc profile only should matter at decompressing into<br>
> > some pixel array? Because further processing will alter those<br>
> pixels<br>
> > ...or I am wrong and input media profiles must be somewhat<br>
> combined<br>
> > during track compositing?)<br>
> ><br>
> <br>
> You have to select the best internal format or you have to change and<br>
> test 6 x N paths in every effect. N is in hundreds.<br>
> <br>
> <br>
> <br>
> But then is there any sense in making profile-based transfer functions <br>
> to be available for rest of cinelerra, like in cingg's case <br>
> guicast/bcxfer.C place? (Where BC_CModels::transfer currently defined )<br>
> <br>
Yes, as I said above.<br>
<br>
Einar<br>
</blockquote></div></div></div>