Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - romainmenke

Pages: [1] 2
General Chat / Re: Apertus Axiom Beta
« on: September 28, 2014, 02:48:30 AM »
donated! and shared, read about it when it was in alpha, hope you guys have fun with it!

Is there something that needs testing or can be done with a 5D2? I've been following the iso-research and srm memory threads, but would be happy to help with anything that needs some love. Read the "how to report bugs" thread and "tips for helping dev's", so I'm good to go.

that would be awesome.  I do not know how to compile mo file but would love to try full res silence on my 5d2.  thank you

I don't think that was the point ;)

A bug is anything that it shouldn't be.
Spelling mistakes are bugs (which is also a good way for non-programmers to get into "programming" and bug squashing; create a fork, fix the typo, push back to the main repo, congrats your first bug fix and first addition to the code base).
Anything that doesn't work like it's meant to (from modules to button presses).
Anything that doesn't work on your camera (it may work on one camera but not on another).

In addition, when filing a bug report, there are priority settings, so if you find something and think "well that's not really a problem" but it is a "bug" then you can tag it as a minor bug.

I know what the concept of a bug is, but finding bugs in ML is not always that easy.
There are typo's and obvious bugs when something is broken beyond use.
Smaller glitches can be hard to spot because I have no idea what the software is supposed to be like without the glitch. Not all bugs are visible in the UI and they often only happen once because you did a number of steps in a precise order.

I also don't think there is need for a new way of bug reporting. When something is really broken the users will be quick to report it.

However when going to a new stable release all the tiny little glitches need to be found too. These things get ignored by users because everything still works and well we are users ;)

I've been thinking for some time now, of providing a build sharing service, where I compile some stuff, and users can test it.

All the fun toys from the branches for instance, and any other stuff that is being developed, but not pushed to the nightly builds.

I think there are some users who for whatever reason, cannot compile, however, they would still be able to provide useful feedback to the development process.  This would be a way for users who cannot develop, to help.  Like a bug finding process by users.

Guess now is the time.  I'll look at setting things up tomorrow.

Exactly what I had in mind. A place where users like me can easily find a way to help. This might also help to keep some threads more focussed on actual dev work without too many questions about timeframes, next stable releases, how to compile,...

I think a lot of users like me want to help but just don't know where or how to start. Maybe it should also be very defined in what it is that needs to be done. If it is just a place where compiled stuff can be tested freely, it will become a new nightly (lot's of users using and asking when it will make it into the next stable)

About bug reports:
I have a background in html,  css, objective-c, javascript,... But those are also more a hobby to me. So the main reason why I have never reported a bug in the last 2 years using nightly builds is because I have no way of knowing what a bug is, or I never encountered one. (I don't push every button and try every setting)

Maybe it would be helpful (but very time consuming) to create guidelines for users on what bugs are. Not just the obvious bugs where something does nothing, but also small UI bugs,.... I also have the bad habit to just turn it off and on again and if it then works I just forget about it all together.

Another thing I noticed and I'm also guilty of myself. Alex has been asking for tests with the the new ISO's with very little respons. I never played around with these because they required a little more effort/brainpower to compile, so I have just been reading the thread and cheering for the dev's.
But maybe a separate section on the forum could be created for dev's to ask users to test something. This way the more tech savvy users can easily find stuff to help with. Like feature requests where users can ask for stuff, a test request where the dev's get to ask the users. If this does not lead to duplicate threads and more work in general.

General Chat / Re: Low Skill shooters slowing down production
« on: July 09, 2014, 01:21:45 AM »

First off all if you want something cheap or free don't expect it to be done good or fast, don't expect anything at all.

To overcome this problem I would suggest finding people who want to learn. Offer to teach them and train them in return for their time helping you.
Take the time to teach them and get them involved in the making of films.
One very good way to do that is to rehearse your scenes with them. Instead of focussing on the results pay attention to them.

If they don't understand the technical side they will do a bad job. If they don't understand the artistic/creative side they will get bored and do a bad job.

My experience is more with photo assistants but basically it is the same. If they have to run around for a day moving lights and stands they will not do so properly or quickly if they don't see what they are creating. If they do see it, they will go above and beyond to make some magic happen.

Share Your Photos / Re: A few from me
« on: May 01, 2014, 08:35:27 PM »
really like the light in the first one.
Can't wait to try the iso module in the studio for some side by side comparison.
Although I think it will be most useful outside where you can't use a fill light to lower contrast.

Duplicate Questions / Re: Never close Mirror (even on changing Modis)
« on: April 22, 2014, 10:32:22 PM »
Just tape the mirror to the top of the housing.
Almost free and it doesn't need software updates ;)

Duplicate Questions / Re: Never close Mirror (even on changing Modis)
« on: April 22, 2014, 05:12:18 PM »
Then the VAF filter might be the right way to go.
Or a mirror-less camera.
not what you want to hear of course but sometimes special shooting conditions do require special gear.

Pretty much the only 2 ways not to have mirror sound and use ML

Duplicate Questions / Re: Never close Mirror (even on changing Modis)
« on: April 21, 2014, 09:17:42 PM »

This was partially discussed here.
It was more about the shutter and not the mirror.

You can buy something like this
It will keep the mirror forced up.

But shutter count or over use of the mirror mechanism shouldn't be a concern. These things are built to take quit some abuse.

p.s. for hardware questions it is always helpful to know what camera you are using.

Duplicate Questions / Re: Raw files speedup videos!
« on: April 20, 2014, 06:22:36 PM »
can you post what you changed in your workflow?
Helpful for others when they read this thread having the same question.

On another note...
A lot of clips in the video are out of focus and show a lot of movement in close up.
Not an expert but I would try a slightly faster shutter speed and stop down the lens a bit, or practice the focus before each shot.

Duplicate Questions / Re: Raw files speedup videos!
« on: April 20, 2014, 02:40:29 PM »
I don't know Sony Vegas, but I can share my workflow:

before filming:
-decide on resolution and fps (shooting everything in the same fps and also exporting to this gives a better result)
-shoot raw

-convert to jpg with adobe camera raw (tiff or psd or cinema dng will ofcours also work, but jpgs are fine for most of my work since I do the color correct in ACR)
-import the jpg's as a sequence
-change the frame rate of the footage
-do the after effects stuff
-render to quicktime animation or prores (basically any uncompressed format, takes up a lot of space and slows down your workflow, but it has the best quality)
-open this in premiere pro
-start editing
-export multiple files for all purposes (vimeo youtube dvd ....)

some pointers for uploading:
-vimeo gives better video result because it doesn't compres your video as much as youtube.
-a 50mbs file will look worse than a 5mbs file uploaded to youtube. (youtube might not recompress your 5mbs file and ae and pr pro do a better job at compressing than youtube)
-use the presets, they are pretty good

some general pointers:
-changing the fps (not slowing down or speeding up) can give bad results because the software had to delete or interpolate frames
-in AE an PR Pro when rendering make sure the "use previews" box is not checked. They will not render your movie correctly, but just use crappy preview files to make your export file
-get the right resolution straight from ACR or other Raw software. They will do a better job since they have all the data from the raw file to work with.
-try not to make too many intermediate renders. optimal workflow: ML raw => Cine DNG => Premiere Pro (from Premiere Pro you can acces AE without rendering) => final export

Duplicate Questions / Re: Raw files speedup videos!
« on: April 20, 2014, 01:28:37 AM »
how did you interpret the footage?

The output frame rate is irrelevant to the speed as After Effects will keep the speed of your comp, but add or remove frames.
So right click your source file, choose modify and interpret footage, there you set your recording frame rate


Just watch this. Neither you nor you're clients will care that you are working on a pc when you get your work done more quickly.
The G7 is cheaper, a whole lot faster and doesn't come with with extra solder added to all the internals

Don't switch to apple :)
I grew up with it so I have no idea how to use a PC. (not that it would be impossible, just used to os x)
But the money I would have saved....

True on the intel gpu part and the ssd experience part.
But since apple no longer makes the regular macbook pro (only retina), you are forced to choose for a gpu that can not really handle the resolution.
So I would wait another year, next gen gpu's will be better at handling that many pixels.
Or buy a second hand 2012 model.

I'm just thinking about the value for money.
If money was no object, I wouldn't worry about performance on a laptop and buy a high spec apple desktop to do the actual hard work.
Any laptop would then be fine for back-ups and a little work on the go.

long time apple fan boy by the way, but I really don't like the direction apple is going now. The machines are still awesome, but not without compromise.

Couple of things that are different with apple than PC.
Only since 2012 do they have USB3 (so don't by a second hand machine from before 2012)

Retina Macbook Pro's are very pretty but you pay a lot of money for a screen.
On the Retina's you cannot change ram, gpu or cpu. So you are forced to buy the highest spec if you want it to last.

SSD as the boot drive do not really speed up your proces.
Buy one or more Thunderbolt SSD drives to use as cache disks. This will make a big difference.
But remember these will only last for about a year if used as a cache disk and then you will see them drop in performance.
SSD suffer from extensive read write (the essence of a cache disk)
This is also the reason why you don't want to use your boot drive as the cache disk.

On the gpu side: -Performance is bad on the retina models because these crappy mobile gpu's have to drive way too many pixels.
                          -Base models don't have discreet gpu's only the built in intel option

On the cpu side: get a high spec I7. having 8 threads that run at about 2.5ghz really does make a difference.

My personal beast is a 2012 macbook pro 15 inch (non retina)
-2.7 ghz I7
-16gb ram
-1gb Vram
-250 gb ssd boot drive
-1TB hard disk for storage (owc second drive bay instead of the dvd player)
-200 gb ssd thunderbolt cache disk.

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 25, 2014, 02:02:31 PM »
that must be the most quoted sentence ever ;)

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 25, 2014, 10:48:21 AM »
I would say we leave this be for a bit until we hear back from a1ex.
He is the only one who can say it is no trouble coding the 1888.

In the mean while has anyone checked with the guys who developed mlv2dng / raw2dng / RAWMagic /....
Might be interesting too know all the sides to this question before we (users) start deciding things we cannot help with.

My 5D2 is above 70K actuations with another 10K live view.
So I'd say if you are only at 2K you'll be good for a while.

Pro DSLR's are rated at at least 150K.

Worry about hot pixels, 4K taking over the industry, global warming, ....
This is not an issue you will ever need to deal with.

If I happen to find a way to stop it actuating mechanically (squeezing a paper around somewhere? lol), would it effect the video shooting capability of my camera?

I don't think it will affect video, but it won't save battery. Jamming the shutter doesn't turn of the mechanism and it will still draw power

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 23, 2014, 10:24:11 PM »
That's sample "c." You have it in reverse order for the full shots :P. The one I have the most difficulty telling apart is the building shot.

haha, in the building shot if you look at the paint strokes on the bricks you can see a difference, they have a bit more contrast.

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 23, 2014, 09:19:43 PM »
the only thing i can think of which would be helpful to have higher res, is doing software stabililzation. i think i need about 3% edge area to get my preferred stabilization, so even the 1% gain in pixels would be handy, but not dire.

true, hadn't thought about that.

Interesting, so I got 2/3 correct on the test. I'm surprised that I guessed sample "a" wrong. Even after comparing the "side-by-side" shots, my eyes are still biased toward the 1856 shot  :o.

if you look closely at the top connectors of the grip you can see a difference in sharpness

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 23, 2014, 05:32:37 PM »
No you are right, the big camera specific exception refer to 1872.
I understood that 1888 with the black borders was also an exception.

@alex Is there no difference in coding now or in foreseeable the future between 1856 and 1888?

If there is no coding difference and since no one minds about removing those borders in post, it would be best to have 1880.

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 23, 2014, 04:56:20 PM »
Like it was stated before the choice is not between 1856 an 1880.
The choice is between simple implementation for all camera's or an exception for the 5d2.
This exception comes without real coding effort now but makes it harder to maintain Raw for the 5d2 in the future.
The simple implementation has a very slight loss of resolution but makes ML easy to maintain, bug test, ....

So if there ever is a bug in raw video or a new feature there is no need to wait for the 5d2 port. It will just be there from the start.

a1ex asked for proof that 1880 is the way to go and worth all the extra trouble.
I think 1856 is just as good as 1880 even if logic says that there is loss of resolution and quality.

the loss is 1,0265 percent

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 23, 2014, 02:33:22 PM »
pored it into a little html page. not perfect (the scroll doesn't follow) but the only way I could let you see them on top of each other in 5 minutes work.

another confession: I scrambled the naming in both sets I posted. Since no one noticed that, I'd say there is virtually no real world difference between 1856 and 1880.

a1 oct 24 1880
a2 nightly 1856

b1 nightly 1856
b2 oct 24 1880

c1 oct 24 1880
c2 nightly 1856

full size:
a1 nightly 1856
a2 oct 24 1880

b1 nightly 1856
b2 oct 24 1880

c1 nightly 1856
c2  oct 24 1880

a.d. & pravdomil's 5D2 builds / Re: 5D2 RAW video Builds 14-Bit
« on: March 23, 2014, 12:26:15 PM »
You can also use the width tag

[img width=900]

Thx for the edit.

Pages: [1] 2