Topics

@1% :  I still don't understand what this jpslice thing is or actually does, but could it be used to improve the quality of "normal" CBR encoding?  (ie encoding at CBR1.0-1.5x with GOP 12.)  Or do you need to drop the GOP to be able to improve jpslice at all?

Sorry for the tangent, but has anyone tested increasing the GOP to perhaps improve CBR 0.8x, etc?

EDIT:  Sorry guys, I've just found I can already do this by using HDR with Intervalometer, but setting the exposure bracket to 0 EV.  I didn't realise there was a 0 EV option!

If I use Hi-Res Silent Picture with the Intervalometer then I have a problem if there is motion in the image, because the hi-res image is taken in panels that are out of sync with each other.  Even fast-moving clouds or blowing trees are a problem.  My solution to this would be to take several photos consecutively and average them, so it approximates one long shutter image.  This could also be used creatively, giving the effect of an ND filter.

In fact, why not have this as an option for "normal" silent images?  A pseudo-long-shutter option achieved by averaging several/many silent pictures?  You could also combine this with HDR, but it would be good to have it as an option without HDR.

Another time when multiple-shots intervalometer would be good is to be able to eliminate things from the scene, e.g. a timelapse of a beach, where a seagull flies across the scene or a child runs across.  If you have two images with them in different places in the frame, you can easily delete them with little effort.

When changing ISO whilst recording in manual video mode, it simply jumps between the ISO values, producing big jumps in exposure.  However, during automatic video it is much much smoother.  Could we have it that when ISO is changed it is changed gradually over a few seconds or so?

Perhaps even by momentarily adjusting the shutter speed slightly (if necessary) to smooth the transition (e.g. if shutter speed is 1/50, allow it to be 1/40 or 1/60 as required for a few frames).

Thanks!

CBR is much safer than Q-Scale, however it sometimes uses very high quality Q-scales on scenes that don't require it.  For example, for casual home/holiday movies I may decide I don't ever want to go better than Q-scale -8 or -4.  (For clarity, negative Q-scales are less compressed and higher quality than positive ones.)  This would save space on the card and also on my HDD later (and forever), and increase the 4GB recording time limit.

Of course, the CBR setting can be reduced, e.g. to 0.6x, but this will result in noticeably poor quality in complex scenes.  An obvious approach would be to use the specific Q-scale value all the time, but the option of the proposed Q-scale-limited CBR would avoid the dangers of suddenly stopping recording if Q-scale -8 Is used all the time.

Yesterday I briefly tested Q-scale -8 on a stationary scene, just moving the camera side to slide and it choked several times, despite using a just-formatted 45MB/s (300x) SanDisk UHS-1 SD card.  (Which, for clarity, is 4.5x faster than a Class 10 card.)

This could also be useful for people with class 4 or class 6 cards, because CBR 1.0 limited to Q-scale -8 may work much more safely.

Thanks!

Include video bitrate settings in movie log file.
Also camera model.
Also HDR video settings used.

If possible:
Also the positions (times) at which any photos were taken during recording, and also their file names, if possible/feasible.
For 600D, whether the video is crop 1080p or full sensor width.


PS - I've found a few .LOG files where the ISO is recorded as 0.  Is this a known bug?

Thanks.

Since ML seems to be able to monitor the buffer level, would it be possible to encode at the maximum bitrate possible without video stopping?  If the buffer starts to fill, ML would reduce the bitrate as required.  It may be risky (in terms of unpredictable stopping) but there are times when that would be ok and it could just be restarted.  Also, for such times a lower target buffer usage could be set, eg only 50-60%.

And/or perhaps a system where you can set a VBR setting, eg -12 (high quality), or even -16, but ML would automatically reduce it if the buffer starts to fill, and could then gradually increase it later if the buffer remains unfilled.  This would allow higher quality at the same time as allowing the bitrate to drop lower in simple areas/scenes.

All the HDR video options start with ISO 100; how about allowing setting both ISO values, to allow 400/1600, etc?  Useful for low-light HDR.

Ta.

Hello Alex.  Thanks for the improvements so far!

1)  Firstly, is Crop 1080p going to make an appearance any time soon?  This would be super-useful at times to avoid moiré and aliasing (as well as the option of extra zoom) - just shoot the scene using a wide-angle lens but at a 3x crop factor (or 4.8x for already 1.6x crop-frame sensors) to avoid aliasing.


2)  Is it possible to choose which lines of the sensor are selected to be encoded to make up the 1080p?  If so, could the group of lines be alternated between each "frame" so that they actually become fields of an interlaced video?  (The idea is to reduce/eliminate aliasing and moiré.)  These fields could then be deinterlaced into frames on a PC, using an existing high quality deinterlacing algorithm.

And it could use just the centre two-thirds (2160 lines, or twice whatever is actually currently) of the sensor, perhaps with the option of still using the full width, producing a 2.35 aspect ratio.  This would create a slight crop factor but reduce/eliminate aliasing and moiré.


3)  I have read that the crop-frame sensors actually only capture 1720x974 and upscale it to 1920x1080 before encoding.  Is this true, and is development any nearer allowing encoding at this native resolution without upscaling (which presumably hurts quality)?

If this is difficult to do as a video, I wonder if 24 "silent images" at 1720x974 could be recorded to the card every second along with audio?  In terms of megapixels 24 x 1720x974 is only equivalent to 2.2 x 18MP per second.  I could cope with each video being a list of thousands of JPEG files.

Many thanks!   I have donated