purthaler / ffmbc

Automatically exported from code.google.com/p/ffmbc
Other
0 stars 0 forks source link

DPX #75

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. ffmbc -i PRORES_422_1080p25.mov -t 0.04 -pix_fmt rgb48be image.%04d.dpx
2.
3.

What is the expected output? What do you see instead?
I expect to see a correct image when opening in Nuke.
Instead, when opened in Nuke the image the colors are green and generaly off. 
Also the image is shifted so the right side of the image is over on the left 
half.
When image is opened in djv_view or imagemagick's convert the image looks fine.

What version of the product are you using? On what operating system?
0.7rc4

Please provide any additional information below:

- Full commandline run (with -v 3) and everything the program printed
without
the repeating parts.
- Upload your sample somewhere and supply url

Fix:
To fix the image I run the image through imagemagick only setting the depth to 
either 10 or 16bit

Command:
ffmbc -v 3 -i PRORES_422_1080p25.mov -t 0.04 -pix_fmt rgb48be image.%04d.dpx
FFmbc version 0.7-rc4
Copyright (c) 2008-2011 Baptiste Coudurier and the FFmpeg developers
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'PRORES_422_1080p25.mov':
  Metadata:
    major_brand: qt  
    minor_version: 537199360
    compatible_brands: qt  
    creation_time: 2011-05-09 07:08:31
  Duration: 00:00:20.00, start: 0.000000, bitrate: 156060 kb/s
    Stream #0.0(eng): Video: prores, yuv422p10le, 1920x1080p, 154517 kb/s, PAR 1:1 DAR 16:9, 25.00 fps
    Metadata:
      codec_name: Apple ProRes 422 (HQ)
      gamma: 2.199997
    Stream #0.1(eng): Audio: pcm_s16be, 48000 Hz, 2 channels, s16, 1536 kb/s
[scale @ 0x29ced60] w:1920 h:1080 fmt:yuv422p10le -> w:1920 h:1080 fmt:rgb48be 
flags:0x4
Output #0, image2, to 'image.%04d.dpx':
  Metadata:
    encoder: FFmbc 0.7
    Stream #0.0(und): Video: dpx, rgb48be, 1920x1080p [PAR 1:1 DAR 16:9], 200 kb/s, 25.00 fps
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=    1 fps=  0 q=0.0 Lsize=       0kB time=00:00:00.04 bitrate=   
0.0kbits/s    
video:12152kB audio:0kB global headers:0kB muxing overhead 0.000000%

Original issue reported on code.google.com by flehnerh...@gmail.com on 21 Dec 2011 at 12:32

GoogleCodeExporter commented 9 years ago
I copied the issue froman other google account so I forgot the attatchments. 
Here they are and sorry for the lousy description. It should read: DPX encode 
16bit give "strange" results

Thanks,
-Daniel

Original comment by flehnerh...@gmail.com on 21 Dec 2011 at 12:35

Attachments:

GoogleCodeExporter commented 9 years ago
Humm I created a file then converted it to jpg using imagemagick and it shows 
fine.
Can you share your prores file ?

Original comment by baptiste...@gmail.com on 12 Jan 2012 at 8:12

GoogleCodeExporter commented 9 years ago
I'm sorry if you misunderstood me. The jpg was a render of how nuke reads the 
dpx. I also get a good result by converting the ffmbc generated dpx with 
imagemagick or using mogrify and setting depth to 10|16.
If I play the image sequence in rv (tweaksoftware.com) it complains about 
incomplete frames and eventually freezes the entire machine (which is probably 
a rv bug). 

I had a look at the dpxenc source and tried doing some debugging. What I found 
out is that the function "encode_rgb48_10bit" doesn't get called. I also 
managed to get the colors right by messing around with the default bit depth in 
the "av_cold" function but the image still got shifted.

What I concluded with was that the problem had to have something to do with the 
packing of bits, but keep in mind that I don't have any C experience.

I can't upload the prores of the last example do to rights, but here's a link 
to a prores that gives the exact same result. 
http://www.localheropost.com/alexa/LocalHeroAlexaTest-Day-LogC.mov

I tested the same command in rc5 with the same result.

Thank you VERY much for your great software.
-Daniel

Original comment by flehnerh...@gmail.com on 12 Jan 2012 at 9:28

GoogleCodeExporter commented 9 years ago
hi,

do you still have the problem, I tested and I have no problem with playback on 
Photoshop

Anthony
I don't speak english very well

Original comment by goo...@anthony-arnaud.fr on 24 Jan 2012 at 12:26

GoogleCodeExporter commented 9 years ago
Hi Anthony!

I haven't tested it in Photoshop, but it looks fine in imagemagick's display 
and djv_view. The problem is when we load the image sequence in a compositor 
like Nuke or view it in RV it looks corrupt.

Original comment by flehnerh...@gmail.com on 24 Jan 2012 at 7:04

GoogleCodeExporter commented 9 years ago
I found the problem and it will be fixed in the next rc. Thanks for reporting.

Original comment by baptiste...@gmail.com on 8 Mar 2012 at 3:57

GoogleCodeExporter commented 9 years ago
Great! Thanks!
Just out of curiosity, what was the problem?

-Daniel

Original comment by flehnerh...@gmail.com on 8 Mar 2012 at 9:18

GoogleCodeExporter commented 9 years ago
Some required field in the header was not populated.
I've released rc6, please confirm and reopen if still broken

Original comment by baptiste...@gmail.com on 8 Mar 2012 at 6:36

GoogleCodeExporter commented 9 years ago
Hey Baptiste!
It works like a charm! Thank you!

Original comment by dan...@stormstudios.no on 8 Mar 2012 at 8:49