MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

Started by ilia3101, July 08, 2017, 10:19:19 PM

Previous topic - Next topic

0 Members and 6 Guests are viewing this topic.

masc

@Ilia: strange... with clang in Qt it compiles... :-/
@bouncyball: I would draw the MainWindow like that: https://www.dropbox.com/s/elhz5plgy55qfwx/MainWindow.ui?dl=0
What do you think?

Edit: I found one thing: if vertical stripes is enabled, Highlight reconstruction does not work. And for the first clip opened, bad pixel does not work. If I switch to another clip, and switch back, all is fine. But those things we can debug later ;) It is a huge change!
5D3.113 | EOSM.202

bouncyball

@ilia3101: I will do pull request when we settle all issues/problems. It's a working draft which can be changed anytime especially when connection to GUI is implemented (it's not implemented right now).

@masc: I'm ok with any gui you offer and will appreciate your help on implementing it (will look at your .ui file later) I'm still learning QT basics :). Nice bug catching, as you mentioned changes are big.

I had to rewrite lot of my code to port this. There I used lots of static local variables in mlv_dump because it works only with one MLV at a time and this approach very convenient. Now in MLV App there can be any number of MLV object instances (I know, now, objects are freed every time when choosing another MLV but anyway) so it would not work here.

BTW I noticed very annoying and strange bug under linux when using MLV App. When resizing main window if no MLV is imported yet, window can be enlarged horizontally but can not be made smaller again ;). This issue disappears if MLV imported and window can be shrunk again. Have not tried this under windows though.

bb

Danne



ilia3101

Quote from: bouncyball on September 16, 2017, 07:21:55 AMBTW I noticed very annoying and strange bug under linux when using MLV App. When resizing main window if no MLV is imported yet, window can be enlarged horizontally but can not be made smaller again ;).
Also had this on Mac

Quote from: masc on September 15, 2017, 09:17:18 PMI found one thing: if vertical stripes is enabled, Highlight reconstruction does not work. And for the first clip opened, bad pixel does not work. If I switch to another clip, and switch back, all is fine. But those things we can debug later ;) It is a huge change!
These kind of things are normally silly bugs by me, I'll have a look what is causing it today(or maybe this one is deeper?).

@bouncyball what are the default settings in your module already doing? Is stripe correction on by default?

bouncyball

Quote from: Ilia3101 on September 16, 2017, 01:43:37 PM
@bouncyball what are the default settings in your module already doing? Is stripe correction on by default?

This is the 'llrawprocObject_t' struct:

typedef struct
{
    /* flags */
    int vertical_stripes; // fix vertical stripes, 0 - do not fix", 1 - fix, 2 - calculate for every frame
    int focus_pixels;     // fix focus pixels, 0 - do not fix, 1 - fix
    int fpi_method;       // focus pixel interpolation method: 0 - mlvfs, 1 - raw2dng
    int bad_pixels;       // fix bad pixels, 0 - do not fix, 1 - fix, 2 - makes algorithm aggresive to reveal more bad pixels
    int bpi_method;       // bad pixel interpolation method: 0 - mlvfs, 1 - raw2dng
    int chroma_smooth;    // chroma smooth, 2 - cs2x2, 3 - cs3x3, 5 - cs5x5
    int pattern_noise;    // fix pattern noise (0, 1)
    int deflicker_target; // deflicker value
    int first_time;       // controls some events which should occur only once per object instance
    int fpm_status;       // focus pixel map status: 0 = not loaded, 1 = loaded, 2 = not exist
    int bpm_status;       // bad pixel map status: 0 = not loaded, 1 = loaded, 2 = not exist, 3 = no bad pixels found
    int dual_iso;         // is RAW data dualiso or not (0, 1, for correctly prosessing of bad/focus pixels, can be removed if DISO block parsing is implemented)

    /* LUTs */
    int * raw2ev;
    int * ev2raw;

    /* pixel maps */
    pixel_map focus_pixel_map;
    pixel_map bad_pixel_map;

    /* stripe corrections */
    stripes_correction stripe_corrections;

    /* image buffer */
    uint16_t * raw_image_buff;
    size_t raw_image_size;

} llrawprocObject_t;


And the defaults are:

/* set defaults */
    llrawproc->vertical_stripes = 1; // enabled
    llrawproc->focus_pixels = 1; // enabled
    llrawproc->fpi_method = 1; // raw2dng interpolation method
    llrawproc->bad_pixels = 1; // enabled
    llrawproc->bpi_method = 1; // raw2dng interpolation method
    llrawproc->chroma_smooth = 0; // disabled
    llrawproc->pattern_noise = 0; // disabled
    llrawproc->deflicker_target = 0; // disabled

DeafEyeJedi

Thanks @bouncyball for yet bringing another life into this already remarkable app with so much potential. Will test out QTv0.7alpha and report my findings!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

masc

Quote from: bouncyball on September 16, 2017, 07:21:55 AM
I'm ok with any gui you offer and will appreciate your help on implementing it (will look at your .ui file later) I'm still learning QT basics :).
I help where I can! :) Or, just give me the interfaces and I'll do it - no problem ;)

Quote from: bouncyball on September 16, 2017, 07:21:55 AM
I had to rewrite lot of my code to port this. ...
Wow, good job. I see, it was even more work than I thought!

Quote from: bouncyball on September 16, 2017, 07:21:55 AM
BTW I noticed very annoying and strange bug under linux when using MLV App. When resizing main window if no MLV is imported yet, window can be enlarged horizontally but can not be made smaller again ;). This issue disappears if MLV imported and window can be shrunk again. Have not tried this under windows though.
Yes, my fault. I fixed that yesterday. See Ilias github. https://github.com/ilia3101/MLV-App/commit/76a727395e6f2c5bef4d559d76809806cb4046f8

Quote from: DeafEyeJedi on September 16, 2017, 07:31:18 PM
Will test out QTv0.7alpha and report my findings!
Thx! Perfect! :)
5D3.113 | EOSM.202

ilia3101

I'm going to work on getting bouncyball's work implemented in the Cocoa GUI. @masc what do you think of having tabs on the right panel, one for the raw level processing by bouncyball, one for the standard raw adjustments we already have, and in the future, a final tweaks tab with more colour adjustment type things.

@bouncyball I see you have to set internal properties on the llrawprocObject (raw_image_buff and raw_image_size), I know maybe it wouldn't be how you want it, but what do you think of making it an option to do something like applyLLRawProcObject() but with extra arguments for the image buffer and image size, as I think in the future(when cache is fixed), there will be a few threads caching separate frames at the same time, so the object having it's one image buffer internally could be an issue.

Something approximately like: applyLLRawProcObjectToBuffer(mlvObject, buffer, size) ?

masc

@Ilia: this is exactly what I thought too. You have Qt not installed, so you could not see my .ui I uploaded some posts above. Here how it looks:



Process is what we had before (but without the profile combobox), Correct is the RAW correction, and Profile is the profile combobox + LUT (maybe we want support that in the future? Would be cool to import .cube files).
5D3.113 | EOSM.202

bouncyball

Hey guys!

I've fixed severe bug caused by overwritten black and white levels right after opening and reading MLV headers in openMlvClip routine. Bayered raw data processing requires original values from MLV. Look at my commits here.

Here is a console output example when everything is set to ON:

Per-frame exposure compensation: 'ON'
Deflicker target: '3072'

Fixing pattern noise...

Using focus pixel map: '80000326_1808x726.fpm'
37440 pixels loaded

Searching for bad pixel types:
HOT  - p = 2271, dark_min = 1949, dark_max = 2141
COLD - p = 1943, dark_min = 1949, dark_max = 2141
COLD - p = 1938, dark_min = 1949, dark_max = 2141
HOT  - p = 2147, dark_min = 1949, dark_max = 2141
HOT  - p = 2207, dark_min = 1949, dark_max = 2141
HOT  - p = 2148, dark_min = 1949, dark_max = 2141
COLD - p = 1948, dark_min = 1949, dark_max = 2141
HOT  - p = 2154, dark_min = 1949, dark_max = 2141
HOT  - p = 2151, dark_min = 1949, dark_max = 2141
HOT  - p = 2145, dark_min = 1949, dark_max = 2141
COLD - p = 1931, dark_min = 1949, dark_max = 2141
COLD - p = 1915, dark_min = 1949, dark_max = 2141
HOT  - p = 2167, dark_min = 1949, dark_max = 2141
COLD - p = 1925, dark_min = 1949, dark_max = 2141
HOT  - p = 2195, dark_min = 1949, dark_max = 2141
HOT  - p = 2790, dark_min = 1949, dark_max = 2141
COLD - p = 1946, dark_min = 1949, dark_max = 2141
HOT  - p = 2156, dark_min = 1949, dark_max = 2141
COLD - p = 1888, dark_min = 1949, dark_max = 2141
COLD - p = 1938, dark_min = 1949, dark_max = 2141
HOT  - p = 2315, dark_min = 1949, dark_max = 2141
COLD - p = 1943, dark_min = 1949, dark_max = 2141
COLD - p = 1947, dark_min = 1949, dark_max = 2141
COLD - p = 1941, dark_min = 1949, dark_max = 2141
HOT  - p = 2157, dark_min = 1949, dark_max = 2141
HOT  - p = 2226, dark_min = 1949, dark_max = 2141
HOT  - p = 2207, dark_min = 1949, dark_max = 2141

Using bad pixel revealing method: 'NORMAL'
27 bad pixels found (crop: 152, 132)

Using chroma smooth method: '2x2'

Vertical stripes correction: 'UNNEEDED'
  1.00000  1.00000  1.00035  1.00047  0.99953  0.99930  0.99995  0.99875


@masc: I loved your .ui file! Tabbed version is very good! :). Still tracking bug which causes not fixing bad pixels on first load.

HERE is a zip file with 3 MLVs for testing (EOSM, 100D and 700D ones, thanx to Danne and dfort) and focus pixel maps which should be placed in the same dir with MLV App binary.

regards
bb

bouncyball

Quote from: Ilia3101 on September 17, 2017, 10:03:29 AM
I see you have to set internal properties on the llrawprocObject (raw_image_buff and raw_image_size), I know maybe it wouldn't be how you want it, but what do you think of making it an option to do something like applyLLRawProcObject() but with extra arguments for the image buffer and image size, as I think in the future(when cache is fixed), there will be a few threads caching separate frames at the same time, so the object having it's one image buffer internally could be an issue.

Something approximately like: applyLLRawProcObjectToBuffer(mlvObject, buffer, size) ?
Technically there is no problem with passing extra parameters at all. However I thought llrawproc object should be separate for each mlvObject instance in the future with all it's unique parameters. For example raw2ev and ev2raw LUTs are calculated every time for every MLV because of the black level and bit depth, also stripe corrections array and bad/focus pixel map arrays are specific to particular mlvObject. We should discuss this on github I guess.

In contrary, if I understand it correctly, ProsessingObject allocated once and its values are refreshing according to recipe every time we switch the mlv, am I right?

EDIT: Right. Now I understand what you mean by saying "there will be a few threads caching separate frames at the same time, so the object having it's one image buffer internally could be an issue". Will see what can I do about it.

bb

bouncyball

@DeafEyeJedi

Quote from: DeafEyeJedi on September 16, 2017, 07:31:18 PM
Thanks @bouncyball for yet bringing another life into this already remarkable app with so much potential. Will test out QTv0.7alpha and report my findings!
It's nice to see you still watching and testing things like in a good old times :D

regards
bb

ilia3101

@bouncyball Ah, the overwritten black level, I'm sorry that was there, if you want, you can remove it and keep the original levels, and remove the whole 16 bit conversion bitshift, and simply pass the original 10/12/14 bit values to the processingObject, as it should be competely fine if you give it the right black and white levels that match the smaller range.

Yes I agree with having a unique object for every clip, I just meant that I want to pass the image data directly to the 'apply' function, so that it can be used from many threads (on the same clip of course).

@deafeyejedi :)

@masc that looks pretty much like what I imagined! Although I don't think it's worth having a separate profile tab yet, as the customisability isn't that interestingly yet, I think it would be fine to keep it in the processing tab for now.
Cube luts are definitely something I want to add, just don't know how they work yet, although I think the LUT tool would go in with the final adjustments section.

bouncyball

Quote from: Ilia3101 on September 17, 2017, 05:28:57 PM
you can remove it and keep the original levels, and remove the whole 16 bit conversion bitshift, and simply pass the original 10/12/14 bit values to the processingObject, as it should be competely fine if you give it the right black and white levels that match the smaller range.
Hmm... did you try this and it worked well? Why we need to convert data to 16 bits if debayering and processing code does not really need this? Did you have something different on your mind doing this? Or was it just for simplicity to not handle all 10/12/14 bit black correction separately?

Quote from: Ilia3101 on September 17, 2017, 05:28:57 PM
@masc that looks pretty much like what I imagined! Although I don't think it's worth having a separate profile tab yet, as the customisability isn't that interestingly yet, I think it would be fine to keep it in the processing tab for now.
Well guys, if you liked changes (and I can confirm that ~98% of it working correctly ;) ) then maybe I will do pull request before we start integrating it with GUI?

bb

masc

Quote from: Ilia3101 on September 17, 2017, 05:28:57 PM
@masc that looks pretty much like what I imagined! Although I don't think it's worth having a separate profile tab yet, as the customisability isn't that interestingly yet, I think it would be fine to keep it in the processing tab for now.
Cube luts are definitely something I want to add, just don't know how they work yet, although I think the LUT tool would go in with the final adjustments section.
Cool. Yes, I also would like to have the profiles in the process tab for now. But because of the tab bar it was one element to high to work at 1280x800 with dock. So I was thinking about a 3rd tab... What we also could do: adding a scrolling area (instead or inside the tabs) Adobe Lightroom-like.

Quote from: bouncyball on September 17, 2017, 07:25:06 PM
Well guys, if you liked changes (and I can confirm that ~98% of it working correctly ;) ) then maybe I will do pull request before we start integrating it with GUI?
The GUI is often the nice part. But I think the GUI should be the last thing to do. The non-Qt part of the app - all the processing stuff - is the most important and should work as good as possible before! This also makes implementing a nice GUI very easy ;)
5D3.113 | EOSM.202

ilia3101

@bouncyball originally this program was a single .c file(pre-gui), and mostly hard coded, so yeah, I originally did that just for simplicity ( I wasn't even reading mlv headers properly), but now it should be fine without that, I tried it recently, but I only tested briefly with 14 bit files, not 100% sure how AMaZE demosaic would react to a <1023 value range, as it already crushes the blacks a little too much (compare it with the bilinear some time), but most likely will be completely fine.

EDIT: Oh yeah, the black level correction relies on black level being in 14 bit world, maybe do something with pow? (for short code, efficiency doesn't matter there anyway)

And yeah, you can pull request as it seems to work without any changes to the GUI required. And I like it 8)

bouncyball

Quote from: masc on September 17, 2017, 07:54:44 PM
What we also could do: adding a scrolling area (instead or inside the tabs) Adobe Lightroom-like.
I've been also thinking about it. Scrolling area instead of tab.

Quote from: Ilia3101 on September 17, 2017, 08:41:16 PM
I tried it recently, but I only tested briefly with 14 bit files, not 100% sure how AMaZE demosaic would react to a <1023 value range, as it already crushes the blacks a little too much (compare it with the bilinear some time), but most likely will be completely fine.
Unfortunatelly with 10/12 bits just deleting black level correction code not working, e.g. all debayered image is light gray. For 14 bits it's working as expected. That is why, as a workaround, I introduced 2 variables in llrawprocObject to back up black/white levels right before altering them in openMlvClip.

And... I made PR :D

regards
bb

DeafEyeJedi

Quote from: masc on September 17, 2017, 07:54:44 PM
Cool. Yes, I also would like to have the profiles in the process tab for now. But because of the tab bar it was one element to high to work at 1280x800 with dock. So I was thinking about a 3rd tab... What we also could do: adding a scrolling area (instead or inside the tabs) Adobe Lightroom-like.

+1

Quote from: masc on September 17, 2017, 07:54:44 PM
The GUI is often the nice part. But I think the GUI should be the last thing to do. The non-Qt part of the app - all the processing stuff - is the most important and should work as good as possible before! This also makes implementing a nice GUI very easy ;)

Agreed.

Quote from: bouncyball on September 18, 2017, 11:18:38 AM
And... I made PR :D

regards
bb

Thanks for this!  :)

Anyway here's my brief test run on MLV App v0.7 alpha. To be honest I was rather more anxious and tempted for BB's work to be implemented in the near future. Especially with mlv_dump on steroids. Just imagine being able to spit out Dual-ISO stuff directly from this app? Still this is all exciting stuff regardless.

So far it seems to work as advertised even though it's still in alpha stages. I noticed my Mac didn't like having FCPX running in the background while running this app. It does this random quick restart. No big deal since that's just me pushing the limits of my mid-2012 MBP 15" (OS X 10.12.6, 2.6 i7, 16GB Ram, 500GB + 1TB SSD w NVIDIA GeForce GT 650M 124 MB/ Intel HD Graphics 4000 1536 MB) which is not too shabby for ML stuff, right? Ha.

Anyway off to my findings:

1) I was pleased to see that it can open 12-bit lossless files with ease even FRSP Timelapse MLV's with the exception of spanning files. I noticed the app doesn't seem to pick up from the end of MLV to the next spanning files (.M00, .M01, .M02, etc) so therefore the footage just cuts in short from the original large MLV files w the spanning. Perhaps this was to be expected since it's still in alpha mode. Though it would be important to include this fix asap.  :P

2) I was also pleased with how the Audio files look when viewing the player from underneath. Makes it feel like a classic MLRawViewer from the future. Will have to test this more thoroughly in terms of length of the audio file matching the length of video file. Will get more into this later.

3) I was bummed to see that I couldn't copy and paste the preferred settings from one file to ALL files at once. Seems the app only allows you to copy and paste one file at a time. Maybe this is intended for now until we progress further. Would be nice to be able to paste the entire batch at once w ease.

4) I actually enjoy using the 100% viewer option (even during playback) which is handy for focus checking especially with 3.5-4K footage. Maybe in the future we can add 200%-400% zoom in as options?

5) Maybe this is to be expected but regardless of how nice it is to be able to batch export ProRes into an output folder since it is still spitting out png files (not that big of a deal but seems unnecessary) however it does delete them automatically once the ProRes is rendered. So not complaining about disk space in here but rather than work amount being involved? Is it required to do the png route in order to spit out ProRes? Hopefully once we get the AVFoundation installed within the app then we will be able to spit out 4444XQ especially with logs.

According to my eyes -- it seems when shooting clouds up in the sky and spitting out logs in 4444 comparing them to 4444XQ you will see more gradient pattern effects on the 4444 as oppose to smoother look of 4444XQ. Correct me on this @reddeercity if you can.

6) I also like how when you select ColorSpace to a certain Log (most of the sliders become disabled not allowing you to affect the footage as expected) w the exception to Exposure, Temp and Tint which is plus. Is this a safety feature intended for rookies? Bold decision.

More to come later. Will upload a quick screen recording of my findings when I can. Thanks to everyone on board in getting this revamped up!  8)
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

ilia3101

@masc Sorry for ignoring the post above, yeah I think eventually we might have to add a scroll area once more capability is added to processing, such as highlight reconstruction. Although it would be sad to add it now, as it would only be a small annoying amount of scrolling. Do you think there's any chance of compressing the sliders and labels a little more? Or is Qt layout at it's limit.
Also the tint slider in Qt GUI still seems to go wrong(image is blue) when fully to the green side, could you copy the Cocoa app's mehtod for doing it?:
-(void)tintSliderMethod
{
    double tintSliderValue = [self doubleValue] - 0.5;
    /* Control should be more fine when its closer to zero... */
    double tintValue = tintSliderValue;
    if (tintValue < 0) tintValue = -tintValue;
    tintValue = pow(tintValue, 1.7) * 20.0;
    if (tintSliderValue < 0) tintValue = -tintValue;
    processingSetWhiteBalanceTint(App->processingSettings, tintValue);
    [App->tintValueLabel setStringValue: [NSString stringWithFormat:@"%6.3f", ([self doubleValue] - 0.5) * 2 ]];
}

I think it produces a good range and correct feel. (of course adapt for Qt's integer slider)
Also, important: can you add the "cHRM Chunk" to libpng files? From this documentation: http://www.libpng.org/pub/png/book/chapter10.html
Might begin filling it with values once actual gamut/space options are added(and hopefully ffmpeg won't ignore that info).

@bouncyball We begin the pull request process! whatever that means :D Will look on github
I will have a go at making bitdepth work in its native value range later, once pull request is merged.

@deafeyejedi Thanks for the testing and feedback!
Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
6) I also like how when you select ColorSpace to a certain Log (most of the sliders become disabled not allowing you to affect the footage as expected) w the exception to Exposure, Temp and Tint which is plus. Is this a safety feature intended for rookies? Bold decision.
I thought that might be better for accuracy of the profiles, although I haven't got colour spaces fully implemented so I can't talk too much ;)
It's about time to nag andy600 with questions if he has time to answer :)... does anyone know where to do that? (haven't managed to make it look right with camera specific matrices yet, but get most of the math now)
Also AVFoundation slowly coming along, will make it as a library so Qt App can implement it too, I hear ffmpeg has flaws in its prores encoding in terms of colour(according to reddeercity), or is limited in colour space, dunno, maybe what I asked masc about may help fix it.

masc

Thank you DeafEyeJedi!

Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
I noticed my Mac didn't like having FCPX running in the background while running this app. It does this random quick restart.

What exactly do you mean with that? Does the App crash when working with FPCX?

Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
1) I noticed the app doesn't seem to pick up from the end of MLV to the next spanning files (.M00, .M01, .M02, etc)

Yes, this is still not implemented. We should do it soon.

Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
2)Will have to test this more thoroughly in terms of length of the audio file matching the length of video file.

That would be interesting, but I expect it will not fit after a longer playback time. But when stopping and restarting anywhere in the clip it should fit again.

Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
3) I was bummed to see that I couldn't copy and paste the preferred settings from one file to ALL files at once. Seems the app only allows you to copy and paste one file at a time. Maybe this is intended for now until we progress further. Would be nice to be able to paste the entire batch at once w ease.

That is a good idea. How would you do it? Selecting the files in the left and then paste?

Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
4) Maybe in the future we can add 200%-400% zoom in as options?

That should not be too complicated.

Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
5) Maybe this is to be expected but regardless of how nice it is to be able to batch export ProRes into an output folder since it is still spitting out png files (not that big of a deal but seems unnecessary) however it does delete them automatically once the ProRes is rendered. So not complaining about disk space in here but rather than work amount being involved? Is it required to do the png route in order to spit out ProRes?

Yes, it is necessary, because the mov is built from the pngs. After that the pngs are not needed anymore and are deleted. What I could do - making it like Ilia does in the cocoa app: making the pngs invisible.

Quote from: DeafEyeJedi on September 18, 2017, 07:57:49 PM
Hopefully once we get the AVFoundation installed within the app...

+1

Quote from: Ilia3101 on September 18, 2017, 08:10:12 PM
@masc Sorry for ignoring the post above, yeah I think eventually we might have to add a scroll area once more capability is added to processing, such as highlight reconstruction. Although it would be sad to add it now, as it would only be a small annoying amount of scrolling. Do you think there's any chance of compressing the sliders and labels a little more? Or is Qt layout at it's limit.

I tried to compress it a bit and I think it could work. Waiting for the pull request and then I'll add it.

Quote from: Ilia3101 on September 18, 2017, 08:10:12 PM
Also the tint slider in Qt GUI still seems to go wrong(image is blue) when fully to the green side, could you copy the Cocoa app's mehtod for doing it?

I'll look deeper into that. I also recognized that in the past.

Quote from: Ilia3101 on September 18, 2017, 08:10:12 PM
Also, important: can you add the "cHRM Chunk" to libpng files? From this documentation: http://www.libpng.org/pub/png/book/chapter10.html
Might begin filling it with values once actual gamut/space options are added(and hopefully ffmpeg won't ignore that info).

Yes, I wanted to do that. Thx for the reminder...

I now add all this points to the issue tracker that we don't forget that. At least for my head this is too much input  ;D
5D3.113 | EOSM.202

escho

Since imageio doesn´t exist anymore in the src-folder, these lines are no longer needed in MLVApp.pro, I guess.

Lines 92, 93
../../src/imageio/structs/imagestruct.h \
../../src/imageio/imageio.h \


Line 136
../../src/imageio/README.md \
https://sternenkarten.com/
600D, 6D, openSUSE Tumbleweed

masc

Quote from: escho on September 20, 2017, 11:26:14 PM
Since imageio doesn´t exist anymore in the src-folder, these lines are no longer needed in MLVApp.pro, I guess.
Right. I changed it. Thank you!
5D3.113 | EOSM.202

bouncyball

Hey!

@Ilia3101: I pushed the commit you asked - removed pointers to raw image buffer from the struct and passed as parameters of apply function. You are right, it's not only convenient, like this it's more elegant too :).

@masc: pushed commit with the fix of the issue we experienced. Now all is working ( hopefully ;) ). And thank you for implementing raw fixes GUI tab. Works great! Just one comment: default values in the source code and in the GUI (Correct tab) are not synced. Can you fix this?

defaults are:

Focus dots ON int 1
Bad pixels ON int 1
Chroma smooth OFF
Pattern noise OFF
Vertical stripes ON
Deflicker target 0


regards
bb

ilia3101

Thanks bouncyball
I can begin implementing a multithreaded cache that works :D