Magic Lantern Forum

Is it possible to have dual ISO for H.264 video?

well it can be recorded as dual ISO but I don't think it adds any info and there is no workflow.

I'm afraid the compression will make it impossible to recover the image. Didn't try, but I'm not eager to.

don`t know but I imagined something like this

but also in 1080p and not limited to 50fps.
I sure know it would come in handy when filming skaters going through shade areas and into the sun.

All you would need is a dng2hdr right? Just export the h.264 frames, and throw it in there.

im not sure how that would help recover the underexposed or overexposed areas.

I am also interested in this feature, to record dual iso in h264.

I did a try to enable dual iso without enablind the raw video module, but the green dot keeps a little dark and the dual iso just get enabled when I enable the raw video, so to test it, the developers need to make the dual iso independent from raw video module.

I am using the T3i / 600D and no money to get a 5D3. In 600D I am limited to record continous 24p raw at 960x544. The dual iso uses alternate lines for different exposure, so I belive the dual iso just will be ok using 1920x1080 resolution, so no way to get good quality dual iso raw from 600D at 24fps 16:9.

Also, even I could get a 5D3, considering the raw files large size, it would be impossible for me to shoot a short film or documentary in 1920x1080 raw...

So due to these reasons I would like to experiment the dual iso in H264 MOV. I think if I increase the CBR bitrate it would help the encoder to get better image using dual iso. Today I am using 1.3x because this makes the files playable in camera.

I think the workflow for H264 dual iso would be simple... convert the H264 video into a JPG image sequence and do the same workflow, drag and drop over the converter. Maybe it would need another converter? (JPG2HDR)? Or even better to drag and drop the MOV file direct over the converter: MOV2HDR

The HDR video is great for situations without so much movement and it works good in 720p 50p or 60p to get the overexposed frames without optical flow... but the dual iso can do this in images with movement in 1920 x 1080 because it does not need optical flow...

So can you enable the dual iso to work with H264? I would like to test it also.

Thanks

For dual-ISO to work as intended it needs to be dealt with BEFORE any further image processing takes place. I can't see h264 dual-ISO ever working due to the nature of the h264 compression and the image processing that is performed in the encoding phase. h264 will "smear" the high ISO and low ISO lines together somewhat, making it impossible to accurately reconstruct a sensible final image. That's assuming there's even a 1-1 mapping from the sensor to a horizontal line. Any resizing/binning will trash things completely.

I understand the compression problem, it could destroy the separation from the lines making different iso useless, but even knowing this I would like to try... maybe it can give us an average result... why not to try?, it is not so difficult to enable dual iso for H264...

I also got another idea, maybe impossible, to implement a similar function from dng2hdr inside camera, so the camera would do the interpolation and iso merge before compression... this is the "dream"...

I believe someday the manufacturers will implement this kind of thing using a sensor similar to the 70D, there is also a new patent from canon showing the dual pixel af with different size pixels, great for different exposures...

Quote from: apefos on November 13, 2013, 11:43:19 AM
I understand the compression problem, it could destroy the separation from the lines making different iso useless, but even knowing this I would like to try... maybe it can give us an average result... why not to try?, it is not so difficult to enable dual iso for H264...

There's no reason to waste time trying, it wont work, it just wont, please accept that.

Quote from: apefos on November 13, 2013, 11:43:19 AM
I also got another idea, maybe impossible, to implement a similar function from dng2hdr inside camera, so the camera would do the interpolation and iso merge before compression... this is the "dream"...

Custom, realtime image processing at 24fps is impossible. I don't even think a super high end computer could handle dual iso conversion + toning at 24fps, much less the measly ARM cpu inside these cameras. Plus, you'd be 'baking in' the curve/toning, since h264 is only 8 bit.

So maybe someday the manufacturers or ml will give us two H264 or H265 streams from adjacent pixels in the sensor recorded to the SD card simultaneously, so we can do the hdr merging in the post production.

Or these two streams could be in just one recorded file in top/bottom or side by side, just like 3d...

Also, if the next generation Canon dslr come with digic6 and 1080p 50p 60p, the hdr video with alternate iso in subsequent frames will be better to use, recording h264 or mp4 in 1080p 50p or 60p to get the 25p or 30p overexposed frames (shadows) without optical flow, this would be enough for good quality low movement images, 16 fstops dr, 11 from the custom picture style + 5 from the hdr video...

in narrative or documentary 1080p raw video is difficult for me to use due to the files are so large and no sound in camera...

Quote from: apefos on November 13, 2013, 11:43:19 AM
I understand the compression problem, it could destroy the separation from the lines making different iso useless, but even knowing this I would like to try...

Take the embedded JPEG preview from a dual ISO CR2 and get something useful out of it. Post the results, I'm curious how far you can get without having access to raw data.

Hmmm, aliasing isn't really affected by the compression and iirc the blurring comes from the resizing stages.

This might just be a way to get 30fps HDR from 1080 h264.

A1ex the raw embedded JPEG won't have temporal compression. I'll try shooting an interlace video at different sizes to see what is retained.

If interlaced video (60i and 50i) can be recorded by camcorders and consumer cameras in 17Mbps it is because the lines separation can be retained... if we use 1.3x CBR maybe it will be enough to keep the lines separation in a enough result, if this can shoot in 1080p and interpolated and merged in post and then downscaled to 720p or even to 640x360p for smartphone view it will be great,

Many thanks for testing the idea... If it can give an average result will help lots of people... no need to be 100% perfect...

If you need a beta tester just allow me to download a version of dual iso module enabled to work in h264... I can test in 600D/t3i

thanks and good luck in the tests!!!

I think all you'd have to do is go to line ~322

change:
int raw_mv = mv && lv && raw_lv_is_enabled();

to

int raw_mv = mv && lv //&& raw_lv_is_enabled();

Quick look, I didn't see any other checks/blocks. EOSM can be tricked from photo mode -> movie mode without raw because of the constant LV or it could not too long ago.

Now is this worth it? That I don't know.

For cameras with poor raw performance like my 550d  :'( this would mean cinemascope hdr files. Eliminating temporal errors from 720 50/60p but potential vertical aliasing errors. Not sure how registration of images would fare after merging or scaling?

Would be neat to test, as I just cant get useful raw from sd card rebel.

Hi 1%,

It seems to be so easy to modify the dual iso module to allow h264 recording... problem is I do not know how to edit these files. Could you please do this change and allow us to download the dual iso module for h264 from your bitbucket? I have the 600D/T3i running your NewMem build so I can test it.

Many thanks!

I can simulate these files as combed footage, I guess the real question will be the effect of interpolation at the edges of high contrast.

i do not know if this is in the dual iso module or in the autoexec.bin... i would like to do this change to enable dual iso recording in h264 for the 600d/t3i, how can I open the file, change and save? see:

go to line ~322

change:
int raw_mv = mv && lv && raw_lv_is_enabled();

to:
int raw_mv = mv && lv //&& raw_lv_is_enabled();

I don't think dual ISO in h264 could possibly work, first the cpu would not handle dual read out from the sensor and compressing to h264, secondly I believe the compression process would ruin any chance of recovery and last I do not see a way for developing the dual ISO frames out of the .mov file...

@apefos: please do your homework first (http://www.magiclantern.fm/forum/index.php?topic=9145.msg88699#msg88699). After you will get reasonably good results, post them and I'll enable it for video.

FYI: recovering the image from YUV (be it compressed or not) is one or two orders of magnitude more difficult than from raw data (linear and not debayered). I wanted you to see this with your own eyes, but you didn't seem to get the message.

@a1ex: I think now I understood the message, now I am doing the homework! Thanks.

I did a try now with the 600D with dual iso module enabled and raw rec 1728x992 enabled and I can shoot a JPG large fine in dual iso and the photo retains the lines... great! I just changed the Pic Quality to Large Fine only to allow camera to save the jpg to the card.

now it is night here, so tomorrow morning I will shoot some jpg photos to do a better perceive in the lines retention and upload to show the results.

Tomorrow I can also try to separate the two fields in the jpg photo using a software in computer, interpolate the lines and merge with enfuse to see what happens...

I have good news. It works!

I took a picture in JPG Small Fine with dual iso and raw rec modules enabled, Pic Quality was set to Small Fine.

I deinterlaced and interpolated the same jpg file two times, one for iso 100 and one for iso 800 and then I merged it with enfuse gui in default settings. To separate the isos you just need to choose even or odd field in the deinterlace moment.

the workflow for video will be simple, export an image sequence from the mov h264 file, deinterlace and interpolate each image two times, one for low iso and one for high iso, enfuse each pair with enfuse gui. (all can be done in batch processing)

Probably a simple filter can be created for Virtual Dub to do this task.

see the original dual iso jpg, the two isos deinterlaced and interpolated jpg and the enfused result jpg: (can I try it in h264 video?) thanks!

(http://www.apefos.com/dualiso/1_dualiso.jpg)

(http://www.apefos.com/dualiso/1_100.jpg)

(http://www.apefos.com/dualiso/1_800.jpg)

(http://www.apefos.com/dualiso/1_enfused.jpg)

Ooh nice result! I wonder if it's possible to stick this into the h264 encoder? a1ex is there enough processing power in a Rebel like the 550D?

Quote from: apefos on November 17, 2013, 07:13:00 AM
I took a picture in JPG Small Fine with dual iso and raw rec modules enabled, Pic Quality was set to Small Fine.

Interesting, so Canon's downsampling algorithm did half of the job here. The thing is, with video you have 2 lines at iso 100 and 2 at iso 1600. Can you try to blend the image at full resolution?

I'm interested in this for in-camera preview (not final output), but I'm having big trouble with color casts caused by demosaicing. Just compare the two sub-images at low ISO and the two sub-images at high ISO (they have very different hues). I'm not sure how to solve it.

Let's go on...

I took a look in the Large Fine JPG in the computer and yes, each iso uses TWO lines. So this is impossible to separate using deinterlace... So I did a 50% resize in the image (downscale) to discard half of the lines and the image changed to ONE line per iso as was expected and the deinterlace+interpolation works...

about video: I recorded a RAW video in the 600D using 1728x992 @ 8 fps with dual iso enabled. The DNG sequence in the timeline shows TWO lines per iso, so it will need a downscale to 50% size to make deinterlace works. I can render the DNG sequence into a H264 video file, and then export a jpg sequence from it  to test if the compression will retain the lines separation, but before it I have a question:

why using two lines per iso instead of just one in the dual iso video? this would make sense for interlaced footage, but for progressive footage one line per iso would be enough... maybe the reason is to respect the bayer pattern? because bayer pattern is GRGRGR and next line is BGBGBGBG. is this the reason or the reason is just to get a better separation? Maybe in the dual iso h264 video we can use one line per iso because the h264 video is debayered in camera just like the jpg images are... one line per iso would introduce less aliasing in the final result and no need a 50% downscale before doing the deinterlace... share your thoughts...

about color cast in sub-images: it is normal issue due to when you change brightness the perceive of saturation changes. The saturation level is the same in the two sub-images, but less brightness makes the eye to feel there is more saturation and more brightness in the other image makes the eye to perceive there is less saturation. But saturation level is the same and things become ok in the merged image. The look of the low brightness image tends to me more red and the look of the high brightness image tends to be more green, but in the merged image everything becomes ok. No need to worry about this for the h264 dual iso video, after merging the final result will be ok. If a merged preview could be enabled in camera probably it would be ok also...

if a merged preview could be enabled in camera maybe the camera could record it into a h264 video!!! but there will be enough processing power to do it in 1920x1080 @24fps ? And using two lines per iso a 50% downscale would be a must before deinterlace+interpolate+merge, but using one line per iso would not need the 50% downscale... or another algorithm for deinterlace would be needed, probably the implemented deinterlace method in the CR2HDR.exe is already doing the deinterlace for two lines per iso or is it doing a 50% downscale?...

More about preview in camera: when looking at the dual iso in live view, I perceived that the high iso prevails over the low iso image, maybe due to more light on it, and I cannot judge the exposure for the low iso. I need to disable the dual iso module to see each iso and find the better iso combination before enablind the dual iso for recording. this way I can get great exposue for the low and high iso lines, it is impossible to set the exposure with dual iso enabled. Also, the white balance in raw recording is wrong at the moment of recording, colors need to be tweaked in ACR when importing the DNG sequence to timeline. Maybe the color cast in dual iso preview is just because the raw recording cannot show correct colors in live view, I always see some magenta cast when previewing dual iso in the lcd. I think this is not a big problem, I can deal with it.

password: diuhjc

yes! making late night brainstorming possible! :)

@apefos, have you read and understood this (esp. section 5):

http://acoutts.com/a1ex/dual_iso.pdf

Yes, I did a read in the dual iso pdf right now

It says exactly what I was guessing in my previos post, dual iso uses two lines to get red and blue information for each iso considering the bayer patern desing: line1= RGRGRG, line2=GBGBGB

The pdf paper does not say one line per iso is impossible, it just say: "good luck interpolating them" and I would like to try my luck!

For h264 recording the camera will do the debayer process before encoding to H264, so we have a chance for the one line per iso to work. The interlaced television video uses one line per field, so one line separation is possible. also in the tests I did in the video above proves that H264 and JPG can retain information in one line per iso.

As I said in the video, we can work in a second dual iso module designed for h264 and leave the current dual iso module just for raw, this way we will not disturb the raw recording in dual iso, we will develop a second experimental and independent module for h264 (dual_iso_raw.mo & dual_iso_h264.mo)

if one line per iso works it will be just great, if it does not work all we need to do is to go back to two lines per iso. why not to try? let's do a test in a module specific for h264 with one line separation and see what happens...

"I want to believe."

(http://www.famouspictures.org/wp-content/uploads/2013/05/I_want_to_believe5.jpg)

Quote from: apefos on November 18, 2013, 06:44:28 PM
Yes, I did a read in the dual iso pdf right now

It says exactly what I was guessing in my previos post, dual iso uses two lines to get red and blue information for each iso considering the bayer patern desing: line1= RGRGRG, line2=GBGBGB

The pdf paper does not say one line per iso is impossible, it just say: "good luck interpolating them" and I would like to try my luck!

I don't think you fully understand how deybayering (demosaicaing) works or you would understand why having only one line is impossible for this (esp. when you have no control over the demosaicaing algorithm - it's being done by the camera).  Think about it: your upper iso is going to only contain green and red information and the lower iso is only going to contain green and blue information (or vice versa). How are you going to make anything useful out of that? You'd have either no red or no blue information in your shadows and the same would be true of the highligts.

Plus, you do realize that the way you are currently doing this, you are sacrificing 75% vertical resolution and gaining very little in terms of dynamic range (from your sample video, I saw pretty much no improvement in dynamic range, simply a 75% reduction in resolution). The way cr2hdr works, you retain full resolution in the mid-tones and only sacrifice 50% resolution in the highlights and shadows. You need to understand how that works, and implement it on 8-bit, nonlinear data (probably almost impossible).

Quote from: apefos on November 18, 2013, 06:44:28 PM
also in the tests I did in the video above proves that H264 and JPG can retain information in one line per iso.

No, it only proves that the particular H264 compression you used in post can retain this information, not that the compression (and more importantly, other image processing such as the slight upscale to 1080p) applied by the camera would retain it.

different opinons and suppositions are normal... mainly when things are not proven yet in the real world... I am the kind of person that does not give up until I see things proven in the real world tests, no matter what people says. we are not loosing anything doing this... and we are loosing more time talking than testing...

the interlaced footage 60i and 50i from dslr and camcorders uses one line per filed and it works. why the one iso per line would not work? it is the same principle. let's see how the camera will demosaic and debayer the sensor with one line per iso, we cannot say things before seeing it...

using deinterlace+interpolation in one line per iso video will turn 1920x1080 into 1920x540 for each iso and it will interpolate pretty well. if we use two lines we would need a special software for deintercale images considering two lines to avoid the 50% downscale. But the best will be to see what happens recording one line per iso before to worry about how to deinterlace two lines per iso images...

@a1ex , @1% , I did the home work, and i did pretty well, so can you enable the h264 recording in the dual iso module and also enable two versions, one version with two lines per iso and other version with one line per iso? this way I can test it and we will se the real world results. you can create these two modules separated from the module for raw (dual_iso_h264_oneline.mo and dual_iso_h264_twolines.mo) it deserves a try, only a real world test will give us the real results, all talking is just suppositions, we need to see what happens in the camera and in the computer.

if you preffer I can do the tests in private videos and not share the module, send me a pm, or I can do it public if there is no problem.

thanks

Quote from: apefos on November 18, 2013, 08:45:03 PM
different opinons and suppositions are normal... mainly when things are not proven yet in the real world...

the burden of proof is on you to prove it is feasible, not on us to prove to you that it isn't

Quote from: apefos on November 18, 2013, 08:45:03 PM
the interlaced footage 60i and 50i from dslr and camcorders uses one line per filed and it works. why the one iso per line would not work?

you clearly still don't understand a bayer array or anything I said: http://en.wikipedia.org/wiki/Color_filter_array

Quote from: apefos on November 18, 2013, 08:45:03 PM
it is the same principle.

no it's not, dual iso is not the same as frame interlacing, they are extremely different things

Quote from: apefos on November 18, 2013, 08:45:03 PM
let's see how the camera will demosaic and debayer the sensor with one line per iso, we cannot say things before seeing it...

yes we can if we know enough about how the sensor works:

If you make every other line a different ISO, either all the blue sensels or all the red sensels will be at the same ISO and there will be none at your other ISO

Example:
ISO100 RGRGRGRG
ISO800 GBGBGBGB
ISO100 RGRGRGRG
ISO800 GBGBGBGB
ISO100 RGRGRGRG
ISO800 GBGBGBGB

a1ex spells this out plainly in the pdf, in a section you quoted, but clearly didn't understand fully. "good luck interpolating that" is sort of sarcasm, he really means its impossible to interpolate that. Plus, you don't have any control of the interpolation, the camera is going to be doing it according to it's own hardwired demosaicing algorithm that is not expecting different ISOs, it will be completely wrong.

Quote from: apefos on November 18, 2013, 08:45:03 PM
@a1ex , @1% , I did the home work, and i did pretty well, so can you enable the h264 recording in the dual iso module and also enable two versions, one version with two lines per iso and other version with one line per iso? this way I can test it and we will se the real world results. you can create these two modules separated from the module for raw (dual_iso_h264_oneline.mo and dual_iso_h264_twolines.mo) it deserves a try, only a real world test will give us the real results, all talking is just suppositions, we need to see what happens in the camera and in the computer.

1% has given you the exact code change you need to do to make it work (except he left out a semicolon), why don't you just do it yourself? (see here to get started: http://www.magiclantern.fm/forum/index.php?topic=991.0)

I'm not saying this is totally impossible, but IMO it will be very hard and not worth the effort. You might manage to get back to the 14-bit dynamic range of the original RAW, but you are going to pay a penalty in resolution, moire, and aliasing that will not make it worth it.

Are you playing the devil's advocate? or you just do not have the inovative spirit? The inovative spirit does not listen to the impossible, it prefers to fail doing it, because doing it allow a chance for success or to learn another way to reach the success. you need to watch the JOB movie to try to implement some inovative spirit on you.

I still believe one line per iso is possible because the camera algorithm uses the surrounding pixels to reconstruct the hole image. in raw the one line per iso could be a different history, but for h264 we have a chance: maybe the camera debayer algotihm can reconstruct the rgb data for all the pixels and all the image even with one line per iso, let's give a try to the camera debayer algorithm using one line per iso. if it fails we just need to go back for two lines per iso, it is so simple to try...

I just do not understand why people keep saying "impossible, impossible" without just giving it a try... just trusting in theory. somethimes teory can be surpassed, I believe the camera debayer algorithm can surpass this teory. If you want do to something you just need to close your eyes and ears to people who say impossible, it is better to fail trying to do... nobody will die doing this... and the cameras will not explode...

Unfortunately I do not know how to compile and do not have time to learn. I did what I could, now it is up to the developers to implement it and allow us to test. I think it deserves a try in one line per iso and in two lines per iso.

I will stop posting for a while... I have work to do here and I think it is also time for stop talking and allow  the developers to work on it.

Quote from: dmilligan on November 18, 2013, 11:09:31 PM
...you are going to pay a penalty in resolution, moire, and aliasing that will not make it worth it.

Exactly ! 

Quote from: apefos on November 19, 2013, 12:20:12 AM
... now it is up to the developers to implement it and allow us to test. I think it deserves a try in one line per iso and in two lines per iso.

... I have work to do here and I think it is also time for stop talking and allow  the developers to work on it.

:o

Where do these people come from?

It seems I found a bug in dual iso. Sometimes in 600D T3i in 1728x992 and in 960x544 the recorded RAW video in Dual Iso shows moving lines. the lines scroll down, I called it waterfalling behavior. See the video: (password = diwfb)

Not a bug, cr2dng can handle it (which lines are which are automatically determined by the algorithm)

Interesting, so it is safe for RAW recording! But for H264 recording maybe it could be a problem because it changes the lines position for deinterlace...

It seems I found another bug, I did some try to drag the DNG sequence over the CR2HDR but I got this screen and nothing happens... (using 600D T3i) see:

(http://www.apefos.com/dualiso/bug1.jpg)

you need to install dcraw

thanks!

the dcraw and the exif are in the same folder of cr2hrd now. it works, but there is a line which says:

black subtract didn't work

and the reconstructed images are underexposed, see the text: (I found this: "After postprocessing, you will get a DNG that looks like a dark ISO 100 shot, but you can bring the exposure back up and be delighted by how little noise is present in those recovered shadows.") so it seems to be working, but there are lots of magenta or cian hot pixels...

(http://www.apefos.com/dualiso/bug2.jpg)

I did more tests and in 1280x720 raw recording in dual iso the waterfalling problem did not happen yet. Sometimes it happens in 1728x992 and in 960x544, It seems to be an intermittent problem, it comes and goes...

For Raw dual iso, as said in previous post, the merging algorithm can deal with this issue, but if h264 dual iso will be implemented this bug needs to be fixed for computer deinterlace and interpolation, or a special extracting program needs to be created.

For RAW recording I understood the need of two lines per iso, the two lines combo will have the red, green and blue information to allow the image reconstruction for each iso.

But for h264 dual iso, probably the camera debayer algorithm can reconstruct the image using just one line per iso, because this is the nature of the camera debayer algorithm, it uses the surrounding pixels to reconstruct each pixel from the bayer pattern. In the interlaced footage from camcorders with 1920x1080 pixels sensors the even and ood fields differs a lot from each other in moving images and the camera can reconstruct it and no problem. also there are lots of light changes in images and the camera debayer algorithm always do a great job. just remember the canon hv20 camcorder. it is a 1920x1080 sensor and records 24p and 60i pretty good, no moire and no aliasing.

These are the reasons I strongly encourage the developers to try one line per iso in dual iso h264 recording. maybe it can surprise us with great results. and the workflow is easy to do in batch processing in computer. the video I did proves the lines separation can be retained.

if we can get two images with 1920x540 for each iso, the interpolation will be pretty good, and the hdr video will shine. there is also the instant hd and blow up plugins whic can do this interpolation without aliasing. if one line per iso in dual iso h264 works it will be revolutionary... no need lots of cards, the inexpensive Rebels will do it at 1920x1080, sound in camera... very small or no aliasing...

I do not know how to compile and it is hard for me to learn... I hope the devs give it a try...

sorry for lots of talk about this feature, but it is very promissing and I am really interested on it

thanks!

What if you could record to an atomos ninja at a different ISO while simultaneously recording h.264?  :o

I think the external recorder can be good idea to allow less compression in recorded video and a cleaner result, but for the low budget people the main goal is to record in h264 in the memory card. After doing the test in the video, I believe the h264 recording will be fine to retain the lines. But first, the main challenge is to test if the camera debayer algorithm can reconstruct the image when using one line per iso, and send a good even/odd fields with the different isos in a reconstructed image  to h264 recording or to the external recorder. I believe yes, but it needs real world tests.

Quote from: apefos on November 21, 2013, 01:01:22 AM
But for h264 dual iso, probably the camera debayer algorithm can reconstruct the image using just one line per iso, because this is the nature of the camera debayer algorithm, it uses the surrounding pixels to reconstruct each pixel from the bayer pattern. In the interlaced footage from camcorders with 1920x1080 pixels sensors the even and ood fields differs a lot from each other in moving images and the camera can reconstruct it and no problem. also there are lots of light changes in images and the camera debayer algorithm always do a great job. just remember the canon hv20 camcorder. it is a 1920x1080 sensor and records 24p and 60i pretty good, no moire and no aliasing.

Quote from: dmilligan on November 18, 2013, 11:09:31 PM
If you make every other line a different ISO, either all the blue sensels or all the red sensels will be at the same ISO and there will be none at your other ISO

Example:
ISO100 RGRGRGRG
ISO800 GBGBGBGB
ISO100 RGRGRGRG
ISO800 GBGBGBGB
ISO100 RGRGRGRG
ISO800 GBGBGBGB

a1ex spells this out plainly in the pdf, in a section you quoted, but clearly didn't understand fully. "good luck interpolating that" is sort of sarcasm, he really means its impossible to interpolate that. Plus, you don't have any control of the interpolation, the camera is going to be doing it according to it's own hardwired demosaicing algorithm that is not expecting different ISOs, it will be completely wrong.

(http://2.bp.blogspot.com/_H_QQWfUIxFY/TCfYe8WdzuI/AAAAAAAABDw/zEQBVIltjlo/s400/Tom%C3%A9.jpg)

@apefos: "Doubting" Thomas, right? Clever. @dmilligan and others: maybe it's best to stop responding? You seem to be just encouraging him  ;) Cheers!

ok, guys, I give up! I learned something in my life: "I agree that we disagree" (about the need of testing it). I was just hoping and wondering that h264 could be different from raw and could handle one line per iso with the internal camera debayer algorithm, maybe someday I learn to compile...

You don't need to learn to compile for this, what you need to do is learn about the process of debayering and how it works. Once you understand that and understand that the dev's don't have any control over the camera's internal debayerer you will see why single line iso's won't work.

Ok, let's forget about one line per iso...

Can I just ask for enable the dual iso recording in h264? (just enable and keep the two lines per iso)

a1ex told me he would enable it after my homework, and I did the homework in photo and video...

Quote from: a1ex on November 17, 2013, 01:00:24 AM
@apefos: please do your homework first. After you will get reasonably good results, post them and I'll enable it for video.

thanks!

Quote from: apefos on November 21, 2013, 06:38:13 PM
Can I just ask for enable the dual iso recording in h264? (just enable and keep the two lines per iso)

https://bitbucket.org/mk11174/magic-lantern/downloads/DUAL_ISO.MO

thanks, but it does not work in the 600D T3i, in the modules loading page, in camera lcd, I get an error message "Err" in front of it.

Can you please download and enable the h264 in this module: (this one is working in 600d T3i)

this working version for 600D T3i is from the latest NewMem build from 1%, see:

https://bitbucket.org/OtherOnePercent/tragic-lantern-2.0/downloads

Quote from: apefos on November 22, 2013, 01:51:08 AM
thanks, but it does not work in the 600D T3i, in the modules loading page, in camera lcd, I get an error message "Err" in front of it.

Can you please download and enable the h264 in this module: (this one is working in 600d T3i)

http://www.apefos.com/dualiso/dual_iso.mo (http://www.apefos.com/dualiso/dual_iso.mo)

this working version for 600D T3i is from the latest NewMem build from 1%, see:

https://bitbucket.org/OtherOnePercent/tragic-lantern-2.0/downloads

Use it with nightly unified, it is because you are using TL build which is fine, but I compiled with latest unified so if you get the nightly bins it will work.

See if this one works with TL, I compiled with TL6D works on my 600D, and the other one I uploaded works as well when I use the ML version since I compiled from the ML unified.

"Err" again...

I do not want to move out of TL... TL is working pretty fine in 600D

Maybe it will be better we ask for 1% help...

(I deleted the dual iso module from my site because the right place for downloading it is from the bitbucket)

Quote from: apefos on November 22, 2013, 03:10:02 AM
"Err" again...

I do not want to move out of TL... TL is working pretty fine in 600D

Maybe it will be better we ask for 1% help...

TL6D is tragic lantern, I dont have any issues with it on my 550d and 600d, u say you just want to test the dual iso with h.264, so this is giving you the chance to test it, and it is recording the dual iso just fine, just can't do anything with it to merge the iso's together obviously like you can with the DNG's from the RAW files.

If you just want to test it, just grab the unified autoexec.bin from the nightly builds and test it.

1% already helped, he told you what to change in the code, I read that you could not compile, so I made the change and compiled for you, so you are ready for testing.

Sorry, but I will give up testing...

The nightly builds territory is not for me... It is not so simple to install and make it to work. And the advice "at your own risk" scares me...

If someday the developers come with a good working solution, like the downloads I did from 1% TL, I will install it...

Many thanks, but I will stop for now... maybe I am too hungry for dynamic range... and maybe it will be better to record dual iso raw because it is safe to do...

The h264 idea is great, but I realized that testing it in early stages is not for me... I did the contribution I could do, but developing and testing in early stages is not for me... sorry!

Tragic Lantern is actually more dangerous than ML nightly, see here: (http://www.magiclantern.fm/forum/index.php?topic=3904.msg78084#msg78084).

Quote from: a1ex on September 23, 2013, 04:02:20 PM
Conclusion: personally I'm afraid to run Tragic Lantern on any of my cameras. Sure, I don't remember anyone bricking his camera with TL code, but I've learned about some dangerous things the hard way, by bricking my own cameras (and then learning how unbricking them). Of course, you should not trust me blindly, you should review the code on your own (even the code from the main repo).

Sorry if I sound like bashing or underestimating the contributions from 1%. I've just tried to do an objective review of Tragic Lantern, especially regarding code safety, and I've tried to back every argument with a link or a code snippet. These are the main reasons TL code didn't get merged into main repo; I've pointed them out many times, but the issues were not solved, so a little reminder shouldn't hurt.

The only reason TL doesn't warn you "at your own risk" is that simply 1% does not feel he needs to warn you. Personally, I would also be afraid to run TL. 1% has taken out many of the safety checks a1ex spent significant time putting in place. He also reenabled several features that a1ex considered to potentially dangerous to be released. a1ex has very considerable regard to protect user safety, 1% has very little.

I can't believe somebody actually did this for you after you moaned and groaned for it, and then you're not even willing to actually test it.

All you have to do is download the nightly .zip, extract it and put it on your card.

I like to be on the bleeding edge. Problem is I have some important work to do with the camera next days, so I cannot allow myself the risk of run into any problems now. January will be a good moment to test because the important work I have to do with the camera will be done. Hope you understand!

 I pitty your clients if you do this for a living. I will try it as I requested it in the first place.
I might need some instructions as I'm not very geeked up on ML...I just use stable releases and a handfull of features.

Quote from: apefos on November 22, 2013, 04:02:56 AM
If someday the developers come with a good working solution, like the downloads I did from 1% TL, I will install it...

try this one for TL 2.0 only
https://bitbucket.org/mk11174/magic-lantern/downloads/dual_iso_h264.zip

ok, I got everything to load up on my 550d, but to tell you the trouth I don`t know if it`s working or not. It still says that it only works in raw, but I was able to set everything and record in h.264. Looking at the footage I can`t say if it works or not...do I have to run it thru some software first?

Quote from: jagnje on November 22, 2013, 03:59:46 PM
ok, I got everything to load up on my 550d, but to tell you the trouth I don`t know if it`s working or not. It still says that it only works in raw, but I was able to set everything and record in h.264. Looking at the footage I can`t say if it works or not...do I have to run it thru some software first?

That is just a menu warning, I did not bother changing the menu info since he was only wanting it for testing. It will still record the dual ISO with your normal h.264 MOV that the camera normally records at.

The code just makes it work whether RAW is on or not.

Just turn it on and set your Canon ISO to 100 and set Dual ISO to something higher and you should notice the interlaced lines in the LCD and when you record like normal it will record what you see in the LCD.

Now you will have an MOV with interlaced effect, but you can't do anything with it because the CR2HDR is for the Raw DNG files so you can't merge the ISO's together like u can with the Raw files. I don't know what the tester had in mind to do with the interlaced MOV clips, just figured I would help him out so he can see for himself that there is nothing much that can be done with enabling it. Some people just need to try for themselves to understand it.

Don`t know I guess I`m doing something wrong...I don`t get the interlaced look. Maybe someone more capable should try it :)

or maybe it just doesn't work and the demosaicing, upscaling, and h264 just smear everything out (which is what I would expect)

does it look any different at all from when you have it enabled/disabled? does it look any different if you change the secondary ISO?

Quote from: dmilligan on November 22, 2013, 05:13:46 PM
or maybe it just doesn't work and the demosaicing, upscaling, and h264 just smear everything out (which is what I would expect)

does it look any different at all from when you have it enabled/disabled? does it look any different if you change the secondary ISO?

I see it and also recorded it, I have an interlaced MOV. Are you using the first Dual_ISO link I gave?

http://www.mediafire.com/download/a3vp5awgqwiqzb1/MVI_8672.MOV (http://www.mediafire.com/download/a3vp5awgqwiqzb1/MVI_8672.MOV)

I used this https://bitbucket.org/mk11174/magic-lantern/downloads/DUAL_ISO.MO
And placed it in the latest nightly build...I may have screwed something up, because I just replaced the regular ML files with the nightly ones...dunno. I can activate it, record in h.264 and all, but it`s just like normal video.
I`m off for the weekend, so I`l try some more next week. If anyone else comes up with something usefull share it here :)
Have a nice weekend everyone.

This might be useful if we could record at 1080 60i. For all that we can just use hdr video. I might test it out anyway though, can't hurt to try.

Quote from: jagnje on November 22, 2013, 06:32:05 PM
I used this https://bitbucket.org/mk11174/magic-lantern/downloads/DUAL_ISO.MO
And placed it in the latest nightly build...I may have screwed something up, because I just replaced the regular ML files with the nightly ones...dunno. I can activate it, record in h.264 and all, but it`s just like normal video.

Try with the full compile, bin and modules right from my card for the 550D.
https://bitbucket.org/mk11174/magic-lantern/downloads/ML_550D_Dual_ISO_H264_Nov_22_2013.zip (https://bitbucket.org/mk11174/magic-lantern/downloads/ML_550D_Dual_ISO_H264_Nov_22_2013.zip)

Here is 600D full compile.
https://bitbucket.org/mk11174/magic-lantern/downloads/ML_600D_Dual_ISO_H264_Nov_22_2013.zip (https://bitbucket.org/mk11174/magic-lantern/downloads/ML_600D_Dual_ISO_H264_Nov_22_2013.zip)

Yeah it works, the .mov even played back in camera. Only thing I can think to convert it is to render out the video to a cinemaDNG sequence and see if CR2HDR will detect them. Who knows...

Oh Guys!... I could not resist... I confess I was freaking afraid and feeling irresponsible loading this to camera. But then I realize the problem was not the fear, the problem was being a low budget guy with no money to buy another camera...

And then I thought... fuck the camera, if it bricks I can hire someone free lancer for my work... I am realy a low budget bleeding edge guy... And I jumped from the bridge...

I downloaded and loaded it to camera... and "ufs"...finger in the on/off lever...  turned it on... lots of error messages... but went on... and I found the ettr module needs to be disabled to avoid the errors.

So I downloaded the last 600D nightly and inserted the dual_iso (h264) inside it replacing the other... much better and no error messages. (600D 22/11/2013) The layout in this build is great, but temperature is reaching 60 Celius so maybe better go back for other build...

recording is nice, dual iso in h264 works!!!

It worth my home work and my "moaned and groaned"

I think my moving out from the topic for a while was good for other people to come and participate also...

now it is time for the workflow...

Bleeding Edge is for the Real Man!  :o  ;D  ;)

Guys, now we can record it in H264, so why keep the same still sequence workflow? It is time comsuming...

Let's think about a deinterlace and interpolate plugin for VirtualDub or even for Premiere or After Effects...

We need a deinterlace+interpolate plugin wich can consider two lines (pairs) instead of one line. It is the same principle, just considering two lines. So we can use the same dual h264 video to export two extracted and reconstructed videos...

We also need a hdr plugin for VirtualDub or Premiere / After effects. Something like Enfuse GUI, but for use in two video streams...

Better if we could have a plugin which could do everything in just one pass, extract the two streams and merge them delivering the final result in just one pass processing... this is what we need...

Let's think to avoid still image sequences...

Don't forget that the 600D also has 3x crop for h264 video..... Hence, no line skipping.  ;)

Yes 3x crop, and also the VAF-Txi filter!

More tests and:

Until now I did not see any, I mean ANY magenta dots!!! (no one, nada)

I can do 35fps override for slow motion in fullhd!!!

It seems I found the problem of waterfalling behavior: in 35fps it gives me the problem, but I tweaked it for a multiple of 0.999 (to match 23.976) and I found 34.965 was the number, and then "voilá" no more waterfalling in lines!!! (I did just one test in this, needs confirmation)

The lines separation is perfect even in 100/3200 dual iso!!! (I am using 1.3x CBR)

All this in glorious 1920x1080p fullhd in a low budget Rebel 600D T3i !!!

In camera LCD the preview is magenta cast, but in computer it is less magenta, maybe after merging the colors gets better, or will need color correction (WB was correct in camera)

Wow, so nice!!!

Problem is this last build is giving me 67 celsius RED warning... so I need to find a build without overheating...

about the workflow, maybe the people from these sites can do the "one pass" solution (deinterlace extraction, interpolation, merging):

http://www.19lights.com (ginger hdr, they work with EXR hdr files wich is great for tweaking in timeline)

http://www.guthspot.se/video/index.htm (deshaker and deinterlace filters for virtual dub, they work with great deinterlace solutions)

One thing I realized is:

after extraction (deinterlace) the image from the lower lines pair must be repositioned to match the position of the first group.

imagine the image reconstructed from the first lines pairs comparing to the image reconstructed from the second lines pairs. they will be two lines mismatched in height.

so, in the interpolation moment, the reconstructed lines must be below the original lines for the first image and above the original lines for the second image, this way they will match in height position.

I know you all hate the one line per iso idea, but why not give it a try? We have nothing to lose, and if it works, the workflow is already ready to go... deinterlace and interpolate in premiere, after, vegas or virtual dub and merge with enfuse gui. and also better resolution and less aliasing.. guys we have nothing to lose testing one line per iso... lets give it a try... (please don't ban me from the forum due to coming back with this idea   ;))

I just sent an email to ginger hdr support, hope they listen to me... imagine ginger hdr workflow for this... it would be a breeze...

(in the momen I sent the email to ginger the views in this topic was: (Read 1920 times). Yes, interesting coincidence!

https://www.dropbox.com/s/8w7p59t8jnhsr6h/MVI_6318.MOV

Here's a sample done on the 600D with 3x zoom.

Great, downloading right now to see your results!

Are you free of magenta dots (hot spots) in both 3x crop zoom and in default 1920x1080p no crop?

Yeah I believe so. I don't have the patience right now to try and process these, but feel free to go for it.

Great! I am free of hot pixels also! The only workflow I know to do at this moment is to discard half of the lines (50% height downscale) and do deinterlace + interpolation for each iso. This is not ideal, better than this would be to get a way to preserve all the lines and reconstruct the images interpolating them... so I did not try yet. It will be better we try to find someone professional to develop it... at this moment I am waiting an email reply from ginger...

I just uploaded an original 100/800 mov dual iso h264 video in 1920x1080 @23.976fps (3x crop mode disabled) (no vaf-txi filter) just the default 600D T3i camera. I got good average colors in this, used a 1000 watts halogen lamp lowered by a dimmer and 2800k manual wb.

https://www.dropbox.com/s/4kwykig7jim1rvo/MVI_1814.MOV (https://www.dropbox.com/s/4kwykig7jim1rvo/MVI_1814.MOV)

Can't believe, it is amazing, three persons, three cameras, three uploaded videos, all free of hotpixels and good lines separation! This is very promissing! Fingers crossed for we get a great workflow!

I DO NOT RECOMMEND THIS
You can actually record dual iso on h.264 without a modified .mo. I tried this a couple of months ago on my 5d mark 3. It goes like this
1 - set up your dual iso settings
1 - Prepare your raw rec to lowest setting 640x360 and then disable the raw rec module
2 - get into normal camera rec mode and start record in h.264
3 - go back into the ML raw rec while recording h.264 and start raw recording then hit rec again which will start the raw recording aswell on top of h.264 recording.
I stop the raw with the normal button and the h.264 recording by hitting menu button.

Not the most beautiful solution and AT YOUR OWN RISK, of course. If a developer like to delete this suggestion, feel free to do so. This is not anything I practice at all and only did it for fun.

Quote from: Danne on November 23, 2013, 09:34:42 AM
I DO NOT RECOMMEND THIS
You can actually record dual iso on h.264 without a modified .mo. I tried this a couple of months ago on my 5d mark 3. It goes like this
1 - set up your dual iso settings
1 - Prepare your raw rec to lowest setting 640x360 and then disable the raw rec module
2 - get into normal camera rec mode and start record in h.264
3 - go back into the ML raw rec while recording h.264 and start raw recording then hit rec again which will start the raw recording aswell on top of h.264 recording.
I stop the raw with the normal button and the h.264 recording by hitting menu button.

Not the most beautiful solution and AT YOUR OWN RISK, of course. If a developer like to delete this suggestion, feel free to do so. This is not anything I practice at all and only did it for fun.

please explain to us why you do not recommend

also, tell us the advantages of using your method

thanks

I am using the 2013/11/23 build for 600D.102 from Latest Build download page. (select your platform = 600D.102)

http://builds.magiclantern.fm/#/

to enable dual iso H264 recording, I replaced the dual_iso.mo with the one I downloaded from here:

https://bitbucket.org/mk11174/magic-lantern/downloads/ML_600D_Dual_ISO_H264_Nov_22_2013.zip

There is a temperature issue in the 2013/11/23 for 600D.102, the display shows 70 Celsius, and until now the developers do not know if this is overheating or a display problem. I recorded some clips and got no Canon simbol overheating warning and no shutdown. I compared the 2013/09/28 build and the temperature raised to 60 Celsius. Not a big difference, so I will keep using the latest build...

Quote from: apefos on November 23, 2013, 09:52:11 AM
please explain to us why you do not recommend

also, tell us the advantages of using your method

thanks

As I said, this is only something I tried for fun, I don,t now if it could mess with code when recording both h.264 and raw simultaneously. There are no advantages whatsoever. Good luck anyway with testing. I see there,s a modified raw.mo for h.264 now better stick to that

Huston, we have a problem... (and some interesting ideas for solutions)

Update_1: I did a look in the timeline with 600% zoom and the lines position (horizontal position) is always the same from the begining to the end of the recorded clips. Even better, in my camera the lines position is the same for all the clips including clips with different frame rate. All frame rates I recorded was a multiple of 0.999 (24 x 0.999 = 23.976) (30 x 0.999 = 29.97) (35 x 0.999 = 34.965) this seems to avoid the waterfalling behavior.

when looking at the image in 100% zoom (default size) in computer screen, the perceiving of lines separation is perfect, you just see the different isos perfectly.

but when zooming in to 400% or 800% zoom, you start to perceive the lines separation is not so perfect, and the separation random changes among two lines for each iso / two lines for one iso and three for the other / two lines for one iso and the subsequent line as some kind of a merge and then the other iso comes...

so, the workflow using 50% downscale in height to get one line per iso does not work. also extracting two images using two lines per iso maybe will not work... (I said maybe because i did not try). So probably we will need a special algorithm which could consider these situations and reconstruct the two separated images or instead of reconstruct the separated images it could do some kind of fusion and get the merged result without separating the images.

this algorithm needs to be build by an expert, and this seems to be the point this idea will stop forever... unless someone is willing to develop this algorithm... the algorithm needs to find which line is iso 100, wich line is iso 800 and which line is a merge between them to do the job (the merged lines would be an average iso 300 result? or a random iso, something between the two isos...)

Or the algorithm would need to separate only the lines which are in the correct low/high isos and discard the ununsable lines. and then reconstruct the images using the usefull lines (maybe half of the lines will be usefull in each frame and maybe the position of good lines will be the same among all the frames in each shoot.)

Discard lines would not be so good because it increases aliasing and lower the resolution. Better solution would be using all the lines, a smart algorith which could to the job using all information from the frames. The information is there... but this is a job for an expert in computer programming...

Another good idea for the algorithm is it try to reconstruct the two lines per iso pattern before extracting each iso, finding the merged lines and doing some kind of "lift or low" in the luminance value for the merged lines, to get the perfect two lines per iso image before deinterlace+interpolation. Maybe this is the easy solution for building the algorithm. The algorithm puts numbers in lines and consider (first image = lines 1+2/5+6/9+10) and (second image = lines 3+4/7+8/11+12). Then the algorithm find the darkest lines for the low iso group and the lightest lines for the high iso group. All other lines will be consider merged lines and would be calibrated lifting or lowering the luminance to match the other lines... After this the algorithm does the deinterlace+interpolation considering two lines per iso, for the first group it puts the interpolated lines below the original lines and for the second group it puts the interpolated lines above the original lines, this is to keep height alignment between the two images, and then the algorithm merges them! I believe this will works, we just need an expert in programming...

Also, instead of separating the line groups before "lift or low" the merged lines, a better idea could be finding the darkest and lightest lines, compares the lines around them and do the "lift or low" in a way to reconstruct the two lines per iso. Just changing the order of things... lift or low before separating groups instead of separating groups before lift or low. or even better, doing the lift or low for the merged lines considering a lines pattern mask with the two lines per iso desing... the expert in programming can decide and implement this...

Important things are: 1 - the information is there, 2 - we are free of hot pixels, 3 - the recording is stable and with sound, 4 - it seems the lines position (good and merged lines) are the same among the frames of each shoot, 5 - color cast can be solved in post or in the processing moment.

Then a crazy idea comes to my mind: Maybe one line per iso will be the way to get this merge between the two isos already done in camera. the one line per iso will never get lines separation, instead of lines separation it will merge everything in a mess or if we have luck in the result we want already from camera!!! (as I said: crazy idea!)

See these images, the first image is a 100% zoom (default size) to perceive that for the eyes the lines separation is good, and the second image a zoom in to show that the separation is random and shows merged lines (maybe it will keep the same random position and same merged/good lines among all frames in each shoot facilitating the algorithm's job):

(http://www.apefos.com/dualiso/dual_iso_h264_nozoom.jpg)

(http://www.apefos.com/dualiso/dual_iso_h264_zoom.jpg)

I updated the previous post with lots of new ideas for the algorithm, please read again

Important thing is we have ideas for the algorithm, the expert in computer programming will translate the ideas into the algorithm code, so if you have ideas for the algorithm, please share here...

I saw images in 600% zoom in timeline and the lines keep same horizontal position from begining to end of the clips and even same position in different clips and in clips with different frame rate in my 600D.

The two clips I downloaded from two other people shows lines in same position from begining to end of clips also, but lines position differs from one camera to another, not a problem for the algorithm.

The latest 2013/11/23 build for 600D.102 shows 70 Celsius, I compared with the 2013/09/28 build which shows 60 celsius, so maybe not a big difference... Only latest builds works with dual iso h264 recording.

Well guys, it seems my job is done... I know nothing about computer programming so developing the algorithm is not for me... :'(

this idea is now waiting for an expert in computer programming to make the algorithm to turn it into wonderfull HDR videos from cheap Rebel Canon DSLR cameras in glorious full hd 24p and even in 35p for slow motion. (is someone from magic lantern team willing to do?) :)

Many thanks and good by for now... 8)

Sunglasses off, I am back!  :)

There is a pattern! This makes things completely possible!

I tried the same technique used in the video I made earlier:

I will show four working steps from the same image, each image was extracted from each of the three cameras used in the h264 dual iso videos of this topic.

the working steps are:
Step A: pure image, just 400% zoom
Step B: the image with the height reduced by 50% to eliminate half of the lines and turn it into what would be a one line per iso, dual iso image
Step C : the even field deinterlaced with interpolation
Step D : the odd field deinterlaced with interpolation

Observing the step A, I realized that there is not a perfect separation among the two lines by iso as we would like to get, and we cannot understand how this separation was impaired, we just can see that some lines seem a mixture of different isos .

Observing the step B we can see that the lines which are a mixture of the different isos appear in a constant interval, ie, when the camera do the debayering and compressing, the mixture of isos in some lines happens in a constant interval. This means that we are encountering the beginning of a mathematical formula that can reconstitute these lines to their original luminance level, because everything indicates that the mixture of isos happens in some respect to a constant lines inerval and certainly the intensity range of the mixture will be the same when considering the same distance between lines.

Observing images of the steps C and D may establish that this really have the constant interval for the mixture luminance in lines and moreover we can also see that this variation occurs in a wave form, ie, I found that there is a frequency .

What the programmer of the algorithm need to do is discover this frequency and turn it into a mathematical formula to retrieve the correct luminance of each line of the image. Probably no need to separate the images into groups of different isos in the first moment, but to implement the function that removes the wave frequency in luminance variation caused by the camera debayering and compression, and thereafter, with the correct luminance in the reconstructed lines, the algorithm will can separate the two images with different isos.

As you can see in the pictures below the frequency of luminance variation is the same for all the three cameras, which proves that the algorithm will work on all cameras.

You can also notice that the frequency of luminance variation is the same in Steps C and D, only presenting an inverted wave, which would be expected because these images correspond to the even and odd fields respectively.

No need to worry about the deinterlaced and interpolated images shows the two isos in varying waveform, it is precisely this that the algorithm will correct .

This experimentation leads me to elaborate the theory that the camera debayer and compression can generate a frequency variation of the luminance of the lines in some waveform that could also be reconstituted in dual iso recording with one line per iso, suffice to discover the wave pattern frequency and turn it into a mathematical function.

Hope all this can help someone to develop the algorithm...

Scientific spirit is moved by curiosity and for not believing in the impossible. The scientist has a motivated spirit that never ends, the scientist is always thinking and taking/getting ideas from his mind. Scientist spirit does experiences, draws conclusions and elaborates theories, moves to a new, more enhanced experience, improved experiences turns to make a law theory. A scientific law is nothing more than a mathematical formula that has functional connection with reality, a mathematical formula, a function! And an algorithm may be composed of a number of functions.  :P

Was this a good homework? Do I deserve a try in one line per iso?

(images below are displayed with 400% zoom for better viewing of the lines, do not worry about the macroblocking , it is due to the 400% zoom )

(http://www.apefos.com/dualiso/camera1.jpg)

(http://www.apefos.com/dualiso/camera2.jpg)

(http://www.apefos.com/dualiso/camera3.jpg)

Another interesting approach would be to forget about lines and think about some kind of debayer algorithm.

after finding the wave pattern frequency to recover the luminance of each line, instead of recovering the lines luminance, this information could be used in conjunct with the luminance and color information of the surrounding pixels and surrounding lines to do a debayering instead of deinterlacing+interpolation+merging

this approach makes my curiosity about one line per iso more intriguing, because finding the wave pattern frequency for the luminance in dual iso h264 video with one line per iso could make possible to creat a much better debayer algorithm than usin two lines per iso...

wow, my mind is blooming...

I strongly believe that if someone becomes willing to develop this algorithm, to see the behavior of one line per iso will be mandatory to understand and develop the algorithm, no matter if the final working solution will be with one or two lines per iso...

instead of debayering this algorithm can be called "DeLinering"

I own a 5d mark 3 and atomos ninja 2 so I'm very curious about the potential of recording dual ISO video feed to the ninja and then processing.  Because it's uncompressed I wonder if we might have some really nice results.  Or is that impractical?

I think it is impractical, let me explain why:

Updated: maybe the folowing idea is also impractical due to we do not know if the h264 compression can retain enough information from each pixel, probably not...

I came back here now to talk about my next idea, and I believe it is the solution (if it can be implemented by the magic lantern team)

Please, follow this thoughts:

In the video I did compressing the DNG sequence into H264 I proved the lines separation can be retained by the codec. So a question was born in my mind: if the h264 codec can retain the lines separation why are we getting merged lines? simple answer: the problem comes from the debayer!!! when the camera does the debayer before compressing to h264 it hurts the lines separation, because the sensor debayer uses the information from surrounding pixels to reconstruct the hole image, and if a pixel is dark and the other is bright, the debayer will calculate an average result between them... so some lines comes merged, with a luminance between the two isos values.

so what is the MAGIC solution? simple! the solution is to implement a way to avoid the debayer algorithm in the camera and record the raw information compressed in h264 and in computer we will use a similar raw workflow, convert the h264 into DNG and do the same workflow used in raw.

and you can ask, so why not record in raw? because h264 allows full hd recording in the low budget cameras in 24fps, 30fps and even more.

what we need to do is to avoid the camera debayer algorithm and record the raw information compressed into h264

for me this idea makes perfect sense. does it makes sense to you all? it also makes sense for an external uncompressed recorder or lossless compressed external recorder.

would it be possible and easy to implement?

(in electronics this thing is called a "bypass")

we can try this in CBR 1.3x or even 1.8x or more if camera can handle.

please read the updated information in the beginning.

Not even 5D3 has enough processing power to compress raw.  Been discussed previously at length.

Quote from: RenatoPhoto on November 23, 2013, 09:31:48 PM
Not even 5D3 has enough processing power to compress raw.  Been discussed previously at length.

it is not raw compressed into raw, it is raw compressed into h264, the bayer pattern recorded into h264.

but I already updated my previous post because maybe the h264 cannot keep enouch information for each red, green and blue pixels...

The beginning of "DeLinering Algorithm" (or "DeWaving Algorithm")

The first idea to start developing the "DeLinering Algorithm" is a static algorithm trusting the wavelength and wave amplitude is a constant over all the frame, from the first to the last line... I think "DeWaving Algorithm" is a better name because this first attempt does not removes the lines, it reconstruct the lines. It is considered static because it takes into account that the wavelength and wave amplitude will allways be the same, and it does not find the first line, the user must reposition the first high iso line in the first line of the frame (the beginning of the first wave) moving the video up in the timeline a little bit. the amount of moving probably will allways be the same for each camera, (as we saw in previous post each camera keeps the lines position in all recorded clips)

Idea is:

1 - shot a dual iso h264 video pointing camera to a white or grey/gray flat wall/paper with perfect ilumination distribution in all the frame.

2 - zoom the image in timeline to perceive the amount of lines in one wavelength, (x lines), (if needed downscale 50% in height to help perceiving the waves)

3 - with a color picker find the luminance value for each line inside one wavelength

4 - calculate the amount of lift or low to the luminance for each line inside one wavelength to reconstruct the "two lines per iso structure" in the x lines wich forms the wavelength

5 - each line inside the wavelength will have a equation like this (my luminance + y% or my luminance - y%)

5 - create the algorithm with 1080 equations, one per line, repeating the wavelength equations group

if wavelength and wave amplitude is a constant this thing will work

I can do everything but not the step 5 because I do not know computer programming...

http://www.en.wikipedia.org/wiki/Wave (http://www.en.wikipedia.org/wiki/Wave)

Updated: looking to the images in my post showing the three cameras, it seems the wavelength and wave amplitude are not constant, ie, it seems luminance variations are random... but it needs the flat wall test to be sure.

Hi guys, I have great news!

I did the grey wall test and I found the wave!

And the best news: wavelength and wave amplitude are both constant! Not average constant, but perfectly constant!

I will try an attempt to write the algorithm! It seems I can do the step 5 from my last post, only thing I cannot do is to put the functions into a computer compiled file, but after everything is written, this step 6 will be easy and fast for someone else to do.

I will show images to demonstrate how things works.

;D  :)  ;)

But remember: there are chances for things to work, but nothing is proven in real world yet, so everything can fails!!!!!  :o

Good luck with this, would love to see it come to fruition.

THAT'S GREAT F*CKING NEWS!

Thanks guys, I will do my best!

Today is Sunday, and after lots of brainstorming, I think I deserve some rest!

As I said before I have some important work to do next days, so I will use the free time to go on with the project.

I got new ideas about the wave amplitude, needs tests...

I will keep you posted!

I decided to finish the work this Sunday to free my mind for my next job... so here it is:

I decided to created the algorithm considering the isos 100/800 combo (3 fstops difference). So it can also be 80/640, 160/1250 and so on... This is due to Magic Lantern advice says it is a safe maximum difference to avoid aliasing when merging the isos. Also I think it will be good idea to avoid noise increase so much, so 3 fstops difference does not increase the high iso so much.

It is possible to implement all isos difference in the same algorithm (100/200, 100/400, 100/800, 100/1600, 100/3200), see in the end of this topic how to do.

The isos will be called hi and lo (high and low). (this remembers me the A-HA band: "hunting high and low, ahhhh ahh ahhh...")

I did some tests with less and more light shooting the grey wall to perceive the wave amplitude better. In these tests I found when the highlight gets too high the results was better keeping the values a little below the maximum. So I found a safe maximum value result for the formula, and it is 245, just a little less than 255.

I foud it will be impossible to reconstruct the two lines structure. The reason is: the camera debayering process turns the two lines separation in a mixture of two or three lines resulting in the wave. After reconstructing the lines, the interpolation algorithm must do the job considering this pattern.

wavelength = 32 lines in 7 groups and 14 sub-groups.
each group contains the adjacent hi-lo lines
each sub-group contains hi or lo lines

the groups and sub-groups distribution inside the wave is:

hi-lo:
2-3
2-2
3-2
2-2
3-2
2-3
2-2

Numbers in the left are iso hi, numbers on the right are iso lo.
There are 3 lines together two times in the left and two times in the right.
The first two groups have same desing as the last two groups.
Three groups in the middle are in symmetric arrangement.
This design makes things calibrated.

So the algorithm is (see the attached original wave and reconstructed wave images below):



DeWaving Algorithm by Apefos
(for H264 dual iso with two lines per iso)


General Function: to reconstruct the lines in h264 video recorded in Canon DSLR using Magic Lantern Firmware using dual iso module with two lines per iso set to 3 fstops iso difference, removing the wave pattern generated by camera debayer algorithm and allowing extraction of two images with different isos.


Three suggestions to match the algorithm with the wave pattern in the image:

1 - User must reposition the video file height in timeline to put the first line of the first wave in the line 01 of the frame.

2 - Insert a wave 00 before the wave 01 in the algorithm and leave the image from the camera as is. The user types a number between 00 and 31 and the entire algorithm is moved down using the typed number as how many lines to move down the first line of wave 01. This way the wave 00 will fit the lines above.

3 - User types a number between 01 and 32 and this number will be the line where the first wave 01 starts. The wave 00 will fill the lines above/before the wave 01. (best option)

(After some try, the user will find the number for his camera).
(all video files from the same camera are expected to need the same amount of height reposition).


Main functions (rules all line functions):

main function A: decimal results below 0,5 = discard

main function B: decimal results equal or above 0,5 = +1

main function C: results above 245 = 245

main function D: (this must be decided by the programmer)
idea 1: line functions apply it's function separately to the R, G and B values of each pixel in the line.
idea 2: line functions apply it's function to the global luminance value of each pixel in the line, some kind of brightness adjust.
(luminance values are measured in RGB 8bit, from 0 to 255, for both ideas 1 and 2)


The Wave design: Line Isos and Line Functions:

wave 00 ( to process the lines before/above wave 01)
(repeat the lines from wave 01)

wave 01 (starts at line 0001) or (starts at line 0001 + number typed by user) or (starts at line typed by user)

wave line 01 = iso hi, line function: luminance x 1.132184
wave line 02 = iso hi, line function: luminance x 1.010356
wave line 03 = iso lo, line function: luminance x 0.523438
wave line 04 = iso lo, line function: luminance x 0.870130
wave line 05 = iso lo, line function: luminance x 0.592920
wave line 06 = iso hi, line function: luminance x 1.031414
wave line 07 = iso hi, line function: luminance x 1.082418
wave line 08 = iso lo, line function: luminance x 0.770115
wave line 09 = iso lo, line function: luminance x 0.957143
wave line 10 = iso hi, line function: luminance x 1.238994
wave line 11 = iso hi, line function: luminance x 1.020725
wave line 12 = iso hi, line function: luminance x 1.387324
wave line 13 = iso lo, line function: luminance x 0.837500
wave line 14 = iso lo, line function: luminance x 0.683673
wave line 15 = iso hi, line function: luminance x 1.036842
wave line 16 = iso hi, line function: luminance x 1.000000
wave line 17 = iso lo, line function: luminance x 0.663366
wave line 18 = iso lo, line function: luminance x 0.917808
wave line 19 = iso hi, line function: luminance x 1.368056
wave line 20 = iso hi, line function: luminance x 1.020725
wave line 21 = iso hi, line function: luminance x 1.270968
wave line 22 = iso lo, line function: luminance x 0.817073
wave line 23 = iso lo, line function: luminance x 0.807229
wave line 24 = iso hi, line function: luminance x 1.042328
wave line 25 = iso hi, line function: luminance x 1.010256
wave line 26 = iso lo, line function: luminance x 0.582609
wave line 27 = iso lo, line function: luminance x 0.893333
wave line 28 = iso lo, line function: luminance x 0.523438
wave line 29 = iso hi, line function: luminance x 1.026042
wave line 30 = iso hi, line function: luminance x 1.158824
wave line 31 = iso lo, line function: luminance x 0.788235
wave line 32 = iso lo, line function: luminance x 1.000000

wave 02 (starts at line 0033) or (starts at line 0033 + number typed by user) or (just after previous wave)
(repeat same lines from wave 01)

(and goes like this until reaches line 1080)
(the 1080 lines needs 33.75 waves, so the algorithm can have 35 waves (from wave 01 to wave 34 plus the wave 00 before/above the wave 01, total = 35 waves)

End of algorithm.

To create the lines function table for the other isos difference: shoot a grey wall with perfect illumination, with the lens in f8 to avoid vignetting, defocused. In computer, convert the image to 16bit, discard colors turning into greyscale. Find the first line of the wave and use the color picker to find the luminance value for each line. Line 16 in the wave will be the maximum luminance value for high iso, line 32 will be the lowest luminance value for low iso. The other high iso lines must be multiplyed by a factor/ratio number to get same luminance value of line 16. The other low iso lines must be multiplyed by a factor/ratio number to get same luminance of line 32. In the conversion table of wave 01 in the algorithm, it shows which line is low iso and high iso. To find the factor/ratio number for each line, divide the luminance value of line 32 by the low iso lines luminance value, and divide the luminance of line 16 by the high iso lines luminance value. After finding the factor/ratio numbers, then create the table. (the wavelength is 32 lines and finding the correct first line, the line 16 and line 32 will be the maximum and minimum luminance values respectively, the wave's ridge and valley). To find the first line of the wave in h264 canon dslr dual iso video, compare the image pixels with the images below.

Other line functions can be created in the algorithm for each line, for example: hue correction, saturation correction, white balance correction...

See the wave and the reconstructed wave:

(http://www.apefos.com/dualiso/wave.jpg)

Last observations:

Someone needs to compile it into some kind of DUALISOH264.exe, so we can drag the MOV file over it and get the still images DeWaved. Maybe also with the isos extraction and interpolation... (I do not know computer programming) Or maybe the Ginger HDR people could do something...


My theory for the one line per iso version is:

the wavelength will be 16 pixels

the amount of merging will be higher, lines separation will be almost lost, or completely lost, so work with 2 stops difference will be smrt decision to help the camera debayer.

if the debayer in camera merges all the lines, instead of reconstructing the lo and hi isos, maybe it will be possible to adjust the luminance values of each line direct into the image.

it deserves a try...


And That's All Folks!!!

BRITOM
that clip you have there don't look like good news. See the child's body twist and her head go back. If someone did that to my child, my instant reaction would be to boot f$#! the B%@!# right in the face.

A1ex showed a color chart in other topic and talked about his interest in better color preview in camera LCD when recording dual iso raw.

This makes me to go back here in this topic in post number 24 when he talked about hue differences between the two isos. At that moment I did not pay attention to the issue, because my mind was focused in the first challenges, to perceive lines retention and enabling h264 recording.

But after finishing the algorithm and seeing the color chart from A1ex and his informations about color differences, I perceived my job was incomplete. I need to consider the information from A1ex which says there is a hue difference between the two isos.

So I did some tests with the 600D today at night here to perceive how is the color behavior. I recorded some dual iso h264 videos showing different colors and in computer I confirmed there is a hue difference, but not just a hue difference, there is also a white balance difference between the two isos in the image.

This will make necessary to do a precise test in the same way I did the grey wall test. But this time with colors. I will need to find the hue difference and white balance difference between isos and calculate formulas for each line in the wave considering the amount of merging between them, because merging changes the hue and white balance difference... I will also need to perceive if color formulas must be applyed before of after luminance formulas... just another challenge...

Ginger HDR replied my email. They asked me If I did a try to reconstruct one still image using the algorithm. This made me to realize that I need to show the algorithm working before someone compile it into a computer software. (oh! obvious thing!)

So, after the color tests and color formulas implementation I will try to reconstruct the lines in a still image manually using the algorithm.

@globalphotobank @everybody, i really sorry, i pasted the wrong gif link... my apologies to everyone

I'm interested in fixing the dual iso preview for photos, not for video. The problem is slightly different: you have to match a small and color-distorted image (720x480 YUV) with some reference image. You no longer have to match colors for each scanline, but only at macroscopic level, because the heavy downsampling already took care of the scanlines.

So, I've tried to find Canon's response curves and how they change when using dual ISO, and for this purpose I've generated the following test images:

gradient-neutral-100.CR2 (http://a1ex.magiclantern.fm/bleeding-edge/gradient-neutral-100.CR2)
gradient-neutral-100-1600.CR2 (http://a1ex.magiclantern.fm/bleeding-edge/gradient-neutral-100-1600.CR2)

(extract the embedded JPEG previews from them and compare them with the raw data)

The biggest issue is now obvious: besides the color cast, as soon as one of the ISOs gets clipped, the color info is lost. I think it's now clear that, unless you find a way to disable Canon's desaturation feature in bright highlights (maybe with a picture style?), the entire dual ISO from H.264 is just a waste of time.

If anyone would like to prove me wrong, please use technical arguments, not spirits.

Ok A1ex, I understood exactly what you want, just give me some time.

@apefos  Here is the version of Dual_Iso you wanted for TL 2.0 NewMem, already tested it on my 600D and all is fine.
https://bitbucket.org/mk11174/magic-lantern/downloads/ML_600D_TL_NewMem_Dual_ISO_H264_Nov_26_2013.zip (https://bitbucket.org/mk11174/magic-lantern/downloads/ML_600D_TL_NewMem_Dual_ISO_H264_Nov_26_2013.zip)

@MK11174

Many Thanks! I downloaded and instaled in card. It is working OK! I got no waterfalling behavior in first tests and module loads fine. Now the dual iso indicator turns green, great!

@A1ex

I did a look in the CR2 files you uploaded in Digital Photo Professional and in Picture Style Editor, mainly in the 100-1600 and compared with the extracted jpg.

To be honest I do not believe a Picture Style will help you in this preview. Let me explain why: The nature and concept of dual iso is the iso 100 capture good highlights and iso 1600 capture good shadows, so most times the iso 1600 will be clipped in things like clouds, open windows and so on. When the image is clipped there is no information to recover because everything will be above 255, so no way to recover anything. I did lots of try to lower the highlights and what was clipped in the 1600 iso lines turned into a flat grey image. And the low iso lines turned into something like false color preview. Professional photografers will not like this.

My idea to solve this preview issue is you enable this functions in some camera buttons:

when dual iso module is enabled:
Press left arrow = disable (suspend) dual iso module and set camera to same low iso of dual iso module
Press right arrow = disable (suspend) dual iso module and set camera to same high iso of dual iso module
Press set = enable dual iso module again (kill suspend)

This way people can see the shadows recovered by the high iso, see the highlights preserved by low iso and see the mixed image if they want. And see things fast, just pressing one button. Only this will give to the professional photografers the perfect preview to see exactly what they are capturing in shadows and in highlights.

If you can, you also can enable camera buttons to change the low and high iso without the need to go into the ML menu, so the photografer see and change low and high iso separately and change them fast:

when seeing low iso press up or down arrows to change it
when seeing high iso press up or down arrows to change it

I don't think A1ex was talking about using picture styles to fix the preview, he was referring to the white clipping of the highlights that the camera does.

Imaging a bright red light, if you take a picture of the red light you might expect that when the values are clipped in the image that you would end up with a bright red pixel but that is not what happens the camera automatically converts the overly bright red into white destroying any of the color information what might have been there. This is not the case for raw since it is just raw sensor data. What this means is that unless you can find a way of stopping the camera from converting clipped highlights into white there won't be anyway to correctly merge the 2 iso's together when there is clipping.  He was suggesting that maybe a picture style could do this.

Have you ever tried to merge an hdr when there are objects in the scene that are moving. I had done several in the past at night with traffic and I can tell you that these incorrect clipped highlights will cause some nasty color artifacts when merged turning bright purple or pink, etc...

Oh guys, you are so hungry!!!

I will show something I am working on since I got my 600D in november 2012. Don't ask anything now!  :-X

Is this what you want?

(http://www.apefos.com./dualiso/teaser1.jpg)

(http://www.apefos.com./dualiso/teaser2.jpg)

 :-X

 :-X

I'm marking the topic as IMPOSSIBLE, until you will be able to prove me wrong.

Quote from: a1ex on November 27, 2013, 01:18:33 AM
I'm marking the topic as IMPOSSIBLE, until you will be able to prove me wrong.

badass

what's the difference between HDR and dual ISO?

ok, no problem, I understand. People wants to see things working.

I will stop posting for a while and concentrate my efforts to finish the demonstration video editing for the aps project I showed in the photos above.

After this I will finish the color tests to improve the algorithm and I will reconstruct a still image extracted from h264 video using the algorithm to prove it works.

It will take time.

I will stop posting for a while until I can show something working.

Thanks.

Quote from: djsubject on November 27, 2013, 04:21:43 AM
what's the difference between HDR and dual ISO?

HDR is "high dynamic range".

HDR usually is constructed from taking multiple pictures at different exposures and combining them all together to get my dynamic range, as in you can see whats in the dark regions as well what is in the super bright regions.

Dual ISO is another way to construct HDR images from one picture, by scanning each line of pixels at different ISOs to create an under and overexposed image interlaced together.

Both of them then need further editing in post.



And to apefos:
You talk a lot of gibberish on different posts which is also sometimes completely irrelevant.
And then make multiple posts in a row. Would you mind toning it down just a little please. :)

Quote from: apefos on November 27, 2013, 07:05:09 AM
ok, no problem, I understand. People wants to see things working.

i think it will work. definitely.
BUT...

when you raise details in single H.264 blocks in vertical direction by interlacing hi/lo exposure, then you lose some bits of your available bandwidth
for describing that interlace pattern. this means you lose horizontal detail and vertical detail across the lines.
because the interlaced lines are visible strongly, the small differences caused by other gradients is very low.

my assumption:
due to the lossy compression, you will lose a decent amount of vertical resolution and also a bit of the horizontal resolution.
you have this detail loss in addition to the resolution loss in under/overexposed areas btw.

can you do me a favor?
can you record the common resolution check patterns in one video with dual iso enabled, disabled, ... a few times?
i would recommend about 5 seconds per state and about 5 ON/OFF combinations.
this with 3 video files please: one video with a low CBR, one with high CBR and one video with VBR (normal quality)

we then can look at the video frames and data rates.

Quote from: g3gg0 on November 27, 2013, 01:33:34 PM
i think it will work. definitely.

I've proved it can't work, even if you start from uncompressed YUV (see post #103).

If you still don't understand: let's say you have a function y = f(x), where x ranges from say -128 to +128, and let's say you have f(x) = x/100 (or something close to that). You can look at y and you should recover x. There's one little issue: you are working on integer math ;)

Quote from: a1ex on November 27, 2013, 01:58:25 PM
I've proved it can't work, even if you start from uncompressed YUV (see post #103).

If you still don't understand: let's say you have a function y = f(x), where x ranges from say -128 to +128, and let's say you have f(x) = x/100 (or something close to that). You can look at y and you should recover x. There's one little issue: you are working on integer math ;)

ah sorry, i didnt want to say it will work with the current state of implementation.
should have added "somehow", that would explain what this fragment of sentence should have expressed.

if you squeeze the integer range with a custom pic style / lut, you will lose color resolution but can cover the exposure ranges.
this will for sure raise some other problems too, no doubt!
and even if there is a workaround that is capable of cover the re-quantization (14 to yuv) properly, the H.264 compression is still lossy.

what i wanted to make clear:
H.264 is based on removing data your eye (brain) doesnt really need to see whats happening.
but in the case dual_iso the obvious thing isnt the interlaced bright/dark line thingy, but the relatively small deltas on top of that.
and H.264 algorithms will now try hard in reducing that "unimportant" data.

there could be one lucky circumstance: the vertical pattern equals the maximum vertical frequency that can be expressed with DCT parameters.
this would allow the encoder to use only fewer bits for describing that pattern. but i am quite sure the encoder can not detect that 1/2 * f_max pattern.
it will most likely detect a 1.9999998 * f_max + 0.00000001 * (f_max-1) - 0.00000001 + (f_max - 2) etc.
so we lose a lot more bits on describing that pattern.
-> reduced details in the whole image

@a1ex if you think it will not work no problem, but other people are free to do tests if they want, so stop bothering us and go work in your raw tasks. you are the main developer but you made this thing open source so please respect it's nature. we have the module enabled, we do not need you and your "impossible words"anymore, let us try our success or our fail alone, you are fired of dual iso h264 development, SHUT YOUR MOUTH AND GO AWAY, NOW!

@g3gg0 here is what you asked me:

a jpg sequence with the fist wave starting at line 01 (balck and white because i did not implemented wb and hue correction to the algorithm yet)

https://www.dropbox.com/s/8z0qghs027qtxdm/jpg192seq.zip (https://www.dropbox.com/s/8z0qghs027qtxdm/jpg192seq.zip)

here are the resolution chart tests in diffetent bitrates:

https://www.dropbox.com/s/mgyqi26r3j39els/MVI_1869.MOV (https://www.dropbox.com/s/mgyqi26r3j39els/MVI_1869.MOV)

https://www.dropbox.com/s/y59aqo92qtbbpre/MVI_1870.MOV (https://www.dropbox.com/s/y59aqo92qtbbpre/MVI_1870.MOV)

https://www.dropbox.com/s/g7ddce61rgxeeka/MVI_1871.MOV (https://www.dropbox.com/s/g7ddce61rgxeeka/MVI_1871.MOV)

https://www.dropbox.com/s/3sbnmmjgkdc8jqm/MVI_1872.MOV (https://www.dropbox.com/s/3sbnmmjgkdc8jqm/MVI_1872.MOV)

https://www.dropbox.com/s/klwl50juhqg22i0/MVI_1874.MOV (https://www.dropbox.com/s/klwl50juhqg22i0/MVI_1874.MOV)

https://www.dropbox.com/s/fqwecc61bn9vov0/MVI_1875.MOV (https://www.dropbox.com/s/fqwecc61bn9vov0/MVI_1875.MOV)

https://www.dropbox.com/s/mgyqi26r3j39els/MVI_1869.MOV (https://www.dropbox.com/s/mgyqi26r3j39els/MVI_1869.MOV)

Speechless!

Soon I will release a picture style.

I will ask for a small donation.

I will use some amount of the donations to support the developers who are willing to work in the dual iso h264 project until we see if it will work or not. I believe it will.

http://www.magiclantern.fm/forum/index.php?topic=9408.0

Quote from: apefos on November 27, 2013, 03:17:04 PM
@a1ex if you think it will not work no problem, but other people are free to do tests if they want, so stop bothering us and go work in your raw tasks. you are the main developer but you made this thing open source so please respect it's nature. we have the module enabled, we do not need you and your "impossible words"anymore, let us try our success or our fail alone, you are fired of dual iso h264 development, SHUT YOUR MOUTH AND GO AWAY, NOW!

wtf??

i guess that is time to say that we need this particular kind of spirit even less.

Quote from: g3gg0 on November 27, 2013, 03:48:54 PM
i guess that is time to say that we need this particular kind of spirit even less.

+1

This dudes been on a rant since his first post in this thread... he even argues with himself.

I failed horribly in math class, but I did do pretty damn good in government and social studies. I'll just say this. You don't have to like the leadership, but you still show them respect for their hard work and knowledge. Wow...

Quote from: Andy600 on November 27, 2013, 03:29:57 PM
Speechless!

+1
is there an ignore function on the board?

...waiting for everyone to gather their pitchforks and torches...

@all except for apefos: Did I call it in Reply #46, or what? What, right? Cheers!

I think the Leadership, the Master cannot discourage the padawans without showing a proof that things will not work.

In this moment, the Leadership, the Master, just have a theory that things will not work, not an experiment, a real proof.

And me, the padawan, I already found the waves behavior and I have an algorithm that worked in the first lines reconstruction test, so I have the first proof that things can work.

So, due to this, I believe that the discouraging behavior of the Leadership, the Master, is a disrespect to me and to all padawans, because if we are in an open source environment, we all have the rights of doing our attempts.

Yes, me, myself, as a padawan, I lost my temper, my bad. But me, myself, as a padawan, I do not need to endure the disrespect from the Leadership, the Master, discouraging me and all the others without any proof.

Probably you all are waiting for me to say sorry. So, I say sorry, many times as needed. But respect my attempts, do not say impossible without any proof, stop discouraging all the people who are willing to help this development.

By the statement "Impossible" have your ambition now be so great to get it to work!

If it's possible now or later.

And if it will not work, it is so, and you are an experience richer.

Let us continue to participate in your results and do your own experiences.

@apefos - dude, you better watch your tone and i am not even going to quote from you , it is really hard to read such things. You have an idea - thats good, continue and be happy but DO NOT disrespect people, especially the ones, who we- all ML users - owe so much!

Quote from: Stedda on November 27, 2013, 03:54:45 PM
This dudes been on a rant since his first post in this thread... he even argues with himself.

Lol.

Yeah he is as bad as that other character that popped up and got banned pretty quick.

I do think this guy is troll, or part troll. He also spams posts with irrelevant information.

Am I safe to say most people want to see him muted?

Apart from bizarre outbursts... I tested it and found that the resolution loss to great. The alternating lines were not well formed (reconstructed with aliasing?) and so created many artefacts when merged. Also there is the small issue of loosing half your vertical resolution! You can't actually reconstruct detail from these large interlacing lines.

Here's a real-world test image (100/1600, exposed with ETTR):
(http://a1ex.magiclantern.fm/bleeding-edge/recover-this-small.jpg) (http://a1ex.magiclantern.fm/bleeding-edge/recover-this.jpg)

If you are able to recover it, I'll give up on engineering and start growing mushrooms instead.

Hopefully this completes the proof for all the non-believers.

Quote from: a1ex on November 28, 2013, 11:56:06 AM
If you are able to recover it, I'll give up on engineering and start growing mushrooms instead.

that kind of that you get in dark corners of underground railway stations for money? ;)

Quote from: a1ex on November 28, 2013, 11:56:06 AM

...start growing mushrooms...

Not so bad idea... but please, don't leave  engineering!!!

Quote from: apefos on November 27, 2013, 08:57:57 PM
I think the Leadership, the Master cannot discourage the padawans without showing a proof that things will not work.

In this moment, the Leadership, the Master, just have a theory that things will not work, not an experiment, a real proof.

And me, the padawan, I already found the waves behavior and I have an algorithm that worked in the first lines reconstruction test, so I have the first proof that things can work.

So, due to this, I believe that the discouraging behavior of the Leadership, the Master, is a disrespect to me and to all padawans, because if we are in an open source environment, we all have the rights of doing our attempts.

Yes, me, myself, as a padawan, I lost my temper, my bad. But me, myself, as a padawan, I do not need to endure the disrespect from the Leadership, the Master, discouraging me and all the others without any proof.

Probably you all are waiting for me to say sorry. So, I say sorry, many times as needed. But respect my attempts, do not say impossible without any proof, stop discouraging all the people who are willing to help this development.

All I am saying "Give peace a chance!"

;-)

Quote from: g3gg0 on November 28, 2013, 12:09:48 PM
that kind of that you get in dark corners of underground railway stations for money? ;)

That's a bit 'specific' g3gg0  ::)


...which station?  ;D

Quote from: a1ex on November 28, 2013, 11:56:06 AM
Here's a real-world test image (100/1600, exposed with ETTR):
(http://a1ex.magiclantern.fm/bleeding-edge/recover-this-small.jpg) (http://a1ex.magiclantern.fm/bleeding-edge/recover-this.jpg)

If you are able to recover it, I'll give up on engineering and start growing mushrooms instead.

Hopefully this completes the proof for all the non-believers.

Well, I tried to... Maybe at some point someone manages to get a better quality...
https://drive.google.com/file/d/0B89CpY3irum7ZVEzZGlPQTFPeTg/edit?usp=sharing

Just as a suggestion, couldn't this interlacing be done like the ML HDR thing? We alternate which lines use high/low ISO every frame, and then compose on post?

Nice try, but I'm not impressed. The sky shouldn't be gray, and neither the roof.

I'm down for some mushrooms.

If  you eat poisonous mushrooms it will look like that :

(http://s30.postimg.cc/l3mbqvc5t/image.jpg)

Magic Lantern... Magic Mushrooms... THIS must be the inspiration! And I was wondering how you devs could handle all that coding (and even seem to have fun doing it...) @A1ex, please post some growing instructions, maybe we can all become coding geniuses like you!
PD: Glad this thread took on such 'positive' tone after all!

Quote from: apefos on November 27, 2013, 03:17:04 PM
@a1ex if you think it will not work no problem, but other people are free to do tests if they want, so stop bothering us and go work in your raw tasks. you are the main developer but you made this thing open source so please respect it's nature. we have the module enabled, we do not need you and your "impossible words"anymore, let us try our success or our fail alone, you are fired of dual iso h264 development, SHUT YOUR MOUTH AND GO AWAY, NOW!

LOL???

where did that come from hahaha!

This thread seems to have died but I have been playing around with Apefos' workflow for Dual Iso h.264

I tried in the Apefos Dual Iso software and these are my results, the image recorded in dual iso and the image after processing in the software and merged in the hdr software.

The Apefos Dual Iso works with JPG, BMP and TIF files. You need to convert the MOV video into a image sequence before using the software.
The software automaticaly batch process all images in the directory, it opens the image, apply the luminance factor numbers to correct the luminance for each line and extracts the low iso and the hi iso lines. After this the software interpolates the low and high iso image separately to recreate the missing lines. With these two recreated images you need to use a hdr software to merge the two images into a single hdr image because the Apefos software does not do the merge.

Apefos is using the most simple interpolation method, an average value from the pixel above and below. this simple interpolation method does not removes the aliasing. he also says in the to-do txt file he created a conversion for eliminate the 2 and 3 lines interval to make the image to be 2 lines interval, the same of dual iso raw, but this is not implemented in the beta software yet.

Another thing that is not perfect is the luminance correction in the lines. He is using 32 values, so some areas of the image keeps with some lines strip. In the to do txt file he says he already calculated 946 luminance correction numbers, but this is not implemented in the software yet.

The results are not satisfactory for use, but the software is in a interesting stage.

Apefos is still working hard on perfecting this workflow.  :)

So, are you able to challenge my proof (http://www.magiclantern.fm/forum/index.php?topic=9145.msg89835#msg89835) or recover the colors from my test image (http://www.magiclantern.fm/forum/index.php?topic=9145.msg90031#msg90031)?

Well that was entertaining... now where's my dual ISO H.264??? I didn't read this whole thread to come up empty handed  :).

Try growing mushrooms instead!

Mushrooms are easy to grow, they grow by themselves on the roof of my bathroom.

Soooooo lost in this thread!
Anyway, I have an idea (briefly tested without sound) for processing H.264 Dual iso! Here goes:

1) Import dual iso footage into NLE
2) Double speed of footage
3) Export footage at double the original frame rate
4) Re import footage
5) Decrease speed 50%
DONE!

In my brief testing, the only potential problem I noticed was a slight choppiness to the end result, but I'm sure someone could use this type of workflow to get some useable results ...maybe?

How does changing the frame rate, change exposure?

This method sounds to good. @cmccullum would you like to answer my question from your thread?

@audionut as far as I can figure, it isn't actually changing the exposure, but causing the flicker to happen so rapidly that it can't be seen (or registered by premiere?). I don't know why the flicker doesn't come back when the new clip is slowed down though. This is just something my crazy brain thought up. If anyone could explain this further, please do!

@conaxe I can't find my thread  :-\ it may have gotten deleted for some reason. As you can see I'm brand new to the forum, and this is actually the first online forum I've ever participated in

Edit: after reading over my post again, I figured out why I even had this idea and why I think it works:
When the speed of the original clip is doubled, the two alternate ISO frames are squished into the space of one frame. In the original timeline, these are "seen" as two condensed frames, but when exported at double the original frame rate, they are read as one frame and joined somehow.
Ex: a 300 frame 24fps clip takes up 300 frames in a 24fps timeline. Double the speed, and you have 300 frames taking up 150 frames in the timeline. Export that clip at 48fps and you now have a 150 frame clip. Bring that clip in to the 24fps timeline, and expand those 150 frames to take up 300 frames worth of time.

To be honest, this could all be complete nonsense. I've still only tried it one time with one clip the moment I got the harebrained idea, but if we do some more testing, and find it to be a viable workflow, it shall be dubbed DUAL ISO FRAME FUSION!!

What you are describing is not "Dual ISO", it is called "HDR Video" there are plenty of existing workflows for processing it properly.

"Dual ISO" is interlaced ISOs within a single frame, "HDR Video" is alternating ISO from frame to frame. It's easy to recover h.264 "HDR Video", it's impossible to recover h.264 "Dual ISO".

@dmilligan I used the dual ISO module, and alternating ISO frames is what I got. Im definitely not saying you're wrong, but as far as I've understood, everyone talking about dual ISO videos has been dealing with the same thing. Am I misunderstanding all of this?

Read about dual ISO, and read about ML HDR video.

When you have a clear understanding about both exposure methods, all your misunderstandings will be cleared.