Recent posts

#1
Hardware and Accessories / Re: can cables of different ca...
Last post by yolao - Today at 08:59:27 PM
Thanks Walter. I will try that.

My concern was if that it could be some kind of noise (sort of speak) in the battery current. The thinner cable is a cable for the dummy battery that i cut out and the thicker one is a cable that goes directly to a battery adapter plate that will use an NP-F battery.

What about the other option?... Connect the dummy cable, the thinner one, directly to the battery adapter plate with power connector?
#2
Remove solder. Straighten strands. Twist both cable strands together. If unable there are 2 options:
- Remove some strands from thicker one. Then twist.
- Isolate thinner cable longer. Use thicker cable as "core" for thinner cable.

#3
Hardware and Accessories / Re: can cables of different ca...
Last post by yolao - Today at 07:40:39 PM
Quote from: Walter Schulz on Today at 07:33:30 PMSorry, unclear description.

You need to insert both cable ends (4 wires) to terminal screws?

Those cables need to be connected together Walter, to conform a single cable. So my concern was if it was ok to connect them since there are of different caliber.
#4
Sorry, unclear description.

You need to insert both cable ends (4 wires) to terminal screws?
#5
Hardware and Accessories / can cables of different calibe...
Last post by yolao - Today at 07:11:53 PM
Hi

So i have two cables (the thinner one is the one that goes to the dummy battery and the thicker to the battery adapter plate). But my doubt is that as you can see they are different caliber. Is there a problem with that?



The other option could be to connect the thinner cable, the one that goes to the dummy battery, directly to the battery adapter plate with a power connector that goes to the 7.4v port.



Which option is better?

Thanks


#6
Cool, thanks Danne, I compiled your version and now frames are fine.

I was using gitHub-based davidmilligan/MLVFS repo whose final commit is 9f81918 [May 31, 2016], while thanks to your hint I realize now that there is a bitbucket-based dmilligan/mlvfs repo that has a few further merges from bouncyball, dfort and g3gg0 up to commit 222f87c [Jul 23, 2018]. Guess something was fixed / improved / implemented there regarding lossless compressed raw MLV files.

Thanks, will work on this!

EDIT: anyone can explain gitHub-based cedricp/MLVFS commits dated Jun - Jul 2022? His work seems to be based on commit 9f81918 [May 31, 2016].
#7
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by Danne - Today at 04:25:10 PM
I use MLVFS with fuse for arm64 mac M1 installed. Integrated in script based program 'Switch'.
Png support seems broken.
https://bitbucket.org/Dannephoto/mlvfs_minus_mlv/src/master/
#8
Quote from: reddeercity on April 22, 2024, 07:53:10 AMThe question I ask is, is this useful ? Or just a novelty say i can do xxfps

Hi. Yes, any 50/60 FPS mode will be useful even with 720p, because we can then upscale it using AI and sell on stocks.
I tried 48fps but it worked just a pair of times for me. So I often use regular RAW video with Dual ISO or crop_mod 5x 3.5K preset. Sometimes it even works with Dual ISO on low resolutions like about 1200 wide.

I'm using the latest experimental build I found here in topics, and it has an issue with DualISO - I have bad horizontal stripes pattern that ruins video quality in post. Also in the crop mode there is a slight patter like on a bath towel (little squares). For the latter I use AI to get rid of, but the Dual ISO bug is concerning.
Anyone else encountered this before?

With aggressive bad pixels fix it is clearly visible.




P.S. Lokks like image posting is not working, I'll leave screenshots URLs here:
https://prnt.sc/AYwQfZ1ls0_y
https://prnt.sc/-isFpfLHQvrg

#9
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by vastunghia - Yesterday at 11:46:04 PM
Never mind, I just realized that I should try cedricp's fork. Will test in the w/e. Mmh, nah. Don't think that's the point.
#10
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by vastunghia - Yesterday at 10:22:00 PM
Thanks n_a_h.

So at the end of the day it looks to me as this should be even much simpler than that. I already verified that, by just replacing

for (int i = 0; i < frame_count; i++)
   sprintf(filename, "%s_%06d.dng", mlv_basename, i);
   filler(buf, filename, NULL, 0);
}

with

for (int i = 0; i < frame_count; i = i+2)
{
   sprintf(filename, "%s_%06d.dng", mlv_basename, i/2);
   filler(buf, filename, NULL, 0);
}

in the mlvfs_readdir() function of main.c, I get half the frames in the directory. Then I think that the function get_mlv_frame_number(), that returns frame number from the filename, can be easily hacked too. And then there I will need to understand how to tweak reported fps.

However, I realized that even leaving the code untouched, the MLVFS I can compile produces corrupted DNG frames. The only changes I was forced to do are related to FUSE (basically OSXFUSE.framework having been rebranded to macFUSE.framework somewhere in the past 8 years and FUSE header path having been moved from /usr/local/include/osxfuse/fuse to /usr/local/include/fuse).

Any clue? Anybody could successfully build a working MLVFUSE recently?