Add upside down mode

[masc4ii]

In this commit https://github.com/ilia3101/MLV-App/commit/c929ed52c5110feb4e195d1f53c68b06bccc840b I added an upside down mode, which turns the picture by 180°. That is useful, when I film with my steady in reverse (camera is hanging then and can go very close to the floor).

I realized it by Qt viewer transformation and ffmpeg flip filter.

Negative:

• Waveform is not mirrored
• Parade is not correct
• MLV, cDNG and AVFoundation output is not affected

What could we do: Turning an image is easy to do... can we add that deeper in the lib, so all functionality can use that?

[masc4ii]

For now I added a checkbox to "Aspect Ratio" groupbox.

Should we rename the groupbox now to "Transformation" or "Geometry" or ... Aspect Ratio may not be the best name for that now... what do you think?

[bouncyball-git]

Hehe nice feature and interesting to implement this deeper. I'm gonna play with raw flip then as a llrawproc additional feature ;) Or may be just when importing MLV? Then all histo/waveform will be correct.

[bouncyball-git]

I guess it is better to implement as llrawproc feature because of focus pixel correction etc have to be done before flip.

Or... the best place to do this after debayer I think.

[masc4ii]

Okay... so we would add the checkbox (or On/Off buttons) there - would be nice & okay! Hm, would be cool to have also the preview picture turned, when opening a masxml.

[masc4ii]

In camera there is a acc sensor for portrait/landscape. Can this also be used for that? Or is its value identical for 0 and 180°? Is this value stored in MLV? mlv_elvl_hdr_t->pitch/roll?

[bouncyball-git]

Now I'm sure the fastest place to flip the image will be after debayer loops where 16bit RGB array is built, but unfortunately this is done in several places and debayer method also 2 so we have to change the code a lot. Inserting buffer reverse code into getMlvRawFrameDebayered() is the universal approach but when I did this reverse code slowed the playback quite a bit. There is a need to reverse 48bit words of the whole buffer. I need to see how you did this. It's fast!

[bouncyball-git]

Ah... now I understand you did the viewer part with Qt filter and the export part with ffmpeg filter.

[bouncyball-git]

Put this code to the end of getMlvRawFrameDebayered() function in video_mlv.c and try it please. This works everywhere including histogram, export etc but it slows things down:

int half_pixels = width * height / 2;
uint8_t rgb_pixel[6];
uint8_t * rgb_buf = (uint8_t*)outputFrame;
for(int i = 0; i < half_pixels; ++i)
{
     memcpy(rgb_pixel, rgb_buf + i*6, 6);
     memcpy(rgb_buf + i*6, rgb_buf + frame_size - 6 - i*6, 6);
     memcpy(rgb_buf + frame_size - 6 - i*6, rgb_pixel, 6);
 }

[bouncyball-git]

If the RGB pixel were 64bit (RGBA for example) we could optimize the code with fast XOR for example but pixel data is 48bits packed in the buffer :(

Code would be:

uint64_t * array = RGBA_Buffer
for(i = 0; i < half pixels; ++i)
{
    array[ i ] ^= array[ max_pixels - i ];
    array[ max_pixels - i ] ^= array[ max_pixels - i ];
    array[ i ] ^= array[ max_pixels - i ];
}

[masc4ii]

On my dualcore macs the speed is okay with your code (I only see a very tiny difference in fps). But this loss of speed would only be there, if the option is checked. Let's pack this functionality in a function which is called there and all is fine... what do you think?

[bouncyball-git]

Yes why not.

[masc4ii]

Would that also work for DNG and MLV export?

[masc4ii]

GUI is prepared for llrawproc function! Checkbox is exchanged to toolbuttons!

[masc4ii]

Öhm... when thinking about where you said to insert the code... llrawproc is not the right place to insert that?! Would it more be a "normal" processing function? In the end of getMlvRawFrameDebayered is the same as in the beginning of applyProcessingObject. What do you say, where is it better to implement? Would like to have it working also in DNG and MLV export.

[bouncyball-git]

Right, I'm sorry I wanted to tell you about it. This is not and won't be the llrawproc feature.

Also IMHO there is no need to flip raw data for DNGs or MLV. This must be the task for post processing software.

I think previously you really inserted it in the right place, into apect ratio part to be renamed to geometry or something.

I will supply you with the modified

getMlvRawFrameDebayered() getMlvRawFrameDebayered8()

functions with additional parameter 'int flip_mode' OK?

[bouncyball-git]

May be "Transformation" will be more appropriate name.

[masc4ii]

But if it is also for us a "normal" processing feature, wouldn't it be better in the beginning of applyProcessingObject()? Yesterday evening I had tried it out there and for what I tested it worked nicely too... Where is getMlvRawFrameDebayered8() used?

[bouncyball-git]

Ahh sory again I meant

getMlvProcessedFrame16 getMlvProcessedFrame8

functions

[bouncyball-git]

Which you are using intensively every whrere :) for every purpose

[bouncyball-git]

You set this parameter and get fliped or not flipped buffer. That's it. And can use it with histogrm, waveform, export, whatever...

[bouncyball-git]

Done, works :)

All calls of 'getMlvProcessedFrame16' and 'getMlvProcessedFrame8' from mainwindow.cpp are hardcoded to TR_VFLIP mode for now and everything is flipped upside down ;)

Just remove (sorry about your time) controls from llrawproc part and voila make use of the last parameter of those functions.

[masc4ii]

Cool, thx! But "VFLIP" & "HFLIP" - the naming is not correct. I thought flip means mirror. So turning 180° means VFLIP&HFLIP... 😄

[bouncyball-git]

Yeah you are right! :)

TR_ROT180?

[masc4ii]

Yes. But leave it... I'll change the whole interface a bit 😄

[bouncyball-git]

I changed it ;)

[masc4ii]

Okay, changed the interface. Like that it should also work out of the box in the cocoa version.

[bouncyball-git]

Nice rework :)

It nicely affects waveform and parade, but should vectorscope also be affected? It is changing.

[masc4ii]

Oh right... strange. But I think this has to do with that: I do not analyse the full image - only "some" (every 4th column and every 4th row) pixels for speed reasons. And when turning, the read pixels are changing. If you test with AMaZE, the effect is smaller.

[masc4ii]

Yes... change this and it stays the same (but is sooooo slow):

//Calc VectorScope
QImage VectorScope::getVectorScopeFromRaw(uint8_t *m_pRawImage, uint16_t width, uint16_t height)
{
    m_pScope->fill( Qt::black );

    //ScopeCloud, each 4th row & column for speed reasons
    for( int x = 0; x < width; x += 1 )
    {
        for( int y = 0; y < height; y += 1 )
        {

[bouncyball-git]

OK :)

[masc4ii]

Thanks @bouncyball-git for your help. I am happy with it as it is for now! -> Close.