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.

Show posts Menu

Messages - TheUnkn0wn

Quote from: wheezl on August 23, 2013, 12:06:07 AM
Runs fine now on my machine  OS X 10.8.4

Prcoessed a raw file. I'm going to compare the output to rawmagic.

Update:  The output is quite different than RawMagic.

update2: Here are two example frames.  The output is similar wether I pick force linear or uncompressed/lossless.

I made no effort to find a decent light :)

Interesting, looks like raw-magic applies more contrast.
Updated to 1.1.0, please test the changes?

Quote from: chmee on August 22, 2013, 10:57:38 PM
(*) rawmagic & raw2cdng do not use raw2dng.
(*) compression is an advantage - practically a sizereduction of ~10% (max ~20%)?
(*) are your dng's supported by speedgrade?

(*) i didnt wanted to be impolite - but i dont see any real benefit beside the compression - and i honestly recommend, to invest the time into mlv. thats it.

regards chmee

- Multi-Threading = Faster conversion from RAW to DNG
- Uses the Adobe DNG SDK for DNG support = Adobe are the creators of the DNG format
- Compression = Lossless JPEG compression, smaller file sizes
- Force Linear = On certain cameras when using a RAW_TYPE that doesn't contain pink dots (650D/700D/EOS-M) the DNG's can't be read correctly by dcraw which means software like RAWTherapee cannot process them correctly. This corrects this issue.
- Standalone = Portable. Doesn't require a folder of files for it to work.

Why don't you download and test it, let me know what you think. When the new Magic Lantern format for RAW is finally released I will add support.

P.S :

QuoteThe first implementation is done and we can record in the new format.
post processing is still done with 'raw2dng' after converting the .mlv into the legacy .raw format using mlv_dump.
Quote from: chmee on August 22, 2013, 07:17:52 PM
@TheUnkn0wn asking gently, whats the benefit of your tool comparing to the other tools existing? with all due respect, better do some research/code in mlv, not raw.

regards chmee

Read the features list, this is also multi-platform and standalone. Other tools require the ML 'raw2dng' tool and are merely a GUI for it. Currently the ML format isn't used, when it gets pushed to the branch I'll support it.
Thanks for your feedback, I'll look into everything today. You've managed to find things I never would of testing on my own.
Quote from: PlayIt on August 22, 2013, 05:08:54 AM
The Mac version doesn´t open in my mac pro running osx 10.6.8

Thanks, I'll update it tomorrow (it means re-building Qt statically which is a pain on a virtual machine) I need sleep.

Magic Lantern RAW - 1.2.0

A simple standalone tool for converting magic lantern RAW video files into DNG or TIF sequences.

- Multi-Threading (makes use of those CPU cores you have)
- Using the Adobe DNG SDK (full DNG support)
- Directly convert to TIF
- Compression (compress your DNG's using Lossless JPEG)
- Force Linear (rebuilds DNG with demosaic CFA data, aimed for use with the 650D/700D since dcraw can't handle their DNG's correctly, I recommend you leave this disabled unless you have a 650D or 700D)

1.0.0 - Initial Release
1.1.0 - Compiled statically, modified multi-threading
1.1.3 - Fixed memory leak
1.2.0 - 16-bit TIF, fixed colour issues

Quote from: nanomad on August 21, 2013, 09:27:34 AM
As I explained before the green pattern stands out a lot even in the Luma only image before debayering. It's not a converter fault.

It's not a converter fault, its dcraws fault :P
On the 700D and 650D you get pink dots don't you? That's because of the default raw stream (or raw type) from the camera. If you change it to one that doesn't contain any anomalies; for some reason draw (used by software such as RAWTherapee) can't process the dng's correctly causing a green tinge/mesh over the image. To fix this I've created a new RAW2DNG tool using Qt so its multi-platform. Here are some of the features.

- Multi-Threading (Makes use of all your CPU cores)
- Full DNG support (Using Adobes own DNG SDK, this fixes a lot of things like thumbnails and image anomalies)
- Compression (Can use Lossless JPEG for DNG's)
- Save directly to TIF

Yes, this will properly process the DNG's so you don't get that green pattern you see when using RAW_TYPE 14.

Which means there's no need to remove any pink dots since there wont be any and no quality will be lost.
I already have a solution, I've re-created raw2dng using the Adobe DNG SDK. Since Adobe created the DNG format its best practice to use what they give you. dcraw seems to ignore some meta-data and misinterprets the raw data causing that green mesh. My raw2dng will include a host of extra features including compression.
Try RAW_TYPE 2 it looks clean and it works with both dcraw and adobe software.

EDIT : nvm, I've found dead pixels in it...
Ok, me and nanomad have kind of figured out the problem. With raw_type 14 you don't get any image anomalies using Adobe software. Using other software causes these anomalies. It's probably down to how the DNG is created?
Ooops! My fault, no wonder they all look the same, I still had the 700D RAW_TYPE address in there...

Try this one, it also goes to 255 instead of 99
Could anyone with a 650D and ML please read this?

Who wants to do some pixel peeping for the 650D?

Download that, replace the files on your 650D SD card. Enter Movie Mode, go to the debug menu and click on "Don't click on this!"

It will start taking 100 frames, might take a while. Make sure you keep your camera on something static so you can pixel peep properly.

Once it has done you should have 0000-0099 DNG's on your SD card. Go through them all (I recommend light room) and find the BEST one out of them all, report your findings REPORT THE FILE NAME of the best one you've found.
Looks like someone with a 650D will have to run this

P.S : After making the changes in debug.c, to run it go to the Debug menu in ML and click on Don't click on this!
I didn't know there was an IRC channel  ???

What's the channel?
Thanks for helping test these changes, I've pushed a pull request with the fixes ;)
Quote from: nanomad on August 17, 2013, 11:07:35 PM
Raw 99 is full of green dots on the 650D :/

For me the 700D has a perfect picture with 99. When I was pixel peeping the RAW_TYPE's I found that 78 and 99 were the best.

Try 78? Looks like the 650D and 700D aren't "exactly" the same after all. If that doesn't work then run this

debug.c - based off work from a1ex

#include "raw.h"

static void run_test()
    char fn[100];
    for (int type = 0; type < 100; type++) {
        MEM(0x350B4) = type;


        snprintf(fn, sizeof(fn), "%s/%04d.DNG", get_dcim_dir(), type);

        bmp_printf(FONT_MED, 0, 60, "Saving raw type %d, %d x %d...", type, raw_info.jpeg.width, raw_info.jpeg.height);

You will have to pixel peep all of the pictures, I used Lightroom to do this.
Green dots!? Can you provide a picture? Has anyone else had this problem yet?

No, my pull request is pending. If you really can't wait then try THIS.

Please respond with your results!
Quote from: spider on August 17, 2013, 09:55:29 PM
:o :D ;D
How does it work? Are these pixels interpolate in the camera?

Nope, nothing is interpolated. Which means your not losing any details anymore. I've set the RAW_TYPE to a stream that doesn't contain those anomalies.
I think I've fixed the pink dot issue, would be nice if someone could test this on a 650D (I don't have one, but the 700D is pretty much the same)
How to get AE_VALUE the easy way

1. Search for "***** copyOlcDataToStorage DataSizeOver Group0"
2. Go to its definition (as seen below)

3. Look above it you will see a value, in the example its 0x367B4
4. Pointer to EXPO_COMP = 0x367B4+0x1C

#define EXPO_COMP (*(int16_t*)(0x367B4+0x1C))
#define AE_VALUE (EXPO_COMP-1) * 8 / 2048

Done. ;)