A495 porting thread

  • 346 Replies
  • 46856 Views
  • Publish
    Re: A495 porting thread
    « Reply #300 on: 03 / July / 2011, 06:35:03 »
    Advertisements
    OK, but the A495 records in MJPEG and not in h264.

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    Re: A495 porting thread
    « Reply #301 on: 03 / July / 2011, 06:49:14 »
    Thanks for your suggestions. Does someone have a clue for the missing "Quality override" option?

    If you're referring to the override to select 'Super Fine' JPEG compression this isn't enabled for the A495.

    Phil.
    CHDK ports:
      sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
      g12 (1.00c, 1.00e, 1.00f & 1.00g)
      sx130is (1.01d & 1.01f)
      ixus310hs (1.00a & 1.01a)
      sx40hs (1.00d, 1.00g & 1.00i)
      g1x (1.00e, 1.00f & 1.00g)

  • Publish
    Re: A495 porting thread
    « Reply #302 on: 03 / July / 2011, 06:53:09 »
    Why isn't it enabled? Would it cause some harm to the camera?

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    Re: A495 porting thread
    « Reply #303 on: 03 / July / 2011, 07:13:47 »
    Why isn't it enabled? Would it cause some harm to the camera?


    No idea. It's possible the camera simply doesn't have it or whoever did the port decided not to include it.
    In most cases 'Super Fine' doesn't give you any visible improvement in image quality; but it does make the files up to 3x bigger. If you want the best image quality save RAW images.

    If you feel like testing it let me know which firmware version you have and I'll compile a version with the quality override enabled.

    Phil.
    CHDK ports:
      sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
      g12 (1.00c, 1.00e, 1.00f & 1.00g)
      sx130is (1.01d & 1.01f)
      ixus310hs (1.00a & 1.01a)
      sx40hs (1.00d, 1.00g & 1.00i)
      g1x (1.00e, 1.00f & 1.00g)


  • Publish
    Re: A495 porting thread
    « Reply #304 on: 03 / July / 2011, 08:49:15 »
    I have firmware version 1.00F. Concerning the unavailable option, I had the feeling maybe the person who made the compilation thought wrongly the A495 produces H.264 MOV files. Anyway I shoot always RAW+JPG but sometimes I would try to temporarily disable RAW to be able to shoot again more quickly. After experimenting a bit with JPEGs from RAW, I find the original "Fine" setting (which produces ca. 2.5MB files) has too much of compression, fine details washed out, with my tests a good JPG with a 95% quality factor is around 5MB. These latter are from RAWs processed with RawTherapee, so such images are maybe better than the "Super fine" camera settings allow for.
    Thanks a lot for compiling a version with 'Quality override' enabled!

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    Re: A495 porting thread
    « Reply #305 on: 03 / July / 2011, 08:57:53 »
    I have firmware version 1.00F. Concerning the unavailable option, I had the feeling maybe the person who made the compilation thought wrongly the A495 produces H.264 MOV files. Anyway I shoot always RAW+JPG but sometimes I would try to temporarily disable RAW to be able to shoot again more quickly. After experimenting a bit with JPEGs from RAW, I find the original "Fine" setting (which produces ca. 2.5MB files) has too much of compression, fine details washed out, with my tests a good JPG with a 95% quality factor is around 5MB. These latter are from RAWs processed with RawTherapee, so such images are maybe better than the "Super fine" camera settings allow for.
    Thanks a lot for compiling a version with 'Quality override' enabled!

    Attached version should have 'quality override' enabled in the 'Extra operations' menu.
    No guarantee it will work - it depends on whether the actual 'super fine' setting code is still present in the firmware.

    Phil.

    CHDK ports:
      sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
      g12 (1.00c, 1.00e, 1.00f & 1.00g)
      sx130is (1.01d & 1.01f)
      ixus310hs (1.00a & 1.01a)
      sx40hs (1.00d, 1.00g & 1.00i)
      g1x (1.00e, 1.00f & 1.00g)

  • Publish
    Re: A495 porting thread
    « Reply #306 on: 03 / July / 2011, 09:16:58 »
    Thanks a lot, it does work! You are right that the visual quality is not very different from the "Fine" setting though. It is good however to have a new override as maybe under bright light conditions the difference is visible. But anyway this demonstrates how much better images the workflow RAW->processing software->JPG produces.

  • Publish
    Re: A495 porting thread
    « Reply #307 on: 03 / July / 2011, 12:26:55 »
    If you're referring to the override to select 'Super Fine' JPEG compression this isn't enabled for the A495.
    If I follow this thread correctly,  this is an issue with jpeg's and not video ?  It seems to have started with video and transitioned.

    @philmoz :  I assume the is an issue with a #define in platform_camera.h ?  Is so, which one ?   The problem with that file is that there doesn't seem to be a way to know if something is missing - it doesn't look like every parameter is either #define of #undef.


  • Publish
    Re: A495 porting thread
    « Reply #308 on: 03 / July / 2011, 12:45:09 »
    If I follow this thread correctly,  this is an issue with jpeg's and not video ?  It seems to have started with video and transitioned.

    I was asking advice on two unrelated issues: the video quality one and the 'Super fine override'. For the video question, my thought also was a card speed issue, only it was strange that increasing the constant quality factor had a negative impact (spurious E09 errors) even if _constant bitrate_ was selected as active. My understanding was either quality or bitrate can be overridden, but not both, and they don't affect each other.

  • Publish
    Re: A495 porting thread
    « Reply #309 on: 03 / July / 2011, 13:34:40 »
    it was strange that increasing the constant quality factor had a negative impact (spurious E09 errors) even if _constant bitrate_ was selected as active.
    I'm not entirely sure what constant bit rate does but if it streams constantly as suggested then one would assume the data tranferred would be higher than what I assume is an intermittent bit rate.  So that would tend to make things stop sooner ?

     

    Related Topics