I just redid some benchmarks to find out if the new 12Bit processing causes any performance degradation. On two machines, Mac and Windows, 1.76.12 is even slightly faster than 1.69.
Carl, is the 12Bit processing always on, or only with content >8Bit?
- Carsten
Thanks Carl!On Nov 10, 2014 4:08 AM, Carl Hetherington <cth(a)carlh.net> wrote:
>
> On Sun, 2 Nov 2014, Sumit Guha wrote:
>
> > I like Carsten's idea of individual H/V sliders. Maybe you can have it as an user-selectable option so that one can choose to use it or not.
>
> OK, I've added that to the to-do list:
> http://carlh.net/mantis/view.php?id=425
>
> I guess if it's hidden behind a "custom scale" option it should be ok.
>
> Best,
> Carl
>
> _______________________________________________
> DCPomatic mailing list
> DCPomatic(a)carlh.net
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
I like Carsten's idea of individual H/V sliders. Maybe you can have it as an user-selectable option so that one can choose to use it or not.
Sumit
On Nov 2, 2014 9:46 AM, Carsten Kurz <audiovisual(a)t-online.de> wrote:
>
>
> Am 31.10.2014 um 00:36 schrieb Carl Hetherington:
>
> > As I said above... I had not anticipated the desire to have true
> > no-scale, to put a small image in the middle of a big screen...
>
>
> Yes, bit of a problem, how many 'creative' options do we want to add to the software - putting a picture into a black frame like this technically is letterboxing/pillarboxing, but not in a strict technical sense. Normally one would do that in an external editor.
>
> BTW - this is not only a problem with SD footage like from DVDs or DV-video - there are also HD-formats with non-square pixels, e.g. HD-DV/HDV is 1440/1080, and I just took a short test with my Sony digital camera set to MP4 format - it says '1080' in the camera menu, but in fact creates a 1440/1080 file with non-square pixels. DCP-o-matic states it is 1,33:1 and previews it squeezed.
> Now again, I can 'just' get it right in DCP-o-matic using the 16:9 option, but that is the only way to do it. Also - in this case I KNOW it is 16:9 and non-square pixels - what if people do not know it and/or the preview image doesn't give a clear visual indication?
>
> Personally I would love to have individual H/V scale sliders, but I don't think this is suitable for the general public ;-)
>
> I guess it would be best to make DCP-o-matic use an existing AR-flag. Then - checkbox or not..., in content tab, or prefs? I guess I would want to have this handled in content specific options, so a 'per file' setting.
> At some point it could become important with bitmap files as well, although they are usually easier to correct externally.
>
> I have seen quite a few files with non-square pixels WITHOUT a proper flag, but I have hardly ever seen a file with a 16:9 flag set wrongly, so I think the risc is small this will cause real harm. And I think most people would like to have DCP-o-matic show these common content types - DV/HDV, and 16:9 DVD with the correct aspect ratio after import immediately. Like my fellow projectionist does ;-)
>
> - Carsten
>
> _______________________________________________
> DCPomatic mailing list
> DCPomatic(a)carlh.net
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
Today I had to create a DCP without sound, that is, the minimum requirement would be 2ch, padded with silence.
I think DCP-o-matic has no formal way to do this - I can set channel count to 0 in DCP properties, but then I get a warning that my DCP contains no sound, that I guess means that no audio.mxf will be generated at all.
Same happens when I deselect the existing two audio channels in content audio tab. I think DCP-o.matic should be stricter, that is, if channel count is set to 0, it should create a 2-channel file padded with silence. Same if I deselect existing channels in an interleaved video/audio file. And it should force channel count to an even number of channels any time. Maybe for now, the easiest way is to limit the channel choices in the DCP tab to 2,4,6,8..., and if there is no audio, or it is deselected in the audio matrix, it should padd the channels chosen in DCP tab with silence.
Of couse, I could just use a very high negative gain, or map the existing audio to channels typically not used. But I think there should be a straighter way.
- Carsten
Attached the spanish translation files for v2.
I suspect that here you wanted to put 14fl and not 4 fl
"Mastered luminance (e.g. 4fl)" [src-wx-po]
Thanks!
Manuel AC
Hi Carl,
I recently received a few questions from users which wanted to import image sequences for video. I had to pinpoint them towards the fact that you can select multiple images with 'Add file' as well as with 'Add directory'. They didn't understand that by using 'Add file', the images would be interpreted as single objects, creating a sequence of slides, and by using 'add directory', they would be interpreted as an image sequence for moving image.
I would like to make this more clear in the naming/translation of the 'add directory' - however - which consequence will it have when using 'add directory' with other media types, can you tell us which interpretation is behind that option in contrast to add file with a multi-file selection? Because if it only works with image sequences for video, we could just as well name it that way.
- Carsten
Someone I know had a problem when trying to convert an iTunes music video file using DCP-o-matic. When adding the file, the summary shows a content frame rate of 90000.0000, that every other frame will be used, and the DCP will run at 0.133333% of the content speed. The timing tab shows a play length of over 38 hours (this is a 3 minute music video) and a video frame rate of 90000.0000.
I was able to duplicate this in 1.76 and 1.76.2 with an iTunes music video I have.
These files are not DRMd.
Any suggestions as to what may be the problem?
-David
Hi all,
DCP-o-matic 1.76.0 is now available from:
http://dcpomatic.com/download
It includes various internationalisation improvements and some assorted
bug fixes:
Update to nl_NL translation from Cherif Ben Brahim.
Fixes to some i18n on OS X.
Fix discovery of encoding servers to work more reliably.
Fix loading of Targa files.
Fix non-update of audio gain when changing the content selection.
Fix crash on exit when the preferences dialog is open (on OS X).
Fix server certificate downloads on OS X (#376).
Allow separate X and Y scale of subtitles.
Copy current ISDCF name into the film name when ‘Use ISDCF name’ is un-ticked.
Fix hidden advanced preferences button in some locales (e.g. de_DE).
Improve behaviour of batch converter window when it is shrunk (#338).
Write <Creator> tags to CPLs with the creating DCP-o-matic's version number.
Drop a hint when there is may be a better DCP container option than that currently selected (#392).
Add a copy button to the preset colour conversions dialogue (#399).
Fix missing ‘no stretch’ and ‘no scale’ options in defaults preferences.
Allow drag and drop of files onto the content panel (#395).
Possibly fix OS X crashes when doing audio plots.
A couple of other small fixes.
Thanks to Carsten Kurz, Cherif Ben Brahim, Raymond Steers and Lilian Lefranc.
Best regards,
Carl
Here's a question for the list! :) Any suggestions, anyone?
---------- Forwarded message ----------
Date: Tue, 14 Oct 2014 16:16:10 +0100
From: Anand Madabushi <armadabushi(a)gmail.com>
To: carl(a)dcpomatic.com
Subject: P3 to XYZ conversion matrix
Hi Carl,
I've got a feature film that's currently sitting in DCI-P3 colour space. I'd like to use a custom matrix to convert this space to XYZ using your awesome software.
You currently have 3 presets, but not a P3 one. I've scoured the web trying to find a 3x3 matrix to do this conversion and even tried to calculate one
mathematically - with no success. I would assume others have tried to do something similar.
Any idea where I can find a conversion matrix for P3 to XYZ?
Many thanks,
Anand Madabushi
Outsight Films, London
I recently had to correct the hash value on one of the reels of an Interop DCP, which was also signed. I changed the hash values of the reel in the cpl and pkl files and also had to change the hash value of the modified cpl asset in the pkl. I was lucky to be able to test this on a few different systems:
1. Christie IMB
2. Dolby IMB
3. Doremi DCP 2K4
4. Doremi IMB
All 4 systems ingested the content successfully. Apart from the Christie IMB, the remaining three systems had no issues playing back the modified DCP. The Christie IMB came up with a 'CPL Validation Issue' when I tried to play it.
Sumit
On Oct 14, 2014 8:55 AM, Carsten Kurz <audiovisual(a)t-online.de> wrote:
>
>
>
> > I tend to do it unsigned, so I can later modify the xml files by hand
> > if needed. Wondering if there is any advantage on signing (not
> > encrypting) a DCP.
>
>
> As far as I know, at some point unsigned SMPTE DCPs will be rejected by servers. I don't know which server currently enforces that already. Signing usually will prevent others from doing changes to the DCP. That could be a benefit or not.
>
> I have yet to do some testing of signed/unsigned Interop and SMPTE content on different servers to find out what happens. I did some test previously on our Sony which shows various validation indicators for ingested content. I haven't been able to find out exactly what they are based on, because they vary even for 'commercially' generated content - trailers, features, etc.
>
>
> I follow the ISDCF maling list for a while now and the ISDCF's struggle in the transition from Interop to SMPTE formatting. It's a simple technical, but complex behavioural process, which in turn makes it a complex technical matter again because of a necessary transitional process in order have no lost shows.
>
> Also we should not take for granted that the DCP-o-matic is doing it is completely right or the only way to implement it.
>
> We recently had an issue with a commercial DCP that was one of our first tests of an IP based download from a german content provider. We were able to ingest it okay, it would show up in the list of ingested features, but we couldn't select the CPL for playback, it simply didn't turn up in that CPL list. So there was obviously something wrong with it. Another download fixed it, but we weren't even sure wether they had changed something in the file now or if it was a download issue (a dedicated download client is used).
>
> As far as I know, 'Signing' is for authorative preventing of intentional or unintentional manipulation, while 'file hashes' provide some technical means to assure proper transmission and storage.
>
> Then a server could do some additional checks to make sure the content is correct, e.g. checking for valid audio or J2k file structures. I don't know which server applies which strategies. Most do some checking while or after ingesting.
>
> - Carsten
>
> _______________________________________________
> DCPomatic mailing list
> DCPomatic(a)carlh.net
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
