Reverse Engineering Picture Styles

[chmee]

here two screenshots about the plaintext-riddle i assume, if we take this hurdle, we can read the whole file.


pf3_plaintext_decode_01

the difference is hex20 as in ASCII, but sometimes -20, sometimes +20


pf3_plaintext_decode_03

the same characters are encoded differently. maybe some of you see a pattern But: Do not forget, after decoding we ve got still a binary file, we have to find offsets for the entries.

[Kharak]

It looks like some kind of Alien Technology to me.

but what do I know.

[markanini]

Yes that could be useful. As for creating icc profiles one can convert 3D luts to icc profiles with for instance OpenColorIO. Tip from Andy600 a while ago. That fact doesn,t really solve the core issue here for know but might be useful later.

I might be wrong but argyllcms does this too.

ICCs contain can contain LUTs but also matrix data. No one will be surprised though if the data in a pf2 is represented in a proprietary way can't interpret like existing standards like ICC and DCP. I hope one day we will able to convert an ICC or Adobe DCP to pf2. That would allow for capturing colors with high accuracy for documentary footage or slide transfers using DCamProf for profiling, or film simulations straight out of the camera.

[reddeercity]

Found something interesting  at https://searchcode.com/codesearch/view/20202630/
perl-Image-ExifTool /Image-ExifTool-8.90/lib/Image/ExifTool/Canon.pm
I guess this is Perl Language , anyways at line 4569 there some tag info on picture style

Code: [Select]

from line 4703 to line 4709   
# base picture style names:
    0xd8 => {
        Name => 'UserDef1PictureStyle',
        Format => 'int16u',
        SeparateTable => 'UserDefStyle',
        PrintConv => \%userDefStyles,
    },But I can't find the "SeparateTable" info
If nothing else some good info , but not sure if any of this really helps.

[DeafEyeJedi]

Yes that could be useful. As for creating icc profiles one can convert 3D luts to icc profiles with for instance OpenColorIO. Tip from Andy600 a while ago. That fact doesn,t really solve the core issue here for know but might be useful later.

Agreed.

[dfort]

There's a discussion about the Canon Emerald picture style in another topic:
http://magiclantern.fm/forum/index.php?topic=17896.msg172219#msg172219

I checked it out in the Canon Picture Style Editor and surprisingly it isn't locked for editing. However, in the editor it only shows the default settings with the "Base Picture Style" listed as Emerald. I just thought this was interesting and it might give us some clues into how picture styles work. The Emerald pf2 file is only 1KB in size.

[Andy600]

I managed to unlock Cinestyle a couple of years ago and just found the file again (not sure I can post here!?  ).

I'm 99% certain that Cinestyle is all done with a lut in Lab space, similar to some ICC profiles.

The profile will open in PSE but reveals no user-editable parts. There is no tone curve data, no HSL adjustments etc and everything turns yellow. The tone curve has no effect except when moving the top and bottom control points. Removing the yellow saturation (6 color-axes) and pulling brightness -2 stops (preliminary adjustments) reveals more detail in the image.

I'm guessing the introduction of the PF3 format with an RGB tone curve basically gave users much the same level of control that Technicolor had when developing Cinestyle (pf2 format) which is why you can get very close to the Cinestyle tone curve - but not exact because of the limited, interpolated control points.

Sadly, this all seems to take place after Jpeg compression. For a proper log profile like Canon Log there needs to be a way to add the function before compression.

Standard



Cinestyle (unlocked)



Cinestyle (unlocked) -2 brightness 0 yellow sat



In DPP

[Danne]

Not posting any unlocked profiles is probably the better idea .

Sadly, this all seems to take place after Jpeg compression.

So practically applying log after it,s filmed with neutral will yield the same result as with technicolor in cam? Havn,t tested this.

[Andy600]

Not quite. Once that contrast is baked into the image the detail is gone.

There are only 256 values to play with but you can gain a little more wiggle room with Cinestyle and with your's and @dforts remake (which is very good BTW) but doing so compromises other parts of the image which can manifest as more visible banding or noise. Raising the black level is probably the most useful thing to do because the H.264 encoder doesn't handle noise well.

[Danne]

wiggle, wiggle 

Once that contrast is baked into the image the detail is gone.

Confirmed then. Thought so over here too.

[chmee]

uuh. i was (theoretically) sure, the styles are used after demosaicing and before/while rescaling to 8bit/jpg.

[Danne]

How to test this? One thing is that picture style editor doesn,t seem to get to linear. Or is it? I played around in dng profile editor and created a dcp profile around logNeutral curvepoints(not exact translation, the dng profile editor curve tool has its own life when adding points). Base tone curve set to linear and whoops suddenly scene referred? highlights are retained even more or am I having a placebo? I turned down sharpness settings in acr.

logNeutral 1.4


logNeutral dcp linear opened in acr

[a1ex]

Does this experiment help you with checking the linearity?

[Kharak]

I'm pretty sure ACR has some auto - Highlight reconstruction, which might be what you see in ACR. Try setting the process to 2010 and 2003. To confirm if you are getting better results.

Also the green on the left side of that balcony, could indicate that ACR is using highlight reconstruction from the Green channel which is more present in the Bayer pattern.

[Danne]

That,s the thing @Kharak. You can,t grab the linear extra information from within acr. You have to get it through a dcp in dng profile editor. I think it,s true linear. Then again you might be right Kharak. ACR is a hidden box of tricks. Tried setting to process2010. Looked like crap.
Since acr is a still image editor most people doesn,t care about this and start working with highlight sliders etc which will give you roughly the same info back but will cause flicker if used in movie sequences.
For sequenced movie dng files a simple linear dcp will cause no flicker but get you some extra highlights.

Thanks for the link A1ex. Missed that one. Gonna check that some more after a good nights sleep

[dfort]

...highlights are retained even more or am I having a placebo?...

I took a closer look at the images you posted using the Mac Digital Color Meter app and it looks like they both have the same amount of highlight detail. The only difference is that the second one doesn't reach the same brightness as the first example. It just looks like there's more detail in it.

@Andy600 -- that's some strange behavior on your unlocked CineStyle. Interesting--so your experiment looks like CineSyle is based on the Standard picture style, not Neutral? Maybe our reverse engineered CineStyle named logStandard is closer to the original than logNeutral?

I found that locked picture styles can be used in DPP (Canon Digital Picture Professional) but of course can't be edited in Canon Picture Style Editor. A CR2 exported to JPEG using CineStyle in DPP doesn't quite match a JPEG shot in camera using CineStyle though they are very close.

So are picture styles applied before or after JPEG compression? I've been thinking about that too. If it is after JPEG compression we'll never be able to create a picture style with a dynamic range greater than one of the standard built-in picture styles set at the -4 contrast setting, right?

[agentirons]

What would be possible if we could get into the Canon file formats? It would be possible to build an MLV to DNG application that translates the picture style into a dcp that can be tagged into the DNG files. Of course the DNG files need to be debayered by a program that understands how to decode the embedded dcp information and it seems that only Adobe Camera Raw and Lightroom can do it.

You guys are my heroes! I just started looking into this exact pipeline again at work, hoping to figure more out. This is what we've wanted for years at our stop-motion studio - monitor on stage using Canon Landscape jpgs, use the CR2s (converted to linear EXRs using ACR/After Effects) in VFX, then apply the Canon Landscape look as a LUT in post so that our DP can start coloring based on exactly what he saw on stage. @Andy600 has done some fantastic work with Cinelog (thanks again, Andy!) but this is still the missing piece of the puzzle. I PM'ed Eric Chan from Adobe about the ACR side of things but haven't heard back yet. I'm still learning with regards to LUT formats, and maybe this was already doable with some other method, but being able to turn a picture style into a dcp would be a god-send.

[dfort]

Wow, quite a workflow. I have worked in animation myself for years and am somewhat familiar with using EXR's in the production pipeline. Picture style to ICC to DCP (which of course gives you a picture style applied to a CR2 on ACR) is what we are trying to figure out.

[dfort]

Yet another log picture style. This is the one Philip Bloom commented on about a while back, CLOG NEUTRAL.

According to the developer, James Miller:

CLOG Neutral comes in two options, one with a highlight roll off knee that stays below clipping (v1) and one where its a little more pronounced (v2).

CLOG 3 gives you a more Canon style modern LOG image.

(Note that I found out about this while Googling "logNeutral" just to see if anyone was talking about our reverse engineered CineStyle picture style.)

[agentirons]

I wonder if another way of doing this would be to create a computer-generated CR2 file that contained known values in a color chart (like a faked, exact Macbeth chart instead of a photographed one), load it into Canon's Digital Photo Professional for converting to 16-bit TIFF using a specific picture style, and then analyzing the RGB differences for each swatch to generate an ICC and a DCP.

It wouldn't let you mathematically generate a pf2/pf3 from a known colorspace like CLog or ArriLog, but it would let you get from existing pf2/pf3 files like Cinestyle into a mathematically generated ICC/DCP file.

Here's the breakdown of the CR2 file format - http://lclevy.free.fr/cr2/

[Danne]

Well creating the cinestyle log into a dcp profile seems not too hard does it? We recreated the curve somewhat primitive 10 points but you can add the points into dng profile editor and come close. If you really want to work your way into a dcp profile you can use dcptool both to decompile and compile anything you want in floating point.
http://dcptool.sourceforge.net/Introduction.html

If you want to convert a 3D lut into an icc profile that can be done with opencolorIO
http://opencolorio.org/
Not that easy though to get coherent results with icc profiles. There seems to be a lot of complexity with icc profiles and various converters seems to produce different results. Then again I might have tested it wrongly. I know that dcraw exports raw_color when applying an icc profile.
I provide 3D luts of cinestyle some posts up, try converting those to icc profiles to start with maybe.

Producing and finetune matrix conversions between formats will probably take time but there is probably a lot of experience here that can be used in a lot of different workflows.

[jkaura]

Hi!

I think there seems to be XOR operation taking place in encoding of picture style files. Take a look at the latter pair of chmee's example files having title and copyright fields consisting of series of single letters: A and B, respectively.

(1) In the first file the title consists of 10 x 'A' and it is encoded in hexadecimal as: 580F 2FC2 552F 2E76 D23D. When XOR'ed with 10 x 0x41h ("AAAAAAAAAA" in hexadecimal) we get: 194E 6E83 146E 6F37 937C

(2) In the second file the title consists of 10 x 'B' and it is encoded in hexadecimal as: 5B0C 2CC1 562C 2D75 D13E. When XOR'ed with 10 x 0x42h ("BBBBBBBBBB" in hexadecimal) we get: 194E 6E83 146E 6F37 937C. The same as with the first file!

[Danne]

Interesting. Thanks for sharing. I tried googling this info but I didn,t understand much. Can you make out any numbers or other understandable patterns we could use?

[DeafEyeJedi]

Interesting. Thanks for sharing. I tried googling this info but I didn,t understand much. Can you make out any numbers or other understandable patterns we could use?

+1

[jkaura]

I think in order to fully reverse-engineer .pf2/.pf3 format we should probably start with the lowest hanging fruits and then make progress to the harder parts (e.g. encoding of 6 color-axes data, possibly in form of ICC profile). One of the easiest things to do (still probably not very easy), as chmee presented in a previous post, is to reverse-engineer encoding of caption and copyright since by focusing on those two fields we can apply a so-called "chosen plaintext attack" as the exact input is known and can be freely selected. As I mentioned in my previous post, I think one component of encoding caption/copyright is applying a mathematical bitwise "Exclusive or" (XOR) operation on plaintext (https://en.wikipedia.org/wiki/Exclusive_or). XOR takes two operands; in this case one operand seems to be the plaintext string given by the user while saving a file in Canon Picture Style Editor and the other one is an opaque bunch of bytes the semantic of which is unknown. Resolving/understanding that unknown is IMO one step towards reverse-engineering this file format.