<div dir="ltr"><div>Hi Jérôme.<br></div><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 28, 2015 at 6:39 PM, Jérôme Laheurte <span dir="ltr"><<a href="mailto:jerome-bugzilla@jeromelaheurte.net" target="_blank">jerome-bugzilla@jeromelaheurte.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Unless something has drastically changed since the last time I wrote Orc code, that is not possible; source and destination pointers are incremented by the « register » size, which must be a power of 2 up to eight, I think; three is out of the question.<br></blockquote><div><br></div><div>So operating on an array of 3 bytes per pixels such as the RGB/BGR layout with the byte array layout RGBRGBRGB... is really difficult or near impossible?<br><br></div><div>And if that is the case, if one wants to use orc, the array needs to be conerted into something like RGB.RGB.RGB. etc. with an extra byte? And such a conversion can't really be done much faster than with a loop like this<br><br><div style="margin-left:40px">for (int i=0 ; i < N ; i++) {<br>  *dst++ = *src++;<br>  *dst++ = *src++;<br>  *dst++ = *src++;<br>  *dst++ = 255;<br>};<br></div><br></div><div>which to begin with was what I wanted orc to substitute using SIMDs commands.<br><br></div><div>Is that more or less the conclusion?<br><br></div><div>Best regards<br></div><div>Peter MM<br></div></div></div></div>